Archive for the ‘CSRF’ tag
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.
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.