2

There is a sign-in form on the website, which submits login/password via POST method. Problem is, that code, which accepts login/password and authenticate user also accepts it via GET method (also, if user was logged in previously - user logged out and logged in as new user).

Question 1: Is that considered secure? Looks like no. Logged-in user could do some important operation in the account (fill a form with personal data, change password, upload some private data), during that an attacker could load hidden GET image on attacker' site and this image with re-login victim to attacker's account. So victim will upload private data into attacker's account.

However I cannot find evidences that it's considered unsecure or that it's a known forgery type.

Question 2: How this attack called? Where can I find info about it?

ATTENTION: In my question form submited via POST, but attacker construct a GET link (with attackers' password in GET). So it's not about designing application which submits password via GET.

  • No. Updated question with "ATTENTION:" notice – vsespb Oct 17 '14 at 14:24
  • If login is done over ssl, the attacker can't pull the user credentials easly since querystring in GET is also encrypted. – elsadek Oct 17 '14 at 14:27
  • It's still about the difference between GET and POST for web application security, whether it's you designing it or the attacker manipulating it. – gowenfawr Oct 17 '14 at 14:29
  • @elsadek how it's relevant here? it my scenario attacker submits his own password via user browser. – vsespb Oct 17 '14 at 14:36
2

Question 1: this is not considered secure for a number of reasons:

  1. The password can be seen on the URL

  2. The password can be seen on browser history

  3. All the passwords will be on server logs

  4. If the user logs on the site, and there's a link pointing to an external site, and the user clicks it, the password is leaked

  5. Spyware with URL monitoring will be able to get the password

I think the problem #3 is the most troubling. If someone gains access to the webserver, he will have all the passwords for every logged user, in plain text. I would fire the person designing this login scheme.

Even if the site employs SSL, those attacks can be done and get the passwords.

Question 2: This is not an attack, is a design error. It opens way to some attacks. Search for CSRF (or XSRF) for the easiest way to attack this design error.

EDIT: The above is true IF the authentication form sends data via GET, and it isn't the case.

If the attacker can create a form convincing the user to supply his login and password, it does not matter how secure the server-side is. Does not matter if the form is using GET or POST, HTTPS or HTTP, Javascript or Flash or Java applet or virtual machine running Linux over asm.js.

  • In my question form submited via POST, but attacker construct a GET link (with attackers' password in GET). – vsespb Oct 17 '14 at 14:22
  • for the first EDIT: no, attacker submits his own password. – vsespb Oct 17 '14 at 14:39
  • @vsespb if there is a csrf vuln, it doesn't matter if it's post or get. Csrf can be used on both just as easily. – atk Oct 18 '14 at 12:29
1

You are asking "what's bad about accepting (but not otherwise enabling) get based authentication?"

The answer: it's a bad practice that may eventually lead to a vulnerability, but it doesn't directly create a vulnerability.

For a vulnerability to exist, it must be exploitable in some way, and it must grant the attacker something they don't already have. In this cäae, how is the attacker going to exploit the get-based authentication?

  • a regular user will use the regular post-based authentication ui. S/he will not be affected by the issues with get-based authn.
  • an attacker who can set up their own get-based authn ui and who can convince your users to authenticate to his authn ui doesn't need doesn't need it to communicate to your server; s/he can have the users send their passwords directly to his/her server
  • an attacker who can change the behavior of your normal ui by rewriting the source code already has access to the source code and can do far worse.
  • an attacker who can change your ui at runtime, via an attack like xss already found a separate xss vulnerability and can do far worse
  • if the application also has a CSRF problem on the UI screen, then the attacker can log in as themselves instead of the regular user. However, that's CSRF, and the use of get or post has absolutely no bearing. CSRF can be performed against both get and post, and disabling get would not disable CSRF. The two topics have nothing to do with each other, except they both could exist in the login screen.
  • an attacker who can convince your login form to change from post to get for another user can take advantage of this vulnerability. Does the application hard code the method as post? If not, does it use any user input to decide whether to post or get? An attacker could email the victim a url to log in to your UI, and that url could contain the parameters necessary to cinvert from post to get - if they exist

So far as I can tell, there is no other attacker relevant to the behavior in question. Except for the questions in the last bullet, the attacker who can make use of this flaw is already more powerful than the flaw would grant. The attacker who doesn't have that power can't make use of this flaw.

All that said, it is a bad practice, and it should be corrected. Correcting it (and adding a comment in the code explaining why) will help prevent future developers on the application from making use of the get-based login and introducing a real vulnerability.

  • pls read en.wikipedia.org/wiki/… - key point that victim logged in using attacker's credentials. – vsespb Oct 18 '14 at 12:46
  • @vsespb as i mentioned in my comments and my answer, that attack depends upon the existence of csrf, which is unrelated to the reasons not to use get. Csrf can be used for post requests just as easily as it can be used for get requests. – atk Oct 18 '14 at 12:48
  • Yes, you are right that POST can have CSRF too, so question is indeed unclear. I'll update question. – vsespb Oct 18 '14 at 12:53
-1

If login form is vulnerable to CSRF (no matter POST or GET), this is unsecure and known type of forgery: "login CSRF" http://en.wikipedia.org/wiki/Cross-site_request_forgery#Forging_login_requests

related question: How to protect against login CSRF?

  • While csrf is a vuln to be concerned about, it is unclear from the question if it is related. The question at hand is "what's bad about accepting (but not otherwise enabling) get based authentication?' – atk Oct 18 '14 at 12:30
  • The website in question is vulnerable to "login CSRF" because it accept auth. via GET as well, as via PUT. – vsespb Oct 18 '14 at 12:42
  • Csrf is a separate issue. It can be performed on post as easily as get (note that the question doesn't talk about the http put verb, so i'm not sure why you are bringing that up). Just because the two issues exist on the same screen doesn't make them otherwise relared – atk Oct 18 '14 at 12:47
  • ok, you're right. updated answer. – vsespb Oct 18 '14 at 12:56

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.