It was only three days ago that I wrote about the almost hopeless challenge of web security, specifically around new vectors with cross-site scripting attacks. Today came news that an XSS vulnerability had been found in the RubyOnRails development framework – and that applications built on the framework, such as Twitter and Basecamp, were vulnerable to XSS attacks.
The vulnerability was discovered by Brian Masterbrook. He probed Twitter with some Unicode characters and found it vulnerable, tried the same thing on Basecamp and found it vulnerable, and then deduced that it must be a problem with RubyOnRails. He has an excellent and detailed write-up on his site about the process he went through. If you are running RubyOnRails anywhere, stop now and read his post as well as the security notice from the Rails developers and get your servers updated (the patch is in the notice, it will be in the release branch ‘today or tomorrow’).
There are a few parts to this story. The first part is that it is great that Brian just happen to be one of the ‘good guys’. We find out about this vulnerability because he put the effort in to inform the parties involved and to get a fix out. We could have easily found out about this the hard way.
The second part is the poor response he got from the guys at Basecamp . I use Basecamp, I have two accounts there and we use it somewhat internally at Techcrunch. Not anymore. Their response to a major security issue does not inspire any confidence, at least not enough confidence that I would feel comfortable having my personal data residing on their servers (for more details on their response, see Brian’s post). Twitter I am not as concerned about – they seem to have their act together in terms of responding to issues promptly (they have had their fair share of security issues, no link required there I think). Brian originally discovered this issue almost a month ago – he seems to have spent a lot of time just communicating with these vendors.
Third part – learning from the mistakes of others. Point one would be: if you are a vendor of an application, get your shit together so that when one of the good guys wants to be able to tell you about a vulnerability he or she discovered, you don’t lose a day arguing about if an email had been sent or not (I am looking at you too Apple – that post will come later). ‘Getting your shit together’ involves having a clear contact page for security issues, a PGP key (afterall, you don’t want everybody reading about how your site is vulnerable), and perhaps a few lines of policy on what you will do if a security issue is discovered (‘its not our fault’ is not a policy).
Point two (of the third part – you following?) is about what developers can learn. If you scan the patch file that the RubyOnRails guys sent out you will see one word consistently popup in the code – ‘verify’. That is what this issue, and what almost all security issues, come down to – not trusting user data and making assumptions about what data your application will receive. The majority of applications take a blacklist approach – ie. check for that, check for this, filter, block, filter .. filter. The more correct approach is to assume that everything coming in from anywhere is going to completely screw you up, and then allow only what the application can handle and only what you expect. If your application is all in English, and you start seeing some funky Unicode characters that were previously only used by a long-forgotten African tribe – there is a safe bet that somebody is messing with you. Blacklist vs Whitelist.
Something else I noticed that has come out of this incident. The RubyOnRails notice attributes the cause of this vulnerability to:
“Due to the way that most databases either don’t accept or actively cleanse malformed unicode strings”
Oh, im sorry? Its the database! Remind me next time I pick a database server to use that I choose one that will filter and anticipate all my user data for me (hint: I was being a sarcastic, if you are a CIO who just picked up the phone to Oracle to ask for the XSS-proofing module, put the phone down). It is easy to shift blame – but this would be like the Microsoft IIS 4.0 team blaming Dennis Ritchie for all their buffer overflows.
We are going backwards with security. It is 2009 and vendors aren’t responding properly and blame is being shifted. In the meantime, RubyOnRails is now seeing a surge in downloads from Russia and various other places – not because those new users want to build apps, but because they want to own yours.