[PHP Series] Session Identifier Acquirement and Session Hijacking

[Byte-ul]

An Overview of Sessions

How are They Used?

• Sessions are a solution to the stateless nature of the HTTP protocol. They enable requests made by the same web user to be linked to one another in the form of transactions, allowing for sequential tasks to be performed. This could be anything, like logging into an account (privilege change), adding items to a shopping cart, proceeding through a checkout system, etc. These are all tasks that require a state to be maintained.

So, What Actually are They?

• Sessions are, by default, stored in temporary files on the web server. Each of these temporary session files hold all information being stored as session data by your web application. Every session has a unique ID (often referred to as the session identifier) that is randomly generated. This session identifier is, by default, stored in cookie held on a web users computer. The cookie is created upon initiating the session (hence why session initiation must come before any output to the screen - because cookies are apart of the HTTP header). Upon subsequent page requests, the cookie is read by the web server, and the session ID is looked up against the temporary files to see if the (re-)visiting user can resume their session.

Session Identifier Acquirement

The secrecy of a session identifier is critical to a session's security. An attacker typically has three options when it comes to acquiring a valid session identifier:

Prediction

• 
  Prediction of the session identifier will be the least of your worries. The generation of session IDs is sufficiently random to not need to worry about this attack vector (and so no preventative measures need to be issued).

Capture

• Capturing a session identifier involves looking at other targets to attack where the session ID is kept. Because cookies (by default) propagate the session identifier, they have become a common target when attempting to capture a valid session identifier. Browser vulnerabilities can help attackers expose cookie information, though because of the rarity of these types of attacks, you need not worry too much about them.

Fixation

• Fixation of a session identifier is where the session ID is set by an attacker in the query string of a URI (usually in the form of ?PHPSESSID=...), forcing the user clicking that link to use that given session identifier. This attack vector used to be a lot easier when session IDs could be passed via the URI. On newer versions of PHP however, the PHP.ini file now has the session.use_trans_sid directive turned off (set to zero) by default. (If your session.use_trans_sid is enabled for some reason or another, then you may want to think about turning it off.) Thus, this security problem is not as much of a concern for us anymore - but that's not to say we should just ignore it.
  It's considered good practice to invoke the

session_regenerate_id() when there has been a privilege change in your application (be sure to set the optional parameter to true to delete the old session data). This will ensure that a new session identifier is regenerated to keep your user sessions secure when a change in privilege has occurred and is another preventative measure to session fixation attacks.

Session Hijacking

Session Hijacking is an attempt to gain access to a user's session to impersonate them. In order for an attacker to hijack a user's session, they must first gain their session identifier (through one of the aforementioned methods). This in itself is not trivial process, and we can aim to make session hijacking even more difficult through looking for consistency in each users behaviour (and therefore requiring authentication for inconsistent behaviour - like re-logins).

One method of preventing this is to look for consistency in the requests made by the user agent header (accessible by the variable $_SERVER['HTTP_USER_AGENT'] variable). We can hash the user's browser agent (such as with md5), and store that as apart of the session. This can then be checked upon subsequent requests:

<?php

session_start();

if(!isset($_SESSION['user_agent'])) {
    $_SESSION['user_agent'] = md5($_SERVER['HTTP_USER_AGENT']);
}else{
    if($_SESSION['user_agent'] !== md5($_SERVER['HTTP_USER_AGENT']) {
      // potentially an imposter - authenticate user with a login page
    }
}

A second method of prevention of session hijacking has already been described earlier, in cross-site request forgery attacks. The idea is exactly the same, where a nonce (a uniquely generated token) is passed via the URI to ensure each request is successfully submitted by that user and that user alone.

Credits: http://www.hackforums.net/showthread.php?tid=4238146