Question

My question is about this summary on session fixation:

• Alice has an account at the bank http://unsafe.com/. Unfortunately, Alice
  is not very security savvy.

• Mallory is out to get Alice’s money from the bank.

• Alice has a reasonable level of trust in Mallory, and will visit
  links Mallory sends her.

  1. Mallory has determined that http://unsafe.com/ accepts any session
     identifier, accepts session identifiers from query strings and has
     no security validation. http://unsafe.com/ is thus not secure.
  2. Mallory sends Alice an e-mail: “Hey, check this out, there is a cool new
     account summary feature on our
     bank,http://unsafe.com/?SID=I_WILL_KNOW_THE_SID”. Mallory is trying to
     fixate the SID to I_WILL_KNOW_THE_SID.
  3. Alice is interested and
     visits http://unsafe.com/?SID=I_WILL_KNOW_THE_SID. The usual log-on
     screen pops up, and Alice logs on.
  4. Mallory visits http://unsafe.com/?SID=I_WILL_KNOW_THE_SID and now has unlimited access
     to Alice’s account. (credit: RichieHindle)

Questions:

Q1 – Is there a way to explicitly prevent the site from accepting any
session identifier?

Q2 – I don’t use the $_GET variable on my site so is there a way to prevent accepting session identifiers from query strings?

• Notes: I’m using php 5.4.3 with SSL and will also use session_regenerate_id..

Answer 1

You could set the options martinstoeckli mentioned in his answer, but this won’t prevent session fixation. It makes session fixation a little harder to attack, but it doesn’t prevent it.

As ServerBloke mentioned, you prevent session fixation by using session_regenerate_id() immediately after verifying the user’s login information and before you show the first page that requires authentication.

Making it harder for the attacker to exploit session fixation does not prevent session fixation. You must generate a new session ID.

More and more, people are using public unsecured untrusted wi-fi hot spots. Sessions can be sniffed from the air. On a physical network, they can be sniffed off the wire. They can also force you to visit any URL by employing a man-in-the-middle attack. So, session fixation is still a problem, even if the attacker can’t send you URLs.

Knowing that sessions (and passwords) can be sniffed, there is another step that is required to prevent session hijacking. That is HTTPS (TLS/SSL).

All protected pages that require authentication should be accessed only over HTTPS. So, the login page (the one where the user sends their username and password) should be accessed via HTTPs. In that same script, you must regenerate a new sessionID. All pages for the remainder of the session must then be accessed via HTTPs to protect the new session ID.

Here’s an example pseudocode login.php script:

// Force SSL
if($_SERVER["HTTPS"] != "on") {
  die('Must login via HTTPS');
}

// Load the current sessionID
session_start();

// Validate the login information, being sure to escape the input
...
if (! $valid) {
  die('Invalid login');
}

// Start the new session ID to prevent session fixation
session_regenerate_id();

// Clear the old session
$_SESSION=array();

// Log them in
$_SESSION['user_id'] = $userID;