Using CSRF for Browser Hijacking

• Wed, 11 Oct 2006 at 03:56:45 GMT
• 7 Comments
• References

Something the Myspace worm taught us is that traditional safeguards against CSRF (cross-site request forgeries) are rendered ineffective when XSS (cross-site scripting) vulnerabilities exist in a web application. This is because malicious content injected into a web site can do a number of things, such as send HTTP requests and receive HTTP responses with Ajax, or even attack servers on your local network.

The result is that an attacker can perfectly mimic your actions using your own browser. It's something I've labeled browser hijacking, and it's one of the most dangerous examples of CSRF to date. It's also basically the same attack that I've been discussing in recent posts such as Cross-Domain Ajax Insecurity and The Dangers of Cross-Domain Ajax with Flash, except that XSS is an easy way around the same-domain restriction (without requiring an open crossdomain.xml policy).

Think XSS doesn't matter? Think again. As Johann from ThinkPHP puts it:

Buy one XSS, get a CSRF for free.

I've been speaking at conferences about CSRF for years, and one of the most alarming things I've noted during that time is that very few developers are aware of it, even conceptually. Jeremiah Grossman has noticed this, too, and he likens CSRF to a sleeping giant. RSnake calls it "the attack of the future." SANS is doing their part by trying to raise awareness.

Hopefully good guys will learn about it before too many bad guys do.