Do login forms need tokens against CSRF attacks?

Question

From what I've learned so far, the purpose of tokens is to prevent an attacker from forging a form submission.

For example, if a website had a form that input added items to your shopping cart, and an attacker could spam your shopping cart with items you don't want.

This makes sense because there could be multiple valid inputs for the shopping cart form, all the attacker would have to do is know an item that the website is selling.

I understand how tokens work and add security in this case, because they ensure the user has actually filled in and pressed the "Submit" button of the form for each item added to the cart.

However, do tokens add any security to a user login form, which requires a username and password?

Since the username and password are very unique the attacker would have to know both in order for the login forgery to work (even if you didn't have tokens setup), and if an attacker already knew that, he could just sign onto the website himself. Not to mention, a CSRF attack that makes the user log himself in wouldn't have any practical purpose anyway.

Is my understanding of CSRF attacks and tokens correct? And are they useless for user login forms as I suspect?

Solution 1

Yes. In general, you need to secure your login forms from CSRF attacks just as any other.

Otherwise your site is vulnerable to a sort of "trusted domain phishing" attack. In short, a CSRF-vulnerable login page enables an attacker to share a user account with the victim.

The vulnerability plays out like this:

1. The attacker creates a host account on the trusted domain
2. The attacker forges a login request in the victim's browser with this host account's credentials
3. The attacker tricks the victim into using the trusted site, where they may not notice they are logged in via the host account
4. The attacker now has access to any data or metadata the victim "created" (intentionally or unintentionally) while their browser was logged in with the host account

As a pertinent example, consider YouTube. YouTube allowed users to see a record of "their own" viewing history, and their login form was CSRF-vulnerable! So as a result, an attacker could set up an account with a password they knew, log the victim into YouTube using that account — stalking what videos the victim was watching.

There's some discussion in this comment thread that implies it could "only" be used for privacy violations like that. Perhaps, but to quote the section in Wikipedia's CSRF article:

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

Emphasis on "novel attacks". Imagine the impact of a phishing attack against your users, and then imagine said phishing attack working via the user's own trusted bookmark to your site! The paper linked in the aforementioned comment thread gives several examples that go beyond simple privacy attacks.

Solution 2

Your understanding is correct -- the whole point of CSRF is that the attacker can forge a legitimate-looking request from beforehand. But this cannot be done with a login form unless the attacker knows the victim's username and password, in which case there are more efficient ways to attack (log in yourself).

Ultimately the only thing that an attacker can do is inconvenience your users by spamming failed logins, when the security system might lock out the user for a period of time.

Solution 3

OWASP has a dedicated section in their CSRF documentation adressing login-CSRF and why/hows to prevent it.

Basically, in login-CSRF a user tries to login to a website as themself but they actually get logged in as the attacker. The attacker then has access to any data the user thinks they may be entering/changing privately in their account.

Key points from the article:

---

How login-CSRF is dangerous:

if an attacker uses CSRF to authenticate a victim on a shopping website using the attacker's account, and the victim then enters their credit card information, an attacker may be able to purchase items using the victim's stored card details

How to address it:

Login CSRF can be mitigated by creating pre-sessions (sessions before a user is authenticated) and including tokens in login form.

And finally:

Remember that pre-sessions cannot be transitioned to real sessions once the user is authenticated - the session should be destroyed and a new one should be made

Note that this mitigation approach also prevents session fixation vulnerability since regenerating session after login is part of this approach.

Comments

[AbiusX]

They can hijack your router, because you probably use default password on that, and its not CSRF-protected for login.

[php_learner]

Wow Super fast reply! Thanks alot! Now I can continue building my website confidently.

[Tails]

Do make sure that any other 'pre-authentication' action also has sufficient CSRF protection. For example, a 'forgot my password' link that accepts an email address could be a source of annoyance. Incorporate a session token or use a CAPTCHA in all such situations.

[squiddle]

Login CSRF can still be used for attacks on the privacy of the user seclab.stanford.edu/websec/csrf/csrf.pdf

[Waihon Yew]

@squiddle: That's quite an interesting paper, thanks for the link. But it hinges on logging the user in with an account under the attacker's control and assumes that the user will not realize something is not right and assumes that the user is going to produce sensitive information which is then going to be stored on the server. So IMHO it is quite less serious than "classic" CSRF.

[squiddle]

@Jon Yes, it can be less serious, but in the end it can be more than just inconveniencing, namely privacy invasion. Every service has to define their threat model themselves and handle accordingly. To do that you need at least be aware of the possible threats. That's why i added my 2 cents.

[A. Wilson]

How does CSRF protection help? Is there anything preventing the attacker from asking for his own CSRF token and just submitting with that? Since no authenticated session exists, there's no reason for the web server to prefer one token over another.

[natevw]

"Is there anything preventing the attacker from asking for his own CSRF token and just submitting with that?" — Yes! That's the whole assumption behind CSRF prevention logic. Browsers did/do allow a form submission to target another origin, but they have never [intentionally] allowed JS to read data across sites, except now via opt-in CORS. Unless you set up CORS wrong, the attacker can trigger a form submission (which may include an existing CSRF token in cookies) but has no way of knowing the token to send the required second copy (e.g. in the body/headers). So CSRF code will reject.

[Gili]

I think your last comment is wrong (you misunderstood what A. Wilson was saying). We're saying that an attacker can load http://good.com/login.html in one client, parse the nested CSRF token, and then publish http://bad.com/login.html that contains a modified form that submits his username, password and token regardless of what the victim types in. CORS does not apply because you've got two separate clients: the attacker and the victim. So to reiterate the question: does the CSRF protection really work for login forms?

[natevw]

Yes, CSRF will protect a login form from cross-site request forgery. A proper CSRF token is cryptographically unique each time it is generated. Sure, the attacker can get a token themselves but it will still NOT MATCH the [potentially unset] cookie the victim has in their browser, and the attacker has no way to set said cookie without compromising a page on the good domain. (Your example seems a bit confused between CSRF and some sort of weird phishing attack, though, so I'm not sure if I'm answering your actual question…)

[samthebest]

Please could you expand on how they would "Ultimately the only thing that an attacker can do is inconvenience your users by spamming failed logins, when the security system might lock out the user for a period of time."

[Anonymous Platypus]

It is worth noting that WordPress doesn't use csrf on their admin panel login form.

[splashout]

What about a site where the accounts are created by an admin and not by some kind of public registration? Any risk there?

[natevw]

@splashout Change step #1 to read "The attacker convinces an admin to make them an account on the trusted domain" or "The attacker steals credentials from an existing account on the trusted domain"?

[you786]

I may be wrong, but it seems there is a significant threat if the user accidentally does anything related to purchasing items. For example, an attacker tricks the user into logging in to a website, and the user proceeds to purchase items without realizing they are in another account (think Amazon or similar). Now the attacker has access to saved payment information, can redirect the purchases, etc.

[Dariux]

@you786 - but user will see it is not him when he is logged in to amazon. Or the assumption is that he will not notice that it is him and will enter credit card information?

[you786]

@Darius.V If you are attacking a target directly, you can simply create an account with that person's name. Or, if you are attacking generally, you can create an account with a common name like 'John', or a name that wouldn't raise suspicion, like 'Guest'.

[HappyDog]

Downvoting as there are exploits that can be performed via a non-protected login form (as described in earlier comments and in the current top answer, by @natevw), so this is bad advice.

[Eric Grange]

How does that really protects anything ? The attacker can just obtain a valid CSRF token independently and submit it, since in that case he would already have everything required. Pre-sessions would be similarly useless, as the attacker can just leverage his own pre-session.

[Eric Grange]

@HappyDog the exploit described by the paper is closer to phishing, and the CSRF protection described in the paper only works if the attacker uses his browser to create the session, rather than the user's browser (as would be expected in such an attack).

[HappyDog]

Well, the question was "do CSRF tokens add any security to a login form", to which the answer is "yes, it protects against some types of attack". I'm not going to get in a discussion about how serious or likely those attacks are as, really, that's something that will vary from site to site, depending on the context. However, given the extremely low barrier to including a CSRF token on the login form (if you are already including them on other forms), I don't see why you wouldn't do it as standard and eliminate one class of threat, altogether.

[java-addict301]

@EricGrange due to same origin policy attacker could not set the CSRF token or pre-session on the forged request. developer.mozilla.org/en-US/docs/Web/Security/…

[java-addict301]

@EricGrange for more info, see developer.mozilla.org/en-US/docs/Web/HTTP/Headers/… and stackoverflow.com/questions/46288437/…

[Eric Grange]

@javaaddict301 the bypass I see is that the attacker can obtain a valid CSRF token from the user context, then submits this token + his credentials, from the same context he obtained his CSRF. The same origin does not apply, because it's all happening from the same origin and context. The protection from this would come from X-Frame-Options or CSP (frame-ancestors), rather than the CSRF.

[java-addict301]

@EricGrange Of course he can submit his own credentials from his own browser, but how does that hurt anyone else?

[Eric Grange]

@javaaddict not from his own browser, from the browser of any user passing through a website controlled by the attacker. The CSRF would only provide protection if the attacker browser was involved, the point is it needs not be.

[java-addict301]

@EricGrange if the user passes through a website controlled by the attacker, then the same-origin policy would prevent headers/cookies being set/sent to a different origin (the protected site). This is my understanding of why this mitigation works.