Do login forms need tokens against CSRF attacks?

user_806835 0
Viewed 52418

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?

csrf token php
3 Answers

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.

user_65011900
Related