This conversation between my sister and her bank was just posted on her Facebook wall, and I thought it was appropriate to share on this blog.

Bank: Hello Miss Hayter, can you give me the date of birth of Maureen Hayter?
My Sister: Erm, I don’t know a Maureen Hayter.
Bank: That’s great, you’ve passed the security check, how can we help?

Apparently the information that protects your assets isn’t something that only you know, but something that you don’t actually need to know in the first place. So all a criminal needs to do is be ignorant of your personal details, and they can gain access to your account.

My sister also revealed that in order to do an actual bank transfer, she was given a list of addresses that she had to confirm she had never lived at. I don’t know the details of the bank she is with, and even if I did I wouldn’t post them here. However if I had my assets with a bank that failed this badly at Information Security, I certainly wouldn’t keep them there for long.

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.