How to Create Bulletproof Sessions

Kevin and Gary show at FOWA London

In the first part of this series we went over how a cookie works and what can be done to secure them. In this section we’re going to go over ways to add additional security to the session beyond the cookie itself.

By the end of this article we will written our own wrapper class for “session_start” that protects our session from a number of attacks while taking into account some of the unique challenges presented by modern ajax-heavy websites.

Session Specific Attacks

Through the use of sessions your identity is maintained as you use a website, and just as in real life identity theft is a concern. By taking over your session an attacker would essentially become you on a website, with access to all of the actions, information and privileges that entails.

The main thing that an attacker needs to steal a session is the session ID. There are three ways an attacker normally goings about doing this, all of which can be protected against but are, by default, completely open.

  • Guess the ID: most session handlers generate ids that make this impractical.
  • Steal the ID: by using malware, sniffing the network, or exploiting javascript exploits attackers can get the value from the cookie itself.
  • Set the ID: rather than steal or guess the ID an attacker may try and set it to a value they choose.

Starting the Session

The default session setup is not at all secure by itself, so we’re going to create a wrapper to add the security we need. To make this code more portable we’re going to build it as a static function of a php class called SessionManager.

To begin our sessionStart function is going to set the name cookie options for the session. Like all cookies we’re going to need to make some decisions about what is going to need access to the session ID. Since these options depend on the application itself lets add arguments we can change based on our specific needs.

For security we can hardcode the “HttpOnly” argument, as session ids are often the juiciest target for cross site scripting attacks.

class SessionManager
{
   static function sessionStart($name, $limit = 0, $path = '/', $domain = null, $secure = null)
   {
      // Set the cookie name before we start.
      session_name($name . '_Session');

      // Set the domain to default to the current domain.
      $domain = isset($domain) ? $domain : isset($_SERVER['SERVER_NAME']);

      // Set the default secure value to whether the site is being accessed with SSL
      $https = isset($secure) ? $secure : isset($_SERVER['HTTPS']);

      // Set the cookie settings and start the session
      session_set_cookie_params($limit, $path, $domain, $secure, true);
      session_start();
   }
}

Using the new class is as easy as including it and running one line but additional options can make it more restrictive.

SessionManage::sessionStart('InstallationName');
SessionManage::sessionStart('Blog_myBlog', 0, '/myBlog/', 'www.site.com');
SessionManage::sessionStart('Accounts_Bank', 0, '/', 'accounts.bank.com', true);

Lock the Session to a Host

Now that our wrapper class is in place and functional we can start building in additional security by restricting the session to the same IP address and User Agent (or browser) as when the session was first opened. This way if the session ID is stolen or guessed the attacker still has to get ahold of the user agent (admittedly not too difficult if they got the session ID) and somehow find a way to get the same IP address.

These attacks only help if the user is not on the same network. The user agent check only adds minor security, since many attacks that compromise the cookie are going to do the same to the user agent. If an attacker is on the same network as the target there is a good chance they already have the same external IP address, as it is pretty common for a network to use private internal addresses while presenting only a single IP address to the internet. This is why it is important to evaluate the need for SSL.

We’re going to add these new checks to our class in the function preventHijacking. This function will return false on new sessions or when a session is loaded by a host with a different IP address or browser. preventHijacking will true if the session is valid and false otherwise. This means it will return false not just on malicious attempts but completely new sessions as well.

static protected function preventHijacking()
{
	if(!isset($_SESSION['IPaddress']) || !isset($_SESSION['userAgent']))
		return false;

	if ($_SESSION['IPaddress'] != $_SERVER['REMOTE_ADDR'])
		return false;

	if( $_SESSION['userAgent'] != $_SERVER['HTTP_USER_AGENT'])
		return false;

	return true;
}

Now that we have a way to identify hijacking attempts we need to set up a way to respond to them. For us this means two things- clearing out the old session data and inserting the IP address and user agent into the new session.

static function sessionStart($name, $limit = 0, $path = '/', $domain = null, $secure = null)
{
	...
	session_start();

	if(!self::preventHijacking())
	{
		$_SESSION = array();
		$_SESSION['IPaddress'] = $_SERVER['REMOTE_ADDR'];
		$_SESSION['userAgent'] = $_SERVER['HTTP_USER_AGENT'];
	}
}

Session Fixation

So far we have effectively eliminated the possibility of brute force guessing. We’ve also made it so any attempts at capturing the session ID would require the attacker to be on the same network as the user in order to take advantage of that ID, while also discussing enforcing SSL to make capturing the session more difficult through traditional means. However, what if the attacker could set the session ID themselves?

