these are tokens, but not CSRF tokens!

I have seen CSRF flaws in a wide variety of web applications over the yearsmost 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

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

TL/DR;

Red Team Leader at Fortune 1. I left my clever profile in my other social network: https://www.linkedin.com/in/malcomvetter