Real-word CSRF hack

January 18, 2008

Here’s another (slightly late) item from my “to blog” folder that I’ve been trying to clear now that this site is live…

Designer gets his domain hijacked and held for ransom.

Despite the usual “this is so bad”, and “sue the b’stard” comments, it’s worth digging into this story for the security details.  (un)Luckily, the designer discovered the way that his domain was hijacked, which many times isn’t usually the case - after a successful hack, attackers can be pretty quick to clean up after themselves so as not to reveal the technique (or leave incriminating evidence).  Turns out it was a well documented and discussed (at least in webapp security circles) vulnerability in GMail where via CSRF an attacker can inject filter(s) that manage email.

First up, what is CSRF most people will ask.  CSRF stands for Cross Site Request Forgery, and is a security vulnerability in many websites, although it’s alternative name of “session riding” is probably more appropriate.  Basically, HTTP is a stateless protocol so a webserver processes each incoming request without knowledge of those previously.  However, if that were the case, lots of webapps wouldn’t be possible because, for example, how would it know if you were logged in, what items were put into a shopping cart, settings, etc.  To overcome this, session cookies are used to give the application a token to access the users’ state on the server.

CSRF comes in because browsers automatically send cookies for each request to the webserver that set them (depending on expiry, domain and path matching).  Although this is appropriate when the user is browsing on the website in question, it also happens if the request is sent from a different website via, for example, an IMG link, XSS, JavaScript, XMLHttpRequest.  This malicious, forced, and potentially silent request for all intents-and-purposes looks like a legitimate action made by the user - such is the way of the web.

There’s a few ways to mitigate against this vulnerability, from both the user side and that of an application developer. 

As a user, the advice is quite simple - when you are done with a website, i.e. you’ve finished reading your email, logout.  Do this before you go off and visit other sites, and as always be careful of what emails you open or any links you click on within them.  This simple logout operation (should) clear your session cookies, thus removing your state/identity on the server (although I’ve reviewed plenty of applications where this fails to happen correctly).  The basic premise is to reduce the window of exposure to while you are logged in, and not have it extended any longer than it needs to be as you go about browsing other sites. 

If you are really paranoid, one possible thing to do is use a separate browser (e.g. FireFox if you use IE as your default browser or vice-versa) for “sensitive” sites like banking, email, stock, etc, and don’t use that browser for visiting unknown sites.  For the really really paranoid, using a browser within a virtual machine for “normal” browsing (like VMWare’s Browser Appliance, although you could build your own VM) limits the opportunity for the browser, but also allows separation from the physical machine so it can’t access documents, data, or infect it with malware.  This is probably the approach Google might be planning with their GreenBorder acquisition. There’s still some risk with either of these approaches, but it should drastically reduce that risk. 

As a developer, there’s a few ways of dealing with CSRF, many of which are detailed in an excellent paper by iSecPartners [warning PDF link].  One simple mechanism is to request user input which only they would know(and couldn’t be cached, pre-supplied, pulled fin rom elsewhere - e.g. a users password, CAPTCHA, codeword, etc) before any particularly sensitive operation.

This certainly is an important vulnerability to be aware of, both for users and application developers, and unfortunately I feel that although it’s very widespread it’s also not being addressed nearly as much as it should.  With all the other “low hanging fruit”, and with examples of cluelessness like this, we’ll probably see more stories of domain/email/bank accounts/stock trades being taken over before long.

Posted in Security