By getting the user to follow a link with a session ID in it the attacker can trick the user into starting a session with the ID of the attacker’s choosing. Rather than guess or steal an ID the attacker will have it right from the start. Many web environments, including PHP, allow session ids to be set through the URL, primarily to get around systems which do not support cookies. Just like with regular cookies the value sent by the client is the value used for the ID, so in this case the value in the URL becomes the session ID.

The solution to this is to change the session ID. How often you do this is tends to be a matter of great debate, but at the bare minimum the ID should be changed when new sessions are created and when the user changes privileges (logs in or out).

A First Attempt At Regenerating the ID

Regenerating the ID is fairly simply in php. Deceptively simple one might say. The function “session_regenerate_id” lets us tell the system to use a new ID. It can also optionally delete the old session.

// Leaves old session intact
session_regenerate_id();

// Deletes old session
session_regenerate_id(true);

If you don’t delete the old session then it is still vulnerable to hijacking and whatever access it had can be granted to an attacker. If you’re changing the session ID often without deleting the old ones you could be creating more holes by leaving a trail of old, but valid, sessions.

Regenerating the ID in the World of Ajax

If an application creates a lot of quick connections to the server some interesting things can happen. PHP, and many other languages, restricts access to the session data to one running script at a time, so if multiple requests come in that try to access the session data the second request (and any other) gets queued up. When the first request changes the ID and deletes the old session the second request still has the old session ID which no longer exists. This results in a third, new session being opened and generally means your user gets logged out.

This bug is ridiculously hard to diagnose as the timing of not just the requests but the ID regeneration has to be just right. In sites that don’t make requests to the server using javascript this type of bug may never be encountered at all, as the time between page loads is more than long enough for the browser to have updated its session info. For sites that make use of ajax techniques, however, this issue will have a chance of occurring whenever the session ID is changed.

In our final update to the SessionManager class we’re going to write a fix for this problem. Rather than delete the session immediately when we change the ID, we’re going to mark the old session as obsolete and mark it to expire in ten seconds. This way any queued up requests will still have access to the expired session but we don’t have to leave it open forever.

To accomplish this we’re going to add the regenerateSession function. This function adds the obsolete flag and expiration to the session, regenerates the ID to create the new session and saves them both. It then reopens the new session and removes the obsolete flag. Unlike our other internal functions we are leaving this one open for use outside the class so that it can be tied into login scripts.

static function regenerateSession()
{
	// If this session is obsolete it means there already is a new id
	if(isset($_SESSION['OBSOLETE']) || $_SESSION['OBSOLETE'] == true)
		return;

	// Set current session to expire in 10 seconds
	$_SESSION['OBSOLETE'] = true;
	$_SESSION['EXPIRES'] = time() + 10;

	// Create new session without destroying the old one
	session_regenerate_id(false);

	// Grab current session ID and close both sessions to allow other scripts to use them
	$newSession = session_id();
	session_write_close();

	// Set session ID to the new one, and start it back up again
	session_id($newSession);
	session_start();

	// Now we unset the obsolete and expiration values for the session we want to keep
	unset($_SESSION['OBSOLETE']);
	unset($_SESSION['EXPIRES']);
}

We need to add another function to check for the obsolete flag and to see if the session has expired.

static protected function validateSession()
{
	if( isset($_SESSION['OBSOLETE']) && !isset($_SESSION['EXPIRES']) )
		return false;

	if(isset($_SESSION['EXPIRES']) && $_SESSION['EXPIRES'] < time())
		return false;

	return true;
}

Finally, in the last change to our SessionManager, we need to update our SessionStart function. It needs to call the regenerateSession function on new requests and periodically after that, as well as destroy the session if it is invalid. Here is the complete SessionStart function.

static function sessionStart($name, $limit = 0, $path = '/', $domain = null, $secure = null)
{
	// Set the cookie name
	session_name($name . '_Session');

	// Set SSL level
	$https = isset($secure) ? $secure : isset($_SERVER['HTTPS']);

	// Set session cookie options
	session_set_cookie_params($limit, $path, $domain, $https, true);
	session_start();

	// Make sure the session hasn't expired, and destroy it if it has
	if(self::validateSession())
	{
		// Check to see if the session is new or a hijacking attempt
		if(!self::preventHijacking())
		{
			// Reset session data and regenerate id
			$_SESSION = array();
			$_SESSION['IPaddress'] = $_SERVER['REMOTE_ADDR'];
			$_SESSION['userAgent'] = $_SERVER['HTTP_USER_AGENT'];
			self::regenerateSession();

		// Give a 5% chance of the session id changing on any request
		}elseif(rand(1, 100) <= 5){
			self::regenerateSession();
		}
	}else{
		$_SESSION = array();
		session_destroy();
		session_start();
	}
}

