7

I have noticed that WordPress doesn't have csrf protection for their admin panel login /wp-admin/. Does it actually posses any potential risk? Is there any possible ways there an attacker could exploit this?

Is it necessary to have csrf tokens for login forms?

Anonymous Platypus
  • 1,442
  • 3
  • 19
  • 34
  • Depends on your site and its function. Related: [How to protect against login CSRF](http://security.stackexchange.com/a/59529/8340). – SilverlightFox Jun 10 '15 at 12:58

3 Answers3

7

It is generally suggested that CSRF tokens are applied to login forms to prevent session donation attacks. The idea is that you can trick a user into visiting a link, and they become logged in under an account that you control. They then perform some action involving storing some secret information to the account, without noticing they're logged in as you, and that gets saved to your account.

A simple example might be a file upload site. If you can trick them into being logged in as you, they might upload a sensitive file into your account rather than theirs, and you can then steal that file.

For Wordpress this probably isn't so big a deal, because it's not particularly applicable to the functionality that Wordpress provides, and the wp-admin panel isn't really a "general user" area that an attacker would have a valid account for.

Polynomial
  • 133,763
  • 43
  • 302
  • 380
  • Session donation attacks sound very similar to session fixation attacks. Are these the same thing (with what I assume is UK pronunciation? ;-) ) – AviD Jun 10 '15 at 10:30
  • Btw, if I understand correctly, then a better / simpler solution is to simply kill / restart a new session during login, which is always a good idea anyway. But given that, the login form wouldn't need a CSRF token - which is designed specifically to protect use of the logged in session. – AviD Jun 10 '15 at 10:31
  • 5
    @AviD Not quite the same. Session fixation is where you set a session cookie in their browser before they log, but the application doesn't change the session ID on login, so you then know the session ID and can hijack their session. This gives you full access to their account. Session donation attacks involve using CSRF to log them into *your* account, not theirs, without them realising. – Polynomial Jun 10 '15 at 10:48
  • 3
    Ah I see! So instead of giving the victim "your" sessionid, you are giving them your credentials. So this attack isn't even really about the session at all, but about the account itself. Perhaps you can get them to add their credit card to your account.... Very interesting, thanks! – AviD Jun 10 '15 at 11:45
  • Scratch that, just looked it up. Though according to the original definition, it still focuses on pushing a (authenticated) session id - so the login form would be irrelevant. So I assume you are talking about a different variant, where instead of sending your authenticated session id, you are actually sending them your (known) credentials, and forcing them to login with your creds. Did I understand correctly? – AviD Jun 10 '15 at 11:57
  • 1
    @AviD Session fixation issues can be exploited to produce a session donation in some cases, but usually they're separate. You're correct about forcing them to log in with your creds though. – Polynomial Jun 10 '15 at 12:54
  • Session donation is when you donate your session id not your login credentials, this attack is called as Login CSRF. – racec0ndition Jun 10 '15 at 13:01
  • 2
    @Aatif It's also a form of session donation. The terminology is largely moot anyway - the point is the actual attack and its impact. – Polynomial Jun 10 '15 at 14:09
  • @Polynomial Never heard the term session donation before. Thank you introducing that.:) – Anonymous Platypus Jun 11 '15 at 06:07
4

The scenario you described, wherein, the login form doesn't not include a CSRF token may give rise to the situation where an attacker uses his own credentials to log the victim into the attacker's account and if the user is oblivious to which account he is logged in to, the attacker can see what actions the victim performed including as suggested above, any sensitive files the victim might have uploaded. This attack is called as Login CSRF.

Wordpress doesn't seem to think it poses a risk. Such attacks have been demonstrated against major companies such as Google and Yahoo. From Wikipedia:

Login CSRF makes various novel attacks possible; for instance, an attacker can later log into the site with his legitimate credentials and view private information like activity history that has been saved in the account. This attack has been demonstrated against Google and Yahoo.

In general, i would suggest having an anti-CSRF mechanism for the login form either checking Origin or CSRF Tokens among others.

The source of the wiki page above: http://en.wikipedia.org/wiki/Cross-site_request_forgery#Forging_login_requests

For more information and other attack scenarios, check http://www.ethicalhack3r.co.uk/login-cross-site-request-forgery-csrf/

racec0ndition
  • 581
  • 4
  • 10
  • `The attack methodology you described, wherein, the attacker uses his own credentials to log the victim into the attacker's account` - are you responding to the question or to another answer? You should respond to an answer in comments and not another answer. – Neil Smithline Jun 10 '15 at 16:05
  • @NeilSmithline actually i was responding to the question, i miswrote the answer it seems, my bad, edited. Thank you. – racec0ndition Jun 10 '15 at 18:14
0

Is it necessary to have csrf tokens for login forms?

In reference to Wordpress - No, it is not. Login pages are not susceptible to CSRF. The whole premise of CSRF is that the user is already authenticated to the app when the unwanted data is submitted.

Per OWASP:

"CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attacker's choosing. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application. "

For more information, please see: https://www.owasp.org/index.php/Top_10_2010-A5

k1DBLITZ
  • 3,953
  • 15
  • 20