0

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?

  • 3
    Can you define what you mean by "insecure cookies?" Given the flow you've described, (which sounds pretty standard) I'm not sure what you think the actual vulnerability is. – Xander Oct 19 '17 at 21:04
  • Just to check here... You get the cookies, and then you make requests for other parts of the website via the browser? Or your other program? If by browser, do you first insert the cookies into the browser? – Anders Oct 19 '17 at 21:12
  • I can use Postman to login to the website and then begin requesting secure information about my account using other POST requests to various endpoints. The insecure cookies are the secure flag set to false. These cookies are used as authorization credentials for the subsequent requests. I will not test my theory but I believe the site would be subject to brute force attacks to attempt username+password combinations via unauthorized client applications (my script). – Michael Markieta Oct 19 '17 at 21:29
2

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.

  • Correct, insecure cookie flag. – Michael Markieta Oct 19 '17 at 21:18
  • Is this not a security vulnerability if the intended method of accessing the site is via the browser? For example, If I was to try and authenticate a google account in an external application, I would need to provide the application context with authority to access my google account on my behalf. – Michael Markieta Oct 19 '17 at 21:19
  • A server does not know what kind of client is sending the requests. It just know what said requests look like. If I write a program that sends requests that looks exactly like the ones Firefox would be sending, how would the server be able to tell the difference? You could write a program that logs in to Google for you if you want to. Firefox, for instance, is a program that does that, but you could write your own. (This is why when securing a server you can never rely on any specific behaviour from the client.) – Anders Oct 20 '17 at 6:08
  • I have updated my answer to include the above discussion. – Anders Oct 20 '17 at 7:37
1

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 javascript: instead of http: or 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 < or " 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.