Summery

At times it amazes me how complex something as simple as an ID- what is essentially just a string of random characters- can turn out to be. While you can certainly use this class for all of your own projects here is what you need to remember when building your own session manager.

Session IDs are attacked by guessing, capturing or setting the id. You can protect against this in your own applications by …

  • Securing the cookie to make stealing the ID harder
  • Limiting the session to a specific host to make attacks more difficult
  • Changing the ID when escalating privileges and throughout the session life.

Here is the complete Session.class.php file for your reference.

Free Workshops

Watch one of our expert, full-length teaching videos. Choose from either HTML, CSS or Wordpress.

Start learning

Robert Hafner

Robert Hafner has been writing code and leading companies for as long as he can remember. He is heavily involved in open source and has released numerous projects, including many security and scalability related libraries. On the professional level he has acted as a dev/ops consultant for many companies and spent five years in an executive role at a leading security company. Robert can be found on LinkedIn, Github, Twitter and on his blog.

Comments

53 comments on “How to Create Bulletproof Sessions

  1. Pingback: Carsonified » How to Create Bulletproof Sessions « Chikocupado’s Blog

  2. Very exhaustive post, I have already integrated the class it in the current project I am working on. It has been a good idea to do it in OOP people should really start to program in this way even on small parts of their projects.
    I was previously using some lines of code to force session regeneration and but this solution is much more complete and leaves things very easy to upgrade any time.

  3. Just checking the ip address like you do is not good, what about people who are behind proxies and change IPs all the time? (AOL, etc)

    • they will have to login again..

      Some people might not agree with me but I really dont like the fact of leaving cookies for more then 1 day on my PC, or even after I close my browser.

      Regarding this class… very nice one indeed. All it needs to be really bullet proof is to hash the IP address in MD5 hashes. In short, eliminate “visible” data that the bad guy might see useful.

      Awesome article, thanks!

      Thats all..
      omg

      • They won’t just have to log in again. It won’t work for them at all. Unless the way AOL works has changed recently, every single request from the same user is likely to come from a different IP. By the time they’ve logged in, they’ll be logged out.

  4. Nice article,
    just a little note on the IP protection as it will not work for AOL customers.
    AOL use proxies, and a user can have differents IPs for the same visit.
    Regards.

  5. Great tips. Changing the session ID every so often is a good one.

    Locking the session ID to a given IP is probably a “Bad(tm)” idea.
    If a users network at work or their ISP (such as AOL) filters traffic through a cache filter or a proxy, that might be load balanced in which case the IP can change while going from page to page.

    So I’d strongly suggest not doing this :)

  6. We’ve been comparing User Agents in one of our projects to lock a session to a specific user, but we’ve found that some of our site visitors are failing the check. When they initially visit the site, the user agent is IE 7, but on the next it reads as IE 8. We’ve noticed user agent switching on a few browsers, but IE 8 so far is showing up the most.

    • Thats really interesting, I hadn’t encountered that type of behavior before. By any chance are you taking advantage of the “compatibility mode” to have IE8 render pages using the ie7 engine? I’m curious as to what can cause this type of issue.

      • We’re not doing any forcing of user agents or modes. At the moment, we’ve rolled back changes that terminate sessions if user agents don’t match, but are continuing to record and monitor user agents when they change mid-session. In fact, we don’t load any HTML until the very last step. I’ve included one users’ before and after:

        Initial page load: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; FunWebProducts; GTB6; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

        After page redirect: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; FunWebProducts; GTB6; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

        • Believe it or not this is compatibility mode coming back to bite you (even if you didn’t ask for it). When compatibility mode kicks in IE changes its user agent to use a different IE version, but it still uses the “Trident/4.0″ tag in the user agent so you know you’re dealing with IE8.

          If you edit the “preventHijacking” function above and replace the user agent code with the following it should fix the issue-

          if( $_SESSION['userAgent'] != $_SERVER['HTTP_USER_AGENT']
          && !( strpos($_SESSION['userAgent'], ‘Trident’) !== false
          && strpos($_SERVER['HTTP_USER_AGENT'], ‘Trident’) !== false))
          return false;

          This works by first checking to see if the useragents match, and if not it checks to see if both the stored and incoming useragents are IE8.

          • Hey tedivm, thanks for that. I’ll include it. That’ll help with this case and since I’ll be listing exceptions like this, I’ll probably create a separate method to check for exceptions.

            I’ve been trying to reproduce these errors on my PC but so far have not been able to trigger the switch.

    • Doug, my reply to your reply to my reply (sorry, couldn’t help that) somehow got put in its own thread. I just wanted to make sure you didn’t miss it.

    • At a guess, I would say the DOCTYPE headers on both pages differ. Regardless, you can force the page that is causing IE8 agents to drop back to compatibility mode (ie. report as IE7) by including IE’s new X-UA-Compatible META tag which overrides any DOCTYPE header:

      • Comments munched my META tag.

        @Moderator, why are there no CODE blocks allowed in the comments of a blog discussing programming!

      • The problem occurs when switching from compatibility mode to regular mode (or vice-versa). Its not enough to supply a metadata tag because when IE sees that it appears to reload the page- including resending the changed referrer to the server.

        I provided a fix below, which is also at the google code site for the code.

  7. I’ve updated the SessionManager class and placed it up on google code.

    http://code.google.com/p/phpsessionmanager/

    The two big changes-

    * Session’s are no longer invalidated by IE8 going in and out of compatibility mode
    * When the stored and remote IP addresses don’t match a check is done to see if both IP addresses came from AOL proxies.

    If someone wanted to expand upon it there are two places they can start-

    * Standardize the proxy checks to other networks can use it
    * Make the IP checks optional, or less restrictive (instead of a direct match have it work off of the first few segments).

    Thanks for all of your input.

    • I believe web developers shouldnt take IP changes seriously, as long as the cookie is intact within the same session. I start working in gmail using my ISP assigned IP address then I change my PC to a VPN supplied IP address and gmail continues to function correctly regardless of the Ip address change, but there are forums like digitalpoint that immediately log me out when they detect change in IP after I have logged in and used my original Id for some time.

  8. nice one, even i’m missing a small walkthrough on the session configuration options/functions like session_cache_expire and especially session_cache_limiter.

    regarding the proxy comments: you could the HTTP_X_FORWARDED_FOR / HTTP_CLIENT_IP header to determine if the request was proxied and then use a combination of ip address and user agent instead. also you could check if that IP is inside the private ip network range and maybe even block it then.

    • I followed through on your advice and have updated the code (http://code.google.com/p/phpsessionmanager/).

      The next step will be to extend the class to make the various checks optional. One of the points I was trying to get across with the discussion on cookies and aspects of this was that security issues do depend on the situation, and while some sites may be comfortable disabling some security aspects other sites (or even different sections of a site, such as the admin side of things) may require something a bit tougher.

  9. Pingback: A collection of stuff » Blog Archive » Como proteger tus sesiones contra ataques

  10. Pingback: How to Create Bulletproof Sessions | Choose Daily

  11. Regarding the locking the session to an IP address, just making an exception for AOL won’t cut it. You just can’t really do it in the real world, unless you are perfectly happy for your users to get logged out repeatedly during their session.

    And also a note on making session cookies HttpOnly – this can be set in the php.ini.

  12. Ditto @Dangerous. IP’s can change on a page by page basis. Browsers, such as Safari & Firefox, will actually send 2 different user agents when checking for RSS feeds. This same half-baked solution has been posted over and over and over. You can’t fix a problem by creating a whole new slew of issues. It’s great for newbs, but no one with any real experience works like this.

  13. I have a principle on dealing with issues such as session management – “keep it simple”.
    Every project has different security needs. If the only thing an attacker would possibly be able to do is change an avatar, then stick to the plain session_start().

    For other purposes, rely on heavily tested and bug-free session management classes. Don’t start on making it on your own if you are not experienced enough, or you risk countless hours in debugging (or even restoring corrupted databases).

  14. It’s not just AOL proxies – I commute with a laptop, which means my IP address will change from my home WiFi to my 3G dongle to my at-work address all in the space of a couple of hours. I’m not keen on the idea of sites that sign out my session just because I moved from one connection to another. I think my 3G-supplied IP address might change as the train moves from one cell tower to another as well.

  15. Hi Robert, its not only IE8, ALL the browsers have a kind of compatibility mode. I don’t think its safe to use HTTP_USER_AGENT .

    Examples:

    IE7:
    Initial page: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618)
    Second page: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

    Firefox 3:
    Initial page: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.13) Gecko/2009073022 Firefox/3.0.13 (.NET CLR 3.5.30729)
    Second page: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

    Firefox 2:
    Initial Page: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20 (.NET CLR 3.5.30729)
    Second Page: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

    IE6:
    Initial Page: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
    Second page: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

    Samsung Phone:
    Initial page: Samsung-SPHM520 AU-MIC-M520/2.0 MMP/2.0 Profile/MIDP-2.0 Configuration/CLDC-1.1
    Second page: Mozilla/5.0 (compatible; OpenWeb 5.7.4-09)

    And sometimes you can find something like this:
    First page: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; GTB6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)
    Second page: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; GTB6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506),gzip(gfe) (via translate.google.com)

  16. Pingback: Wayne State Web Communications Blog » Blog Archive » [Friday Links] The Eventful First Week Edition

  17. Pingback: Carsonified » How to Create a Valid Non-Javascript Lightbox « Better

  18. Good article! I’ve always been stickler for making these things as tough as possible.

    One question though. You’ve focused on making the session ID as bulletproof as possible, but what about some good session housecleaning tips like cleaning out important session values on logout or a failed login attempt.

  19. Pingback: Ennuyer.net » Blog Archive » Rails Reading - Sept 10, 2009

  20. Great Artical, just what i needed
    One thing I am not clear about – why the “5% chance of the session id changing on any request”?

    • Avner.. (well this is old, so for new readers I guess).. I believe the 5% seed is to have a slight security measure… once in a while random session id’s will generate to further decrease a successful id spoof.

      Why not just higher than? well to do with server loads I think.. also the point of replacing sessions with 10 sec buffers… try this for example on your localhost and refresh rapidly.. you will see bottlenecks.

      it is a bit funny indeed summery hasn’t been corrected but not the pertinent issue here.

      Interesting article… thanks a lot.. as a newcomer to web security and sessions management, it was a nice read. PS. If ANYONE notices chrome doesn’t destroy cookies properly via php session management , let me knowwww ;)

  21. Pingback: Self Managed Guidelines, Tips & Frequently Asked Questions - Hosting Articles - RatingHost.Com

  22. Great article!
    Except you overlooked the vulnerabilities that shared host users are exposed to, session data is stored on files on the server which can be exposed to other users on the same shared host, a good idea would be to store session data in the database.
    Another thing PHP has a function which allows you to set your own session handler

    bool session_set_save_handler ( callback $open , callback $close , callback $read , callback $write , callback $destroy , callback $gc )

    that way you can use the regular PHP session functions instead of calling static class members all the time.

  23. I’ve found a bug in the following line of the regenerateSession() function:

    if(isset($_SESSION['OBSOLETE']) || $_SESSION['OBSOLETE'] == true)
    return;

    The problem is that if $_SESSION['OBSOLETE'] isn’t set, then it will generate Undefined index: OBSOLETE

    Best option here is the drop the isset() part of the if statement and instead do the following:

    if(@$_SESSION['OBSOLETE'] == true)
    return;

  24. Sorry, I take back the last comment I made. The problem is the if statement should be AND instead of OR, like so:-

    if ( isset( $_SESSION['OBSOLETE'] ) && $_SESSION['OBSOLETE'] == true )
    return;

    The reason being is if $_SESSION['OBSOLETE'] is not set then $_SESSION['OBSOLETE'] can’t equal true, because it isn’t set.

  25. Guys few remarks:

    1. $_SERVER['remote_addr'] is a CGI variable and it cannot be trusted. If the hacker did fixate the session of the user, then he did communicate with him already. It is very common that he will already have all his CGI headers;
    2. Some firewalls block the CGI headers;
    3. YOU ARE BLOCKING USERS OF NAT NETWORKS. AOL users for example regularly change their IP’s dynamically. You definitely kick these users out of the system. You DO NOT WANT THAT :)

    Cheers

  26. Hi
    can someone explain how to use this class? in a login i can save username and password to the session but what do i do when logout?
    in addition when i start the session and i set the $limit to 10 the session variables still hold after 10 seconds.

    hope someone can explain with good details.

    best regards

  27. Pingback: How to Enlarge Penis

  28. it doesn’t work for me either. I read elsewhere that session_start() should be the very first function call in your php script.

  29. looks like in a lot of places it is written “$ SESSION…” when it should be written “$_SESSION…”