AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth

Slaying Firesheep

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:

  1. No security.  Generally used for pages with static content, open for all.
  2. 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.
  3. 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!

Send to Kindle

Comments RSS TrackBack 8 comments

  • Tweets that mention AKF Partners  |  Tech Blog, Slaying Firesheep » AKF Partners Blog -- Topsy.com

    in November 20th, 2010 @ 17:13

    […] This post was mentioned on Twitter by Mike Fisher, Mike Fisher. Mike Fisher said: Slaying Firesheep http://bit.ly/9Ey6A9 #in […]


  • Quora

    in November 21st, 2010 @ 23:11

    Can HTTP sidejacking be solved by sending signed cookie alone, since maintaining https/ssl is very heavy and requires lot of resources?…

    There is a simple way to use https just for an authentication cookie and prevent sidejacking.  This way all content can still be served with just http and there is no mixed content warning.  Here is our blog post about it: http://akfpartners.com/techbl…


  • Quora

    in November 21st, 2010 @ 23:15

    What is the best way to prevent HTTP session hijacking?…

    From a user’s perspective you should not use unsecured wifi.  From a service provider perspective you should create an auth cookie that is served over https even if the entirety of the site is plain old http.  This way you can ensure you users’ cooki…


  • Ravi Periasamy

    in November 22nd, 2010 @ 07:33

    We can just do with secure cookie? Why we need a non secure cookie also?


    • Randy

      in November 22nd, 2010 @ 12:05

      The example provided uses a non-secure cookie to show that sidejacking can be prevented in a very inexpensive and backward compatible manner. This approach could be deployed quickly and easily to the sites that are currently vulnerable to sidejacking, such as Facebook, Google, Amazon, etc.


  • Greg Steuck

    in November 24th, 2010 @ 18:18

    This workaround simply breaks Firesheep in its current form. authenticate.php is a noop in “properly logged in” case. So the FireShepard only needs to instruct their browser to disregard those requests going to authenticate.php. One can even build this workaround directly into Firesheep (assuming it has full DOM access)


    • Randy

      in November 25th, 2010 @ 17:49

      Greg, you are absolutely correct. Note also that the example is clear that this is simply a proof of concept. Increased security can be accomplished via a number of methods; let me articulate three:
      1. The authenticate.php script returns variables and values critical to the correct functioning of the page.
      2. The authenticate.php script returns other javascript files that need to be included.
      3. The authenticate.php script generates new cookies, that the non-secure server will expect next time. Thus, we are making “single-use” cookies. A sidejacker might potentially see the current page, but could not generate the required cookie values for the next page.

      Make sense? The example is purposefully bare-bones. A true implementation would implement one of many different methods to secure the site in completeness.


      • Pino

        in July 9th, 2013 @ 12:34

        I’d like to see how you might fix this solution to accommodate users who turn off JavaScript.