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.

vsespb
  • 29
  • 3
  • possible duplicate of [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) – gowenfawr Oct 17 '14 at 14:21
  • 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
  • @gowenfawr it's completely different questions, both related to web authentication on client side. imho. – vsespb Oct 17 '14 at 14:38
  • @vsespb I commented before you update the question, – elsadek Oct 17 '14 at 14:39
  • Okay, in that case this just makes no sense at all. If the attacker can glean the credentials, they can use GET or POST, either way. If the server side code handles GET and POST data equivalently, no difference. If it doesn't handle GET because it expected POST, then it's like a blank submission, no problem. What "hidden GET image on attacker's site" do you imagine is going to magically grab credentials from the user's browser? It doesn't work that way. – gowenfawr Oct 17 '14 at 14:59
  • @gowenfawr attacker submits his own password. – vsespb Oct 17 '14 at 15:16
  • @vsespb attacker can do that via GET or POST. Again, no difference unless app doesn't parse GET, in which case it either denies login (correct) or completely screws up and grants login - at which point the problem of a program handling bad input is the problem, not GET or POST. – gowenfawr Oct 17 '14 at 15:22
  • Difference between GET and POST: Attacker can own a site which victim visiting. Attacker can insert hidden IMG or IFRAME with GET URL with attacker's password and login. This way victim will be aut-logged-in using attacker password in our web application. With POST it's this is not possible (at least with IMG). – vsespb Oct 17 '14 at 15:35

3 Answers3

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.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
  • 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.

atk
  • 2,156
  • 14
  • 15
  • pls read http://en.wikipedia.org/wiki/Cross-site_request_forgery#Forging_login_requests - 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?

Community
  • 1
vsespb
  • 29
  • 3
  • 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