3

I recently realized that a few production web applications I was running. Diddnt have csrf protection for the login page.

It is only after authentications where csrf protection kicks in.

I was just wondering if there are reasons why developers/administrators would do this. Could it be due to the heavy load of tracking anonymous users? just thinking out load.

love to hear from all of yall!

cheers

Jiachen:)

jia chen
  • 710
  • 1
  • 6
  • 16

2 Answers2

1

CSRF is generally intended to protect against attacks executed under the assumption that the user is already logged in. So for example, malicious code is run in the user's browser while they have a session on an online banking or credit card account site OWASP CSRF documentation

Also interesting to note: a case can be made for CSRF being needed on login. As described here a login form not protected by CSRF leaves open the possibility of an attacker tricking a user into using an account they control. In this case they could harvest the victim's data or activity while logged in with that session. So it's probably best to add it in at the login.

Community
  • 1
  • 1
Paul Degnan
  • 1,972
  • 1
  • 12
  • 28
  • Paul, you describes the use of a CSRF token on the target url of the login form, not the login page which produced the login form. The question is about CSRF for the login page. – user2023577 Nov 18 '16 at 22:55
-1

CSRF involves silent exploits while the user is already logged in the browser (in another tab lets say).

If he is not, that request would not do anything, or simply reveal the attack by popping a login form.

So, to defend stupid web user from harming themselves, yeah I guess you could try to carry some antiCSRF token. But now, tell me how you begin that antiCSRF protection again? How could I possibly post my anticsrf token along the login form the first time? I would have to land on the / or something else to get the anticsrf token while receiving the login page. But most site have the login form straight in the first landing page. Hence the browser cannot present an antiCSRF token on first request (cannot use cookies, because it would be sent by browser even during the attacking request).

Anyway, that's my guess.

user2023577
  • 1,752
  • 1
  • 12
  • 23
  • "But most site have the login form straight in the first landing page" — Yes, and you could put a hidden input with the anti-CSRF token in there just like any other form. (With a cookie being set along with the page also containing the token (or a session with it in) for comparison when the form is submitted). – Quentin Feb 03 '16 at 23:12
  • That's a token for the login process (like j_security_check), not the login page. If the user continues loging in, the malicious action could still be performed. That's not adding protection. The goal is to not even render the login page (or at least clear the malicious request) because it was demanded from another site. Because it is practically not feasible, the requested malicious url is normally cleared upon login. If it is not, the app is vulnerable to the dumb user loging in a trusted site even if he didn't request it. – user2023577 Feb 03 '16 at 23:32
  • then with this, how to I prevent people from posting successful login request under another domain like say a phishing campaign. – jia chen Feb 05 '16 at 06:48
  • This is what I meant by "clear the malicious request". You cannot prevent them from logging in (your site doesn't know it is accessed through an attack workflow) but your site can refuse performing actions that were requested prior to login (and parked aside for post-login retrieval). You know, when you get redirected to the intended place after login. – user2023577 Feb 05 '16 at 12:36
  • This redirection to a potent action is precisely what you would have to sacrifice in order to be safe for dumb user under attack. Your app should almost never buffer a pre-login request if it didn't have the anti-CSRF token. Since the login page is not supposed to prepare a token, then it is impossible to bookmark any potent url. Only nullipotent urls (the safe read-only kind) are tolerable for post-login redirection without an anti-CSRF token. Anyway, that is pretty much the case if your app is well designed and uses POST-redirect-GET (PRG) pattern (because one cannot bookmark a POST). – user2023577 Feb 05 '16 at 12:36