Login CSRF is low-risk and high-risk
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.
They had another login CSRF vulnerability in 2020 and fixed it, but gave it a low risk rating of 3.8. The Internet Bug Bounty awarded $300 to a login CSRF in Phabricator and described the low severity of vanilla login CSRF in these terms:
It only allows an attacker to force the victim to log in to an account they control, which might be the first step in a more interesting attack but isn’t clearly valuable on its own.
High-risk Login CSRF examples
High-risk Login CSRF bugs lead to account takeover when OAuth and SAML allow an attacker to associate a victim’s service provider with the attacker’s identity provider that the victim is CSRF’ed into. It’s not common, but it’s dangerous.
Rockstar games ranked a Login CSRF vulnerability as 8.7 CVSS because it allowed the attacker to take over the victim’s account. AirBNB paid $5000 in 2016 and Uber $8000 in 2017 for similar vulnerabilities where Login CSRF combined with an open redirect broke OAuth 2.0 and allowed for account takeover.
This is why Login CSRF vulnerabilities don’t fit neatly in a single classification. Unfortunately, identity protocols like OAuth and SAML make introducing Login CSRF easy.
Login CSRF is a footgun for identity protocols
When you use SSO protocols like OAuth and SAML, you should consider whether you care about Login CSRF. Many configurations make the usability tradeoff of making signing in easier while making Login CSRF possible. One type of configuration is vulnerable “by design” is IdP-initiated SSO.
IdP-initated SSO is when you log in directly from UI hosted by the “identity provider” (e.g. Okta, Google, Facebook, etc.) before interacting with the end service. If you think of a dashboard with tiles that you can click on to log into sites, that’s IdP-initiated SSO.
Whenever an identity protocol allows you to log in directly via the identity provider without user interaction, it’s susceptible to Login CSRF. We see it show up with multiple popular identity protocols, including OAuth 2.0, SAML 2.0, and “magic links”.
Login CSRF in OAuth 2.0
The IETF OAuth 2.0 Standard and the OAuth 2.0 Security standards describe how to prevent Login CSRF with the state parameter. If you don’t use a state parameter in OAuth 2.0, you’re likely vulnerable to Login CSRF. The state parameter cannot be bound to a pre-existing session with iDP-initiated authentication, because there is no pre-existing session.
Slack patched a “state missing on Google OAuth 2 Login CSRF” bug bounty report but said it did “not constitute a plausible exploit, so is not eligible” for their program. New Relic closed a similar bug without fixing it, acknowledging “the state parameter is intended to prevent this sort of CSRF” but they “marked it as Won’t Fix due to the low risk of a login CSRF”.
Clearly, Login CSRF is part of the OAuth 2.0 threat model (“The ‘state’ parameter should be used”) but because Login CSRF is usually benign it’s frequently omitted without serious consequences.
Login CSRF in SAML 2.0
IdP-inititated SAML flows are essentially Login CSRF as a feature. If you login in a user and they don’t need to interact with wherever they’re logging in first, then whatever authentication claim you hand to the attacker can be handed to the victim. According to Auth0:
IdP-Initiated flows carry a security risk and are therefore not recommended…enabling this flow opens the possibility of an Login CSRF attack
From what I can tell, every SAML implementation that support IdP-initiated login should be vulnerable to Login CSRF.
Login CSRF and Magic links
“Magic links” are URLs that automatically log you in when you click them. No username, password, or 2FA — you just click the link in your email. Logging in without a password seems like such an obvious user experience win that people tend to say “Wow? Why has no one thought of this before?”
https://example.com/magiclink?magictoken=<psuedorandom-string>I built NoPassword in 2012 and won a Twitter Hack Week prize for a magic link prototype. Before then, and since then, other people have discovered the idea of magic links, including a company named “Magic”. Many sites offer them as a first class login feature, like Slack.
A URL that automatically logs you in is iDP-initiated login, although it’s easy enough to fix an interactive “Magic Link” flow by setting a cookie when the user enters the email address and validating the same value in the link. That said, I didn’t do this in NoPassword and nobody in 145 comments on Hacker News even mentioned it.
Login CSRF is low-risk and high-risk
Security is difficult to measure. We reduce the complexity of individual vulnerabilities into terms like Login CSRF to make them easier to talk about and count. Login CSRF is an exquisite example of how our analysis and measurement can be confused. It’s usually low risk — a pawn in the game of usable authentication. But it can be a viable target for a “game over” account takeover. The best bet for your next Login CSRF report is to figure out which one it is as quickly as you can.
