A major concern regarding sessions is the secrecy of the session identifier. If this is kept secret, there is no practical risk of session hijacking. With a valid session identifier, an attacker is much more likely to successfully impersonate one of your users.

An attacker can use three primary methods to obtain a valid session identifier:

1. Prediction
   
2. Capture
   
3. Fixation

PHP generates a very random session identifier, so prediction is not a practical risk. Capturing a session identifier is more common—minimizing the exposure of the session identifier, using SSL, and keeping up with browser vulnerabilities can help you mitigate the risk of capture.

Keep in mind that a browser includes a Cookie header in all requests that satisfy the requirements set forth in a previous Set-Cookie header. Quite commonly, the session identifier is being exposed unnecessarily in requests for embedded resources, such as images. For example, to request a web page with 10 images, the session identifier is being sent by the browser in 11 different requests, but it is needed for only 1 of those. To avoid this unnecessary exposure, you might consider serving all embedded resources from a server with a different domain name.

Session fixation is an attack that tricks the victim into using a session identifier chosen by the attacker. It is the simplest method by which the attacker can obtain a valid session identifier.

In the simplest case, a session fixation attack uses a link:

  <a href="http://example.org/index.php?PHPSESSID=1234">Click Here</a>

Another approach is to use a protocol-level redirect:

  <?php

  header('Location: http://example.org/index.php?PHPSESSID=1234');

?>

The Refresh header can also be used—provided as an actual HTTP header or in the http-equiv attribute of a meta tag. The attacker’s goal is to get the user to visit a URL that includes a session identifier of the attacker’s choosing. This is the first step in a basic attack; the complete attack is illustrated in Figure 4-3.

Figure 4-3.  A session fixation attack uses a session identifier chosen by the attacker

If successful, the attacker is able to avoid the necessity of capturing or predicting a valid session identifier, and it is possible to launch additional and more dangerous types of attacks.

A good way to better understand this is to try it yourself. Begin with a script named fixation.php:

  <?php

  session_start();

  $_SESSION['username'] = 'chris';

  ?>

Ensure that you do not have any existing cookies for the current host, or clear all cookies to be certain. Visit fixation.php and include PHPSESSID in the URL:

  http://example.org/fixation.php?PHPSESSID=1234

This creates a session variable ( username ) with a value of chris . An inspection of the session data store reveals that 1234 is the session identifier associated with this data:

Create a second script, test.php, that outputs the value of $_SESSION['username'] if it exists:

  <?php

  session_start();

  if (isset($_SESSION['username']) )
  {
    echo $_SESSION['username'];
  }

  ?>

Visit this URL using a different computer, or at least a different browser, and include the same session identifier in the URL:

  http://example.org/test.php?PHPSESSID=1234

This causes you to resume the session you began when you visited fixation.php, and the use of a different computer (or different browser) mimics an attacker’s position. You have successfully hijacked a session, and this is exactly what an attacker can do.

Clearly, this is not desirable. Because of this behavior, an attacker can provide a link to your application, and anyone who uses this link to visit your site will use a session identifier chosen by the attacker.

One cause of this problem is that a session identifier in the URL is used to create a new session—even when there is no existing session for that particular session identifier, PHP creates one. This provides a convenient opening for an attacker. Luckily, the session_regenerate_id() function can be used to help prevent this:

  <?php

  session_start();

  if (!isset($_SESSION['initiated']))
  {

    session_regenerate_id();
    $_SESSION['initiated'] = TRUE;
  }

  ?>

This ensures that a fresh session identifier is used whenever a session is initiated. However, this is not an effective solution because a session fixation attack can still be successful. The attacker can simply visit your web site, determine the session identifier that PHP assigns, and use that session identifier in the session fixation attack.

This does eliminate the opportunity for an attacker to assign a simple session identifier such as 1234 , but the attacker can still examine the cookie or URL (depending upon the method of propagation) to get the session identifier assigned by PHP. This approach is illustrated in Figure 4-4.

To address this weakness, it helps to understand the scope of the problem. Session fixation is merely a stepping-stone—the purpose of the attack is to get a session identifier that can be used to hijack a session. This is most useful when the session being hijacked has a higher level of privilege than the attacker can obtain through legitimate means. This level of privilege can be as simple as being logged in.

If the session identifier is regenerated every time there is a change in the level of privilege, the risk of session fixation is practically eliminated:

  <?php

  $_SESSION['logged_in'] = FALSE;

  if (check_login())
  {
    session_regenerate_id();
    $_SESSION['logged_in'] = TRUE;
  }

  ?>

Figure 4-4.  A session fixation attack can first initialize the session

I do not recommend regenerating the session identifier on every page. While this seems like a secure approach—and it is—it provides no more protection than regenerating the session identifier whenever there is a change in the level of privilege. More importantly, it can adversely affect your legitimate users, especially if the session identifier is being propagated in the URL. A user might use the browser’s history mechanism to return to a previous page, and the links on that page will reference a session identifier that no longer exists.

If you regenerate the session identifier only when there is a change in the level of privilege, the same situation is possible, but a user who returns to a page prior to the change in the level of privilege is less likely to be surprised by a loss of session, and this situation is also less common.