Press enter or click to view image in full size
As security professionals, we often treat Cross-Site Request Forgery (CSRF) as a solved problem. We implement the Synchronizer Token Pattern, ensure our frameworks have built-in protections, and move on. But what happens when that trusted pattern is built on a flawed foundation?
In a recent assessment, I stumbled upon a fascinating misconfiguration that turned a standard CSRF defense on its head. It served as a powerful reminder that the implementation of a security control is just as critical as its existence.
A Quick CSRF Refresher
First, let’s quickly recap what a standard CSRF attack is. In short, it’s an attack that tricks an authenticated user into performing an unwanted action on a web application. For example, an attacker could host a malicious webpage with a hidden form that automatically submits a request to your-bank.com/transfer?to=attacker&amount=1000. If you are logged into your bank and visit that page, your browser will happily submit the request with your session cookies, and the bank will process the transfer.
The most common defense is the Synchronizer Token Pattern.
- The server generates a unique, secret token for a user’s session.
- The server embeds this token…