7

I am trying to prevent session fixation and have read the following from the owasp website:

Session Fixation

Session IDs are to be generated by your application only. Never create a session only because you receive the session ID from the client, the only source of creating a session should be a secure random generator.

I handle sessions by using: 

ini_set('session.use_only_cookies', 1); // Forces sessions to only use cookies. 
ini_set('session.entropy_file', '/dev/urandom'); // better session id's
ini_set('session.entropy_length', '512');
session_start();

and checking for the existence of a user id:

if(isset($_SESSION['user_id'])) {
    //act like user is logged in
} else {
    //refer user to the login page
}

Does this mean the only source of creating my session is via a secure random generator?

Hard worker
  • 3,916
  • 5
  • 44
  • 73
  • possible duplicate of [Php session fixation example and fixes](http://stackoverflow.com/questions/10715002/php-session-fixation-example-and-fixes) – Markus Malkusch Jan 09 '14 at 14:25
  • Does that duplicate address my question? The second half of the sentence – Hard worker Jan 09 '14 at 15:18
  • No, it does not relate to the source of session id. However I had the impression that actual your requirement is to prevent SF effectively. Therefore the source of session id is irrelevant. The referred question addresses SF effectively. – Markus Malkusch Jan 09 '14 at 15:30
  • I disagree. Please see deceze's answer - the user of session.use_strict_mode answers my question and clarifies the situation. – Hard worker Jan 09 '14 at 16:04

2 Answers2

9

By default PHP is prone to session fixation:

A simple attack scenario

Straightforward scenario:

  1. Mallory has determined that http://unsafe.example.com/ accepts any session identifier, accepts session identifiers from query strings and has no security validation. http://unsafe.example.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.example.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.example.com/?SID=I_WILL_KNOW_THE_SID. The usual log-on screen pops up, and Alice logs on.
  4. Mallory visits http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID and now has unlimited access to Alice's account.

http://en.wikipedia.org/wiki/Session_fixation

session.use_strict_mode boolean

session.use_strict_mode specifies whether the module will use strict session id mode. If this mode is enabled, the module does not accept uninitialized session ID. If uninitialized session ID is sent from browser, new session ID is sent to browser. Applications are protected from session fixation via session adoption with strict mode. Defaults to 0 (disabled).

http://php.net/manual/en/session.configuration.php#ini.session.use-strict-mode

Enabling session.use_strict_mode prevents PHP from accepting ids of non-existing sessions and creating them. This does not prevent other types of session fixation though:

Attack using server generated SID

A misconception is that servers which only accept server generated session identifiers are safe from fixation. This is false.

Scenario:

  1. Mallory visits http://vulnerable.example.com/ and checks which SID is returned. For example, the server may respond: Set-Cookie: SID=0D6441FEA4496C2.
  2. Mallory is now able to send Alice an e-mail: "Check out this new cool feature on our bank, http://vulnerable.example.com/?SID=0D6441FEA4496C2."
  3. Alice logs on, with fixated session identifier SID=0D6441FEA4496C2.
  4. Mallory visits http://vulnerable.example.com/?SID=0D6441FEA4496C2 and now has unlimited access to Alice's account.

This can be prevented by session.use_only_cookies, which is on by default.

You may still be vulnerable to yet more session fixation attacks through XSS, which you will have to counteract with measures other than PHP ini settings.

deceze
  • 510,633
  • 85
  • 743
  • 889
  • 1
    `session.use_strict_mode` won't prevent Session Fixation. The attacker doesn't have to invent a session id. – Markus Malkusch Jan 09 '14 at 13:04
  • 1
    It prevents "the creation of session ids from any source other than a RNG" (paraphrased), what the OP asked about. – deceze Jan 09 '14 at 13:05
  • Your post implies with your very first sentence that `session.use_strict_mode` could make PHP unprone against Session Fixation. – Markus Malkusch Jan 09 '14 at 13:07
  • Thank you deceze. This actually answers the question. use_strict_mode is exactly what I was looking for. – Hard worker Jan 09 '14 at 15:24
  • i'm completely new to php. how do i enable these in `php.ini`. i can't find those settings in that file? – oldboy Aug 07 '17 at 22:48
2

Session IDs are to be generated by your application only.

That quote from OWASP PHP Security Cheat Sheet is wrong. Restricting the source of the session id has no effect on Session Fixation. An attacker can go to your site and just grab a valid session id.

The passage was fixed and gives now an effective method for preventing Session Fixation:

Invalidate the session id after user login (or even after each request) with session_regenerate_id().

Markus Malkusch
  • 7,738
  • 2
  • 38
  • 67
  • I agree that is an effective method but was puzzled by the quote I give you guys. The reference is here: https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet#Session_Fixation – Hard worker Jan 09 '14 at 15:17
  • We may stop puzzling. The quote is no longer valid. – Markus Malkusch Jan 10 '14 at 20:55
  • @Anthony yes. The idea of [Session fixation](https://en.wikipedia.org/wiki/Session_fixation) is making a user with a known session id to login (e.g. "Hey Anthony, could you please check your emails at 'gmail.com?sid=IKnowThisId'"). If the application changes the session id after login, an attacker cannot use the previous known session id. – Markus Malkusch Aug 10 '17 at 07:24