I’ve mentioned the HTTPS Everywhere add-on for Firefox a couple of times on this blog. The add-on, developed by the Electronic Frontier Foundation (EFF), attempts to boost your security whilst browsing by sending as many requests as possible over HTTPS. Yesterday, version 2.0 of the add-on was released, with a new feature that “detects encryption weaknesses and notifies users when they are visiting a website with a security vulnerability”. Using data obtained through EFF’s SSL Observatory project, combined with new research into weak public keys, the add-on can now warn people about potential security problems with their connection to various websites.

Until recently, it was impossible for Google Chrome extensions to intercept an HTTP request, and so a Chrome extension was not developed (although there are alternatives). With the new WebRequest API however, a beta version of HTTPS Everywhere has now been released! Both the updated Firefox add-on and the new Google Chrome extension are available here.

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.

WhiteHat Security is holding a competition to find the top ten web hacking vulnerabilities of 2011. There are 50 vulnerabilities in the competition, and there is an open ballot to vote for the top 15. Those 15 finalists will then be judged by a panel of security experts and they will announce the winners.

Voting is open to anyone until 26th February.

This hasn’t been a good week for Google Wallet, the mobile app that stores your credit cards so you can easily make payments with your phone. Yesterday, zvelo engineer Joshua Rubin revealed that the 4-digit PIN used to authenticate users of the app is stored as a SHA256 hash on the device, and this hash is easily obtained if the device is rooted. The problem here isn’t that SHA256 is insecure (on the contrary, it is a highly recommended hashing algorithm), but rather that there are only 10,000 possible values that the PIN could be (0000 to 9999 inclusive). This means that a brute-force attack is easily executed by simply SHA256 hashing each possible PIN and checking the resultant hash with the one stored on the device.

The following video shows the attack in action. The team who found the vulnerability simply created a separate app that reads the stored hash value and brute-forces it. It only takes the app a few seconds to crack the hash.

If you thought that was a bad design decision by Google, you haven’t seen anything yet. As it turns out, there is no need to root the device or crack the hash, as all an attacker needs to do is ask the phone to reset the Google Wallet application data. This wipes the PIN from storage, but not any card details, so when the Google Wallet app is next opened it asks you for a new PIN and lets you use the stored card details immediately:

Path (Photo credit: SimonQ)

Yesterday it emerged that the iOS app for the mobile-only social network Path was uploading address book data without the user’s permission. This violation of user privacy caused a large backlash against the company, with many users promising to delete their accounts in the comments of articles covering the revelation. As someone who installed the Path app but has rarely used the social network, I immediately requested the deletion of my account and for the removal of any information they had uploaded without my permission.

Today, the Co-Founder and CEO of Path, Dave Morin publicly apologised for the mistake, and has attempted to rectify the situation:

We believe you should have control when it comes to sharing your personal information. We also believe that actions speak louder than words. So, as a clear signal of our commitment to your privacy, we’ve deleted the entire collection of user uploaded contact information from our servers. Your trust matters to us and we want you to feel completely in control of your information on Path.

A new version of the iOS app has been released in the App Store, and includes an opt-in for sharing your phone’s contacts with Path servers. This is a step in the right direction, and Path must be applauded for their speed at admitting their mistake and fixing the issue. However, companies should take note that this entire event could have been avoided if they had implemented the opt-in by default.

Often companies will use the excuse that if such data was opt-in, hardly any of their users would consent to it being used. In my opinion, this excuse is pitiful, since it puts the importance of the service above that of the user. Users care about the service (if they didn’t, they wouldn’t have signed up in the first place), but they also care about their privacy. This short-lived debacle has shown that people will abandon a service if they feel it has violated their privacy, so the real question is: do you want to be a company that is open about how it uses personal data, or face an exodus of users later on when your privacy violations are discovered?