This article is more than 1 year old
Cross-site hacks and the art of self defence
The new browser wars
And what if you're at work or connected to the virtual private network? Your browser can go after the corporate portal. Do you have single sign-on? That means you're logged into every web application on your intranet, and your renegade browser can go after any of them.
Using CSRF, an attacker can attack all of these targets and can do just about anything you can do through your browser. All these attacks can be done remotely and basically anonymously.
OK, so what can you do to protect yourself? First, don't stay logged into websites. You have to actually hit the log-out button, not just close the browser. Next, stop CSRF from getting to your critical websites by using a separate browser to access them. Companies are increasingly using separate browsers for accessing intranet applications and the internet - more should follow suit.
If your web application is attacked by a CSRF, all you'll see is normal transactions being performed by authenticated and authorised users. There won't be any way to tell that the user didn't actually execute the transaction. Probably the only way you'll find out that you have a CSRF problem is when users start complaining about phantom transactions on their account. The attacker can cover their tracks easily by removing the attack once it has worked.
Taken alone, CSRF attacks are simple and powerful. However, most attackers use CSRF and cross-site scripting (XSS) in conjunction. Together, these two techniques allow attackers to invade a victim's browser and execute malicious programs using the credentials of site the user is logged into.
This combination is devastating, and I'm frankly surprised that a cross-application CSRF-XSS worm hasn't already been developed.
The best solution to CSRF is to require a random token in each business function in your application. You can generate the random token when the user logs in and store it in their session. When you generate links and forms, simply add it to the URL or put it in a hidden form field. For example:
Requests that show up without the right token are forged and you can reject them. If you want to add protection without modifying code, the OWASP CSRFGuard is a filter that sits in front of your application and adds token support.
Whatever steps you take to protect yourself - whether it's the physical act of using different browsers or taking a token-based approach with the OWASP filter, make sure you do something - and soon. It will be difficult to roll out protection against forged requests once an attack has started.
Jeff Williams is the founder and CEO of Aspect Security and the volunteer chair of the Open Web Application Security Project. His latest project is the Enterprise Security API, a free and open set of foundational security building blocks for developers.