I work for a web development company in Athens, and, as with anything that deals with the Internet, one of our chief concerns remains security. This includes making regular efforts to ensure that we’re using the latest server software, and that we utilize good programming practices to avoid malicious users being able to circumvent our security from within the context of our applications. Recently, however, a security problem that has been neglected by the web development community for years has been brought to the forefront with the recent release of a Firefox extension that allows you to take over other people’s accounts, without stealing their passwords. More after the jump.
How they know who you are
As I explained in my September 1st blog post What is HTTPS?, the world wide web is run on a protocol (or, set of rules for information exchange) called HTTP that specifies how your computer should talk to other computers who are running websites. HTTP has an interesting property that sets us up for the primary problem of this post. That is, HTTP is stateless. Sateless means that HTTP does not provide any way for telling your website requests apart from any other website request out there. Each time you load a new web page, you are performing a separate HTTP request, and they all look the same to the server running on the other end.
“But Matt,” you say, “I don’t enter my Facebook username and password each time I go to a different page! How does it know who I am?” Good question.
Obviously, no one would use these popular websites if we had to enter our password for each request, so the smart people who make websites have obviously figured out some way around this limitation. That tactic is a concept called sessions. Sessions are essentially pots of information that are stored on the server, and all sessions are associated with some “Session ID” that uniquely identifies each session. This “Session ID” is stored in a cookie, which is a piece of information associated with a website that your browser will attach to any request sent to that particular website.
Essentially, this works as follows in the context of Facebook:
- You click on a Facebook bookmark in your browser or type “facebook.com” in your address bar.
- If you have a cookie with a Session ID on your computer, your browser will automatically transmit that when it sends your request to Facebook. If that Session ID is currently associated with your account, you will see your news feed and all of that cool stuff. If not, you’ll be kicked to the login page.
- If you get kicked to the login page, you will be using HTTPS (see the referenced post if you want to know what that means) to prevent someone from stealing your password. So, you enter your username and password, then click Log In. If that is correct, Facebook will transmit a Session ID to your browser and instruct it to load your homepage with your news feed.
- Your browser reads this redirect instruction, and does as its told: it makes a regular HTTP request to your Facebook homepage, transmits your newly acquired Session ID, and displays your news feed when it receives content from the Facebook server.
How they steal your session
Odds are, you don’t see the problem in this situation. I didn’t until recently, but web application developers have made an egregious mistake in the course of application development over the last several years. In the scheme above, you’ll note that for the actual process of logging in, you are redirected to an HTTPS connection – which means that all of your information is secure. However, as soon as you are logged in, you are back on regular HTTP, because that’s less taxing on the server’s CPU.
The crucial error here is that your Session ID, the identifier that tells the server who you are, is transmitted over the internet with each HTTP request, in plain text. The issue with this scenario is that your Session ID is the next best thing to your username and password. On many sites, providing a valid Session ID is enough to give you access to everything that the user using that session has access to.
This type of exploit has been known about for awhile, but until recently it has been treated as a relatively low risk situation, because it required a somewhat sophisticated knowledge of HTTP and networks. Also, the odds that the public wi-fi you’re using will have a hacker who is stealing passwords on it is usually rare. Unfortunately, a Firefox plugin by the name of Firesheep has recently been published by a guy named Eric Butler. Firesheep sits on any publicly accessible wireless network and detects sessions that are going on around you, and allows you to take them over at will.
What can I do?
To be truthful, your options are limited. A lot of the weight will fall to web application developers like me. There are a few tools out there that can help you out, like HTTPS everywhere from the EFF, but as many readers of Eric Butler’s blog point out – the only real solution is end-to-end encryption of all logged in sessions, **everywhere. **The problem with this arrangement is that it is expensive. Twitter doesn’t even support full HTTPS for all resources. It costs more money to run all user sessions through HTTPS, something that I’m likely to encounter myself as I converted my entire administration panel to HTTPS. Even downloading an image over regular HTTP is enough to have your Session ID revealed.
There are several pieces of good news about this threat. Websites like banks keep their content completely encrypted, so you’re safe on that front. Your credit card numbers are encrypted during the process of checking out online, so you’re safe on that front. To be honest, the worst grief that you will likely experience is probably having your Facebook or Twitter page hacked, however if someone like me isn’t careful I could end up with someone hacking into my website. And that’s no fun.
Another stroke of good news is that as long as you’re on a protected wireless network, you’re probably safe from this threat. If you don’t think you are, you should probably get a better roommate. Unfortunately, many students like myself utilize the University of Georgia’s wireless network, PAWS, which is not protected.
Users at the University of Georgia should seriously start considering the use of the UGA VPN when using an unprotected wireless connection (it works on or off campus), or utilizing the PAWS-Secure network, where it is available. However, the speed problems associated with using the VPN off campus and the lack of secure options available at other public hotspots poses a serious issue for those of us who like to enjoy a cup of coffee while we work.
Sound like a bad situation all around? Good, you’re starting to catch on. Web Application Developers are starting to work on a number of countermeasures to make attacks like this more difficult, but to put the problem to rest for good will likely require website administrators to start encrypting logged in sessions completely – something that can be both costly and time consuming to implement for large sets of websites.
What do you think about this issue. Please, feel free to leave thoughts and comments below. As you all know, I’m always a fan of some comment love.