Php session fixation example and fixes

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;

Answer 2

If you use session_regenerate_id() everytime a user logs in you will prevent session fixation. As the user logs in, their fixated session ID will be regenerated and thus stopping the attack.