Do login forms need tokens against CSRF attacks?

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?

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.

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.

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.