90

I discovered something I consider a major vulnerability in a SaaS product that includes the username and password in the query string of the URL on registration and every login attempt.

The technical support of the service has told me they consider the vulnerability insignificant, as the only way to exploit it is to gain access to the user's browser history.

Were they correct in their decision? I'm fairly new to information security, but it still sounds like laziness on their part.

I did skim through this question, but having read the most upvoted answer I'm now even more concerned about this being overlooked, as the data is sent via GET and the credentials are displayed in plain text.

Improve this question
4
  • 11
    Noteworthy: temporary authentication tokens that expire after use and/or a short time window are fine in URLs
    – usr-local-ΕΨΗΕΛΩΝ
    Commented Jan 25, 2018 at 8:12
  • 2
    It might be worth pointing out that a GET request is almost certainly the wrong HTTP method for the type of request being made. Parameters in the URL are what makes it trivial for the credentials to leak through; browser histories, link sharing, etc. Really the request should be POST with the credentials in the request body - thus preventing trivial credential leaks like this.
    – Fraser
    Commented Jan 26, 2018 at 0:43
  • You should only trust services that always use HTTPS for authentication and transfer the credentials using the POST method. This requires a valid and trusted certificate (green lock icon in address bar). Security tokens (they are unique strings, not credentials) valid for a single auth can appear in the URL without being a risk for security. Using GET for authentication is unprofessional: credentials can be registered in logs, history, third party software (security suites/malware/...) and browser add-ons. Never trust who does not take your security seriously.
    – user126127
    Commented Jan 28, 2018 at 10:48
  • From a social engineering POV, anyone who knows what sites you are visiting, will know what sites to target and thus can really start to profile you as an individual. I have seen numerous cases where attackers as part of their enumeration and recognisance phase will get you to click on a link as part, and all it does it pass your browser history to an attacker.
    – KingJohnno
    Commented Jan 29, 2018 at 10:27

4 Answers 4

Reset to default
120

Yes, this is a vulnerability. You can point them to such august bodies as

The common problem is that the credentials are stored on the client-side in the clear (browser history) and on the server side (webserver connection logs) and there are multiple methods to access that data.

Yes, it is laziness on their part. They are thinking of their code alone, and forgetting the client-side and the infrastructure.

Improve this answer
5
  • 36
    An important concern raised in the stackoverflow link is that the referer header may include the query string with the credentials. So tech support's assertion that the only way to exploit this flaw is to gain access to the user's browser history is simply false, and getting access to the server isn't necessary either.
    – Ray
    Commented Jan 24, 2018 at 19:08
  • 1
    @Ray the OP seems to state that it is sent when logging in, which limits the availability of it being used in a referer header. If it persisted as a means of session control, then sure, but I don't think that's the case here.
    – schroeder ♦
    Commented Jan 24, 2018 at 19:15
  • @schroeder A lot depends on what exactly is displayed right after they log in. If it was this site, for instance, it would be whatever page you were on when you decided to log in. I also can't help but think that this login method would synergize really well with an XSS vulnerability. In the end, the real reason to do it the safer way is (as it often is) "Why risk it?"
    – Ray
    Commented Jan 24, 2018 at 19:23
  • 3
    @ray, you're right, of course, but I'm trying to limit my answer to things that are easily demonstratable as data leaks. There's a ton more things that could also happen, but they might end up as situational or debatable.
    – schroeder ♦
    Commented Jan 24, 2018 at 19:26
  • 1
    Any proxies will be logging the credentials too. *note yes TLS inspection would be required for this though. Maybe "any" was a strong word..
    – user2867314
    Commented Jan 26, 2018 at 16:09
57

Secrets do not belong into URLs. URLs appear in browser histories, in proxy caches, in server logs, get sent to analytic service providers and can appear in many other places where you don't want secret information to appear. Using HTTPS (they do use HTTPS, right?) only prevents proxy caching, none of the others.

Users might also copy & paste URLs around without noticing that their login credentials are still in them.

Therefore, registrations and logins should use the HTTPS POST method with the login credentials in the body of the message.

Improve this answer
1
  • 19
    Copy paste is a huge one. URLs are made to be shared, if it shouldn't be shared it should go in the request params and not in the URL. Also goes for the other way around, send your search params in the url for convenience so users don't share a URL that leads to a blank search page.
    – Qwertie
    Commented Jan 25, 2018 at 4:28
12

First rule of product security: Never, ever, trust the vendor saying that a security issue is irrelevant.

I won't duplicate the technical answers given already. I want to expand on them and point out that the assessment that leads them to evaluating the issue as irrelevant is based on assumptions which may or may not hold up in the customer environment. Without a solid understanding of your environment they cannot make this call. That's like a car company saying that driving their new model at 250 km/h is perfectly safe - it probably is on the test track, but on most real-world roads it wouldn't be (road quality and traffic).

This becomes clear once you understand just how flawed their evaluation is. Aside from browser history, a GET parameter will also show up in proxy logfiles and it can be mistakenly mailed when someone wants to share a link, to name just the two most obvious other ways in which this secret could leak thanks to their bad engineering decision.

Taken both the vulnerability itself and their bad reasoning and handling around it together, I would seriously doubt their ability to manufacture secure products. I would let them know in no uncertain terms and re-evaluate the product in light of this new information.

Improve this answer
3
  • 1
    I am not sure how much you deal with security reports, but I get a handful every week where the user has no idea about what he is talking about. Time permitting, I try to explain why the problem is not a problem - some get it and some do not. So yes - there are times when an answer of "not applicable" or "not relevant" is correct. If you "never, ever" trust such vendors then it means that you do not deal with good vendors, who can estimate accurately. This is particularly visible with bug bounties - if you ever run one publicly you will quickly change your mind when receiving some "reports".
    – WoJ
    Commented Jan 27, 2018 at 13:19
  • (cont'd) and you will answer as "not applicable", "not relevant". Now - there are PLENTY of companies who completely fail to deal with their security, or misinterpret security reports. This does not mean that you should "never, ever" trust one who has an opinion different from yours.
    – WoJ
    Commented Jan 27, 2018 at 13:21
  • 3
    You misunderstood. A security issue is always relevant. Maybe not to you, or in typical settings, but there will always be at least one customer for whom it is relevant, and always at least one attacker who can leverage the issue into something more serious. Some things that people report are not security issues. But for these you can explain why (e.g. the check seems to be missing, but there is a check later in the chain).
    – Tom
    Commented Jan 27, 2018 at 14:14
3

You are right. There are two things here:

  1. Credentials in URL
  2. Caching in the browser

Credentials should not ever be exposed in URL. The URLs are logged in a lot of places, for example proxy server, firewalls, etc. I would be excited to steal that information if I was the firewall administrator or something along those lines. Now on to their point that the attacker would need access to the browser. Well how about if the user is using a public computer? Would they still say it’s insignificant? If they do, man, you need stop using their services.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .