In Praise of CSRF Tokens
I have seen CSRF flaws in a wide variety of web applications over the years — most of them aren’t all that relevant and worth discussing (which is why I rarely hear anyone talk about CSRF anymore). The flaws I have seen range from “nuisance” level, e.g. adding a product to an ecommerce shopping cart without the customer’s consent (but in theory the customer will see the product at checkout or at some point afterwards, so customer service may get involved and it may get expensive in terms of customer service labor sorting out the messed-up orders), to the “disastrous” level, e.g. adding a backdoor administrator account in a web portal.
But we rarely hear about real world attacks and breaches using CSRF attacks. Why?
One theory: because all the other classes of security defects are likely to be abused first.
Second theory: because the user will just get phished, use a weak password, or reuse passwords across several systems (all of which are extremely common).
My money is on the second theory first, but the first theory probably holds some weight, but that’s not what I am writing about CSRF tokens today. There’s another reason.
Correcting My Past Mistakes
First, to correct a mistake I previously held onto (and if I held onto it, maybe others did as well): when assessing applications, I would note the lack of a CSRF token/nonce mechanism on any part of the application EXCLUDING the authentication/login form. That was a mistake. To me at the time — prior to simulating adversaries red team style — the user knew the password and the attacker couldn’t, therefore the attacker couldn’t add the password to a form on the user’s behalf, just like the attacker couldn’t add the CSRF nonce/token to the form on the user’s behalf, because only the user’s browser knew the token value.
But that’s not always true. CSRF tokens on Login Forms are important, and red teaming has taught me that.
CSRF on Login Forms
Consider the situation where the attacker views the application solely as a means to steal the victim user’s credentials. Perhaps the attacker creates a lookalike website on a “good enough” DNS domain name, phishes the victim user, and the victim user proceeds to login with their credentials. For the extra special Midas touch, the attacker can log those credentials, and then write a new auto-posting HTML form to the victim user’s browser and have them log directly into the original victim application. They’ll have a valid session on the actual target application, and now the attacker will have their credentials. This will happen so fast that any non-technical victim will never know what happened and many technical victims may be distracted enough to ignore.
But this would NOT happen if CSRF tokens were required on the login form of the target application. The attacker may have the credentials from the phish, but not the CSRF token value, so the “automagic” login would fail. The Midas touch of the hack would be a little less golden and some victims may notice what happened. Incident Responders would be notified, credentials would be rotated, and breach objectives would fail to be achieved by the attackers. In other words: it would be a good day for the good guys.
Reused Tokens as Attack Indicators
Another situation: suppose the attackers attempt a password spray against the login form but fail to notice the intricacies of the CSRF tokens that get generated and invalidated after a single use. As the attackers fire off their spray, they are giving away a key piece of intel to the defenders when the CSRF token is invalidated after the first request and reused for the next 100+ requests — no matter how fast, how slow, or how distributed (source IPs) the attack is. This is a great opportunity for Blue Teams to hone in on the activity, add IP addresses to watch (or ban) lists, and learn about their attackers who are otherwise flailing loudly in the ether.
(All of this pre-supposes the CSRF tokens are not reusable — all bets are off in this case if they’re good for multiple requests across a wide time window.)
Sadly, most web applications that use CSRF tokens are pulling the tokens from frameworks that haven’t considered their value for security detection and response — only for prevention, so the event log data probably isn’t captured in a meaningful way. Blue Teams will need to duct tape and superglue something together.
MFA
And of course, the real solution is multi-factor authentication on the login form, but even in that case, CSRF tokens on the login form still prevent perfectly golden (undetected user experience), real-time, man-in-the-middle (MITM) attacks. They don’t stop real-time MITM, they just won’t result in the victim having a legitimate session into the target application on the first try.
TL/DR;
CSRF tokens/nonces are unsung workhorses for infosec and Blue Teams should probably monitor them more closely.
