This is a guest post by Randy Wigginton that started from a conversation about how to better secure cookies. Randy has an incredibly impressive career being one of the earliest employees at Apple and holding Distinguished Engineer and Architect titles at companies such as eBay, Quigo, and Google. Nowadays he is spending most of his time on personal projects that grab his attention such as this issue with unsecured cookies. Randy can be reached directly at this email.
The browser extension Firesheep has deservedly attracted a great deal of attention. This extension has made it painfully obvious that many major Internet sites have not adequately protected user’s information. In this article, we present a simple approach that will substantially improve user authentication security, and render Firesheep and other session sidejacking tools mostly useless.
There are at three different levels of security used on the web:
- No security. Generally used for pages with static content, open for all.
- Some security. Useful for sites with login and customization, such as Facebook or Amazon. The information on the pages is not particularly sensitive. This is the majority case for websites.
- Full security. Financial and other sites where all information must be kept confidential.
For #1, any http server is sufficient. For #3, all pages, images and communications must be encrypted. Case #2 is a hybrid.
For most users, there are asymmetrical aspects to logged-in, customized websites. While I do not care if anyone sniffs the network to get my status updates or discover what I am shopping for, I do NOT want anyone else claiming to be me or buying items on my behalf! The traditional IT response has been “The only way to be secure is to put all pages and images under SSL”. The problem with that approach is that SSL is slower and more costly; sites switching to all SSL will need to increase their server farms substantially. This can be extremely expensive.
Here is a demo of a very simple site. This site consists of a starting page, a secure login, then two non-secure pages that require users to be logged in. Here you will find an extension script for FireSheep (right click and ‘save as’); it captures session cookies from the demo domain. If you attempt to hijack a session on the akfdemo.com domain, you will be redirected to the sidejacking page.
How are sidejackers recognized? When a user logs in, TWO cookies are dropped. In our case, one is called “session”, the other is called “authenticate”. These two cookies are identical except for a single attribute: “authenticate” is a secure cookie. We authenticate users on non-secure pages by including a reference to a secure javascript at the top of each page. At the top of pages requiring authentication is this line:
<script type=”text/javascript” src=”https://verify.akfdemo.com/authenticate.php“></script>
The authenticate.php script is:
<?php
// If this is the original user, they will have one secure and one non-secure cookie
// Both are set to username:password
// A real implementation should encrypt values. This is for demonstration purposes.
if (strlen($_COOKIE['session'])==0) {
// They have not logged in.
echo “window.location = ‘http://”.$_SERVER['HTTP_HOST'].”/landing.html’”;
} else if ($_COOKIE['authenticate'] == $_COOKIE['session']) {
// The secure cookie is identical to the non-secure cookie. Let the user stay.
} else {
// They do not have the secure cookie we require. This must be a hacker!
echo “window.location = ‘http://”.$_SERVER['HTTP_HOST'].”/sidejacked.html’”;
}
?>
If the user has no session cookie, they have not logged in; send them to the starting page. If the user has a session cookie that matches the secure authentication cookie, they are allowed through. In the last case, they have a session cookie (which could have been obtained from Firesheep or other), but they do not possess the matching authenticate cookie. This is the sidejacking case; in such a situation, we direct the browser to the sidejacked.html page.
It is best to think of the secure cookie as a checksum, or verification, of all the plain non-secure cookies. With this technique, we improve user security at a fraction of the cost of using full SSL for all resources. This technique should be used in conjunction with other security best practices to provide a complete security solution for a website.
Another security approach that consumer based internet companies should consider is using HTTP for the base page, any non-personal information, while collecting and displaying personal user information via HTTPS AJAX calls. This way the user info is protected, the entire page does not require the overhead of HTTPS, and the browsers don’t alert users of mixed content.
If you haven’t installed Firesheep but are curious how it works, here is what it looks like running (click to enlarge the picture).
You can see on the left side the that it has captured several cookies from Yahoo, Google, Facebook, Twitter, and our AKF Demo site. When you click on any one of those captured cookies (except for the AKF Demo) it logs you in to that person’s account. Below is what happens when you try it on the AFK Demo site with Randy’s code.
Notice that it cannot login to the demo site and is actually identified as a possible sidejacker!
Recent Comments