Image via Wikipedia

I’ve briefly covered Cross Site Request Forgery (CSRF) before on this blog when talking about the exploit I discovered in About.com polls. It is one of the most common vulnerabilities on the web as it exploits the inherent way in which browsers handle HTTP cookies. It is also (for the most part) easily preventable if you know what you are doing.

A few weeks ago, I was thinking about a type of CSRF attack that is less well-known, but could potentially be very annoying for an end-user: Logout CSRF. Most (if not all) websites that have some form of login also have a method for handling logout, and usually this method involves the user simply clicking on a link. The link takes the user to a page which destroys their session cookie, and thus they are no longer logged in as a user.

When you click on a link, an HTTP GET request gets sent to the URL that the link is pointing at, complete with any cookies that the browser might have for that URL’s domain. The browser also uses HTTP GET to load other parts of a webpage, like images or included JavaScript files. So, if someone were to include an image in a website A that pointed to the logout URL of website B, anyone visiting that website A would get logged out of website B (if they had a valid session on website B).

What has this got to do with Google? Well, Gmail is vulnerable to this type of attack. The URL for logging out of Gmail is “https://mail.google.com/mail/u/0/?logout“, and any HTTP GET request sent to that URL will destroy your Gmail session cookie. To see it in action, log into your Gmail account and visit this page: http://cryptogasm.com/gmail-logout.html (I’ve purposefully not made it a link, so just copy it and paste it in your browser’s address bar). Once the page has loaded, refresh your Gmail account, and you should be logged out. (Note: This attack does not affect your account in any other way, all it does is log you out).

I alerted Google over this fact, and it seems many people have done so in the past, because I got referred to a section of their bug documentation specifically addressing this problem. What stands out for me is this line:

At this time, the ability of malicious web sites to log users out of unrelated web applications is essentially unavoidable; it is a consequence of how the web is designed, and cannot be reliably prevented by any single website.

Whilst it is true that CSRF is a consequence of how the web is designed, it is completely untrue to say that such an attack is “essentially unavoidable”. On the contrary, Logout CSRF is easily thwarted by including a unique token in the logout URL that is purposefully hard for attackers to guess or brute-force. Many sites do this, including the WordPress admin panel from which I’m writing this article. This way, only an HTTP GET request that includes a valid token will log the user out.

In Google’s rationale for essentially ignoring this problem, they cite a blog post by one of their employees, Chris Evans. In it, he claims that it is “futile” to defend against Logout CSRF since there are other methods of destroying a session cookie, like cookie forcing and cookie bombardment. Whilst this is true, note that both these techniques need some level of skill to implement, whereas the simple Logout CSRF I created took me less than a minute to get working. If you limit the methods that can be used to successively perform an attack, you limit the number of attacks.

This sort of thing makes me wonder if Google really understand CSRF, or whether they really don’t care about their users.

This is a very good article from Webmonkey explaining why the vast majority of the web is stuck using the HTTP protocol, which sends all information (including usernames & passwords) as plaintext, as opposed to HTTPS, which encrypts it. Whilst HTTP is fine for a lot of static websites, it is very insecure for websites that have access to personal information, or that are accessed using some kind of password.

The problem of HTTP based login sessions doesn’t stop with passwords being sent in the clear though. Whilst users usually only enter their password once per session, their associated session cookie is sent with every request, and so stealing this cookie is a lot easier than stealing the password. The stolen cookie can then be used to hijack the current session of that user.

The main reasons why most websites don’t move to HTTPS has nothing to do with complexity in setup, but rather the high cost of digital certificates, slower speeds of transfer (due to the initial key exchange), and the inability for browsers to cache web pages. So for now, it doesn’t seem likely that your favourite forum or blog (even this one!) will switch to HTTPS.

So what can you do? Well, if you do use websites that require passwords to access, or that store session cookies on your computer, make sure you are using a network that is trusted. In other words, use a network that you know (such as one at your home or work), and in the case of wireless networks, make sure it is secured by at least WPA. Public WiFi access points that are usually found in coffee shops should be avoided, mainly because they are susceptible to Evil Twin attacks.

