Login CSRF allows an attacker to force a victim to log in to an attacker-controlled account. It often shows up in vulnerability scans and bug bounties. If you see a Login CSRF vulnerability, should you fix it?
As defenders, we should only spend time fixing Login CSRF if attackers can use it to get something they want. For example, in the diagram below, the attacker wants to know that the victim searches for “llamas” on Google.
What’s the risk of Login CSRF?
Login CSRF can be low- or high-risk, depending on context. Most of the time it’s low-risk (e.g. “you search for Llamas!”), but it can also be the root of some ugly security problems, as we’ll see.
Why are most Login CSRF vulnerabilities low risk? Because the victim would realize they were logged into the attacker’s account. The OWASP CheatSheet section on CSRF describes this threat:
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.
The victim has to be fooled into doing something while using the attacker’s account. It now takes two separate acts of deception — one to get you to run the Login CSRF exploit, and another to get you to think it’s your account and do something sensitive in it.
Low-risk Login CSRF examples
If you were building a vulnerability scanner, Login CSRF would probably be listed as “low-risk”. The impact is usually more annoying than harmful. A 2016 SAML login CSRF bug in HackerOne was resolved without a fix:
We also discussed the Login CSRF… and we continue to feel that bypassing CSRF checks is an accepted risk for the user experience… This may change in the future if this begins to be exploited somehow.