Avik’s Ruminations

So Twitter was hit by a Cross Site Request Forgery (CSRF) attack earlier today.  Together with a Cross Site Scripting (XSS) attack earlier in the week (the hover-and-you’re-infected worm), this hasn’t been a good few days for twitter, or indeed for web security.

I’m surprised at the simple and basic nature of these attacks. For a high traffic site such as twitter, one would expect more due diligence. Every penetration tester I know would have found these in a few minutes. It also goes to show how oblivious most web programmers are to attacks of this nature. While the the basics of XSS attacks are better known among developers these days (though that didn’t prevent the XSS at twitter a few days ago), the nature of CSRF vulnerabilities does not seem to be very well understood.

The attack today was very simple. You clicked a link, which loaded a few lines of javascript in your browser. The script then created two iframes, and set the src attribute of the iframes to an url of http://twitter.com/share/update?status=[message goes here]. It did this twice; once with the message being a link to the page hosting the javascript, and again with a rude text. If you’re logged in to twitter in your browser (which you’re likely to be if you’re clicking the link while reading twitter), then, as the iframe loads, your tweet gets published. Every one of your followers then sees these tweets in their timelines, and when they click the link, the worm propagates through their followers.

Note that this vulnerability wouldn’t necessarily have been prevented if twitter’s publishing url had been a POST rather than a GET. Another suggested solution is to verify the referrer, but that is a very weak form of protection. In particular, it will not work over HTTPS. The canonical method of preventing a CSRF is to add a hidden variable with a secure random token when a form is generated, and then checking that token when the form is submitted. This verifies the intent of the user to submit the form.

In a rich internet (flex/silverlight/ajax based) application however, the server does not generate a form for each submission. Rather, the token must be sent and saved a the client at the beginning of a session, and then sent back for each critical security sensitive operation. It’ll also be obvious that the protection against CSRF implies keeping state on the server between requests, which means there are scalability questions. This needs to be considered for any distributed deployment of the web servers in a cluster.

As you can see, sometimes a CSRF attack may be simpler to implement than an XSS. Also, there’s an enduring myth that if a website is protected against XSS, it does not need to worry about CSRF. That is clearly not the case, as was evident today. An XSS vulnerability is not required in order to exploit a CSRF issue.

There are many other websites that continue to be affected by CSRF issues. If you write web apps for a living, please take a minute to learn about CSRF attacks, and consider your application in light of these issues. Ruby on Rails can add automatic CSRF protection to your app. For java apps, the OWASP CSRF Guard can help you implement this protection.