4

From what I understand using GET to submit usernames/passwords is a security issue because the username/password are part of the URL which can show up in browser history.

Is this still an issue if the login GET request is made using AJAX?

Abe Miessler
  • 8,155
  • 10
  • 44
  • 72
  • 3
    Already thoroughly answered here [Is there a difference between GET and POST for web application security?](http://security.stackexchange.com/questions/30754/is-there-a-difference-between-get-and-post-for-web-application-security) – Adi Oct 07 '13 at 17:16
  • It doesn't say anything about AJAX which I specifically ask about here. – Abe Miessler Oct 07 '13 at 17:26
  • 3
    It doesn't need to. Same concepts apply. The answers here are just repeating what is there. – Adi Oct 07 '13 at 17:28

3 Answers3

6

From what I understand using GET to submit usernames/passwords is a security issue because the username/password are part of the URL which can show up in browser history.

That's not the only issue. Using GET for situations where the user is submitting data opens up your application to CSRF vulnerabilities.

For example, I could embed <img src="http://yoursite.com/login?username=something&password=somethingelse">, which may log visitors on my site out of your site due to the call to the login handler. This specific example depends on implementation, but other attacks can be made. There may be cases when an attacker wants users to be logged in to their account.

Besides that, other loggers on the way (your ISP, etc) may log this for a longish period of time. Of course, the same can be said about POST request, but usually the full request dtails won't be kept for long.

Manishearth
  • 8,237
  • 5
  • 34
  • 56
  • I'm not sure that using GET opens one up for CSRF attacks any more than POST does. Reference: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) – Abe Miessler Oct 07 '13 at 17:42
  • As a webmaster, we have to go out of our way to log POST data, but logging URLs with query parameters, such as this GET request, is automatic. – Michael Hampton Oct 07 '13 at 17:54
  • Yeah I get that part. I was just referring to the CSRF vulnerabilities. – Abe Miessler Oct 07 '13 at 17:57
  • 1
    @AbeMiessler Some kinds of CSRF attacks are not possible with POST (like the image one). POST CSRF requires the user to click a button or JavaScript. If I am CSRFing a site via a social network or a forum, the image attack is the only one I have. But yes, you should protect yourself from CSRF with tokens, not by switching to POST. – Manishearth Oct 07 '13 at 17:57
2

Yes, it is definitely still an issue. The browser history is not the only place URL parameters can be logged, but the server will likely log them, and intermediate proxies may log them as well.

Sensitive data such as user credentials should be POSTed as form data, not passed in the querystring.

Xander
  • 35,525
  • 27
  • 113
  • 141
2

GET requests (by protocol definition) must be "idempotent", which means no side-effects. In this case, changing your session state to "logged in" instead of "not logged in" is an example of a side-effect.

Much about the way browsers and servers and proxies work rely on this principle of GETs not having any side-effects, so violating this principle means you could run into difficult-to-diagnose problems down the road.

Always use POST when what you're doing changes the state of something, even if you don't actually have any data to POST. Just do it.

Community
  • 1
tylerl
  • 82,225
  • 25
  • 148
  • 226