Trying to make sense of “Strict Sessions”

[Jacques1]

Hi,

 

PHP 5.5 has introduced a (little-known) feature called “Strict Sessions” which is supposed to prevent session fixation. It will reject any session ID for which there's no corresponding session file, so it's no longer possible for users to have PHP adopt their own ID. For a detailed description, see the RFC.

 

Does anybody have any idea how this approach is useful?

 

The article goes into a lengthy discussion of how it's possible for an attacker to override the native session cookie with a custom cookie. No doubt about that. But how is that relevant? People can override my session ID all day long. The only thing I do not want is that PHP stores my user ID in one of those sessions in the login procedure. And this can easily be prevented with session_regenerate_id().

 

Furthermore, “Strict Sessions” obviously do not prevent an attacker from obtaining a valid session ID from the application and using that for a session fixation attack. There's simply no need to make up an ID.

 

Am I missing something? Or is this just yet another “genius security feature” along the lines of Magic Quotes?

 

[Psycho]

Look at the response in this forum post: http://stackoverflow.com/questions/21020294/preventing-session-fixation-by-ensuring-the-only-source-of-creating-a-session-sh

 

It seems that a malicious attack isn't about the user trying some random session ID. The malicious user would trick an unsuspecting user to visit an unsecured site using a session ID that the malicious user has defined. once the user logs in the malicious user could then hijack their session.

[Jacques1]

I understand the concept of session fixation attacks. The problem is that I don't see how “Strict Sessions” are supposed to prevent this.

 

An attacker doesn't have to make up their own ID. They can simply obtain a fresh one from the application and use that. This will pass all checks of the “Strict Sessions” feature.

 

At the same time, session fixation can easily be stopped by calling session_regenerate_id() in the login procedure. Even if an attacker has managed to set a custom session ID in the victim's browser, now the session has a new ID.