I am able to POST to the login form of a website with my username and password and retrieve authentication credentials in the form of insecure cookies. This allows me to access any other page of the secure website as if I was logged in via the browser. I believe this might be a vulnerability and would like to report it. What are the consequences of such a vulnerability that I can use to explain the situation to the company?
This doesn't sound like a vulnerability at all.
If I understand you right, uou do have to use your own username and password? Making a POST request with those is exactly what your browser does once you hit the logg in button. That you use another program to send the request is impossible for the server to know, and doesn't matter much anyway. Any client is as good as any other. There are no "authorized clients", there are just clients.
Think of it like this. If I write a program that sends exactly the same HTTP requests as Firefox do, how could your server differentiate between them? All the server see is the request, not the client itself. If I download the source code for Firefox and modify it for my purposes, how would your server know? (This, by the way, is also why the server can never rely on the behaviour fo the client to enforce security.)
Also, if this were to be considered as a vulnerability, how could an attacker exploit it? An attacker wouldn't know your password, so they couldn't POST it, no matter if it is done "programatically" or from a browser.
You mention that the cookie is "insecure". If you mean that it does not have the secure flag set, then that is bad practice. And it might be a sign that they are serving part of their site over plain HTTP, which is no good either.
As others have noted, sending your login credentials (username + password) is exactly what every client - be it Postman, a script invoking
curl, a web browser, or anything else - does. There are some risks that may occur with a login system, though:
- Does the system allow specifying a page you get redirected to after login? If so, does it allow specifying the domain of the link to be something the site's owner does not also own? That is an Open Redirect vulnerability, which can be used in combination with other attacks to bypass certain kinds of filtering and/or make it more likely victims will fall for a phishing attack or other form of malicious web page.
- Related to the above, can you redirect the user to a different URI scheme, such as
https:? If so, an attacker can potentially get an XSS on the user immediately after authenticating, which could be used to take actions as the victim and (if the browser doesn't actually navigate but does execute the script) even steal the user's login credentials.
- In the case of incorrect login credentials, does the POST request return a failure page that is vulnerable to XSS? For example, if you send a username that contains
"characters, and they are reflected in the response for failure without correct encoding, then an attacker could "link you to the login page" from another website, while actually injecting a script that steals your credentials if you log in.
- If no additional tokens are required, the site may be at risk from login CSRF, where an attacker forces a victim to log into a service using an account the attacker controls. While this isn't a problem in most services - if you log me into your StackOverflow account, for example, that just means I can use StackOverflow under your name (which doesn't help you any) - some services you really don't want to use while logged into somebody else's account. For example, imagine a password manager that has a browser extension and, any time you log into a service, asks if you want it to remember your password. If I can force your password manager browser extension to use an account I have access to, instead of your usual account, then if you save any passwords to it I will be able to retrieve those passwords later. Most of the time, though, login CSRF is not a concern.
- Finally, you briefly mention the risk of somebody trying to brute-force your password by programmatically sending a large number of login requests. This is absolutely a risk, and a well-designed login system will have protections against it. If you make a large number (the threshold is typically somewhere in the 5-10x range) of bad login requests, something should happen. Some good measures include requiring you to solve a CAPTCHA before you can try again (to break scripted brute-forcing) or disabling logging into the account but sending an email to the associated address, with a link that will log you in. Note that some other common approaches (like just locking the account for a few minutes) are not a good idea, as an attacker can then lock out legitimate users by deliberately sending bad login attempts as those users.
Now, with that said, let's look at some other issues you mentioned. If the cookie that stores the authentication token doesn't have the
Secure flag set, that is a major vulnerability. Any attacker on the same network as you could hijack your session by intercepting a web page that is served in plain text and adding a plain-text request (for example, a simple script request that does nothing but make your browser send a GET request) to the vulnerable site, then stealing the cookie when your browser makes that request over plain HTTP. Any web page which cares if the user is signed in should only ever be accessible over HTTPS - otherwise, an attacker can do even simpler attacks like Firesheep to hijack your session - and therefore there's no reason to ever have authentication tokens in non-secure cookies. The
HttpOnly flag is much less vital - there are XSS attacks that can be executed regardless of whether or not the script can read your cookies - but in general it should be set too.
Getting back to HTTPS, the site really ought to be using HTTP Strict Transport Security (HSTS), which protects against attacks such as SSLStrip; any site that requires authentication should be using HSTS, as it's just a header (
Strict-Transport-Security) in the HTTP response.