For users of Firefox who are more concerned about security and less about speed or caching, I highly recommend HTTPS Everywhere, an addon that forces HTTPS on popular websites that are usually served over HTTP.

Any online poll that doesn’t require some form of registration is going to run into big problems when trying to limit users to one vote each. The standard procedure of many online polls is to assume that each IP address constitutes one person, and thus the poll is limited to one vote per IP address. Whilst this assumption is of course flawed in both aspects (one IP address can be assigned to multiple people, and one person may have access to multiple IP addresses), it is a good one to have when trying to limit the amount of “voter fraud” in anonymous online polls. However, relying on this assumption alone as a preventative measure is not even close to good enough.

Other methods for limiting people to one vote each usually rely on the ignorance of most internet users in terms of how browsers work. For instance, a relatively common method I have seen is to set a cookie when the user votes, and then to check the status of that cookie whenever they make a subsequent vote. If the cookie is set, the vote is disallowed (though this action may not be communicated back to the user), and if the cookie is empty or non-existent, the vote goes into the system. Since cookies are stored on the user’s computer and not the poll server, they can be easily (in most cases) deleted by the user in question. In fact, many browsers have methods built-in to them to deny cookies from certain websites¹, and some have extensions that can easily be used to perform repetitive votes in an online poll.²

If preventing as many instances of voter fraud as possible is your aim, then using methods that depend on client-side procedures is a big mistake. Limiting the poll to one vote per IP address is the best way to go if you don’t want to code a registration system, but the additional security measures should not be overlooked.

About.com is a large information & advice sourcing site owned by The New York Times Company.³

About.com’s content is provided by a large group of writers, who each write for a specific topic, ranging from African History to Yoga. According to Alexa⁴, About.com is ranked as the 64th most visited website on the internet, so you would expect their design team would know a few things about how the internet works. Sadly, when it comes to anonymous online polls, this is not the case.

Every year, About.com run a “Readers’ Choice Awards” competition, where their readers vote in various polls for each topic. The medium for most polls used appears to be a custom-made form, the processing of which is done on an About.com server. The poll I chose to do my analysis on was the “Best Web Design Overall” poll at the About.com Web Design / HTML topic. I thought it a good poll to choose given that at the time it had received relatively few actual votes, and the topic ties in nicely with the security of online polls.

Using Paros (a nifty proxy tool that allows you to view raw HTTP requests / responses), I captured the exact requests sent to the About.com server that were responsible for making a vote (my vote went to the site in last place, which at that point had only 3 votes).

GET http://webdesign.about.com/gi/pages/poll.htm?linkback=http%3A%2F%2Fwebdesign.about.com%2Fb%2F2011%2F02%2F11%2Fvote-for-the-about-com-readers-choice-awards.htm&poll_id=6765141284&poll=4 HTTP/1.1
Host: webdesign.about.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
Referer: http://webdesign.about.com/b/2011/02/11/vote-for-the-about-com-readers-choice-awards.htm
Cookie: TMog=B2FKLs2J20kA0972; zFD=B2IPB2F20B20R20B00R02; gs=webdesign; jsc=13; Mint=B2IMZK0U20SA18BF; zBT=0; pc=30; zRf=-2; zFS=B2IB0B20B10B00B01
 
