For years PHP has been vulnerable to session adoption which can enable session fixation. And since sessions are a major part of web applications now a days. A lot of platforms are open and waiting for an attack to happen.
session adoption & session fixation
The problem exists because the current session module does not validate the session id that comes in from a cookie. This means uninitialized session id’s can be passed by the client. This happens due to the fact that browsers overwrite cookie if multiple cookies are send per request. Some people would say this is solvable by implementing session_regenerate_id(). But this is not the case.
Because session fixation can be used to take over control of web applications. Validation is required when multiple cookies are send per request. When multiple cookie are send with a request. Browsers send multiple cookies without domain / path information. This way it’s impossible to tell which cookie belongs to which domain.
So how do we fix this?
There is some userland code that does offer the ability to validate session data. But this has not been widely adopted by other developers.
Code that adds the session ID as a validation key:
And the code to check if the session was properly initialized:
Thank god the internal developer know this. And are working to fix this. For the past days there has been an interesting discussion going on on the internals list. About applying a patch that will fix this. The patch will add some new php.ini features and a new method validate_id() for the session save handler. Hopefully this will be available in version 5.4.
To not break BC strict_mode will be disabled by default. But can be enabled by setting the following setting in php.ini. When enabled uninitialized session ID will be discarded.
To prevent a DoS instead of session fixation. An new feature has been added that deletes possible malicious cookies that prevent new session ID.
You can read more about session fixation and the upcoming patch on the PHP-Wiki