GET http://guidepolls.about.com/webdesign/6765141284/results.js?linkback=http%3A%2F%2Fwebdesign.about.com%2Fb%2F2011%2F02%2F11%2Fvote-for-the-about-com-readers-choice-awards.htm&poll_id=6765141284&poll=4 HTTP/1.1
Host: guidepolls.about.com
Accept: */*
Accept-Language: en-us,en;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
Referer: http://webdesign.about.com/gi/pages/poll.htm?linkback=http%3A%2F%2Fwebdesign.about.com%2Fb%2F2011%2F02%2F11%2Fvote-for-the-about-com-readers-choice-awards.htm&poll_id=6765141284&poll=4
Cookie: TMog=B2FKLs2J20kA0972; zFD=B2IPB2F20B20R20B00R02; gs=webdesign; jsc=13; Mint=B2IMZK0U20SA18BF; zBT=0; pc=30; zRf=-2

For security reasons I have removed the User Agent information from the two HTTP requests above.

What is very interesting is that my vote was sent (in the first request) using a GET method rather than a POST method that is usually associated with forms. The resulting HTTP response including a call to a JavaScript file (second request), and it was this second request that seemed to do the actual vote. One thing I did notice is that the poll did not rely on Cookies, but instead seemed to record my IP address with my vote, and disallowed any subsequent votes from my connection. However, this limit of one vote per IP address was the only “security” feature in place on the poll.

Knowing that the poll used a GET request, and that I could not simply manipulate the poll by sending multiple requests from the same IP address, I set up a fake HTML image tag in the footer of a website I run. The URL of the image would be the voting URL for my chosen poll option (i.e. the one in the second request above), and I added some custom CSS to the image that would hide it from view, so that no browser would show a missing image icon and draw attention to the code. The resultant code looked like this:

This type of exploit is known as a Cross-Site Request Forgery (CSRF/XSRF), and once embedded within the website footer, it was only a matter of time before site visitors would load the page and get their browser to (unknowingly) send a vote to the About.com server. The vote would be from their IP address, and would go completely unnoticed to most web users. Sure enough, after a few minutes, the poll results had gone from this:

Before

to this:

After

With the exploit working, and the site “Fido” in the lead, I removed the malicious code from my site. I refrained from posting this blog post until the official About.com voting period was over, and the results were announced (in the end, Google won).

What should be taken away from this? Well, don’t use GET requests to add votes to polls; POST requests are trickier to force upon users, and usually either involve them clicking submit on a form, or having some JavaScript doing the action in the background. Another thing this should alert web designers to is the importance of another level of security on top of their polls. It is great if you can code a poll that works, but it is even better to code a poll that works securely, especially if there are people out there who want to manipulate your votes for reasons other than trying to demonstrate possible exploits (like myself). In my opinion, I believe that a simple CAPTCHA verification (such as the popular reCAPTCHA) should solve most problems with online polls such as this. Yes, they can get annoying, but at the end of the day, they only take up a few extra seconds of your users’ time, and they are very difficult (though not impossible) to bypass.

An example HTTP Cookie

According to this BBC News article, a new European e-Privacy directive that comes into force this year will require websites that use cookies to gather explicit consent from users before issuing them to the browser. The directive was created to try and cut down on websites that track users from site to site, and display adverts based on the information stored about them in their cookies. Cookies used for logging what people have in their shopping baskets (common in online stores like Amazon) are apparently the only use that are excluded from the directive.

Of course, this leaves the question of what will happen to the most common use of cookies, that of logging people into websites? Every time you use a username & password to log into a website, you are usually issued with a cookie that acts as your “passport” around that website. Instead of entering your username & password on every page load, the cookie is sent instead, saving you a lot of time and effort. Like a passport, the cookie is unique to each user, and usually has some form of randomness to make it near-impossible to brute-force. So if sites have to gather explicit consent before these cookies are issued, this may mean that as an addition to entering your username & password, you may have to check a box to say you agree to receiving the cookie, or in some extreme cases, have to click away a popup box in order to log on properly.

Whilst I agree that cookies have become a big privacy issue as of late, I’m not so sure I agree with the directive in this case. Something does need to be done to stop the tracking of users around the web, but I believe such a harsh directive as the one issued will do more damage to the web browsing experience than it will good. Not only will it slow down the whole process of logging into websites, but it may also lead to more confusion of the average user. It could also cause some unintended side effects, such as more people leaving their sessions open rather than logging out, meaning that any intercepted cookies would be valid for longer.

In my opinion, the issue of how to handle “malicious” cookies should be done in the browser. After all, it was browsers who started fighting the problem of malicious JavaScript, as well as dealing with the various pieces of malware that spread over the web. Indeed, only a couple of months ago the BBC reported on such moves from both Mozilla, Google, and Microsoft. Whilst this directive probably will solve a few problems with cookies, I predict it will cause more for the end user in the long run.