Servage Magazine

Session fixation is similar to session hijacking. The fixation method means the attacker obtains a valid session ID from the application whereafter the attacker gets the victim to use the same session ID. The hijacking method means the attacker gets to know the identifier for an existing user session. Either way the session will thereafter be known to the attacker who can present himself as the user to the application. This is dangerous because if an attacker can make the application believe to be the user, the attacker can essentially do whatever the user would be able to do. It is like having forgotten to logout whereafter someone takes over the computer and continues as that previously logged-in user.

Understanding how sessions work

It is important to understand exactly how sessions work to be able to identify and solve problems regarding session fixation and hijacking. The user gets a unique session identification whenever you start a session through your script. The following example is based on PHP, but it is essentially the same process in any language. The session can have a limited or unlimited lifetime. That depends on the way you pass the session identifier from request to request and for how long you store the session data on the server.

// Starting a session initiates the process of being able to handle $_SESSION data in PHP
session_start();

Preventing fixation

URL-based session handling appends the session URL to every request. This method is not preferred because it creates unattractive URLs with an appended GET parameter and it makes URL-based caching more tricky. Furthermore this is a potential way of starting session fixation by distributing such links to unsuspecting users with a preset valid session ID.

http://mydomain.com/some/page?PHP_SESSID=xxx

Cookie based session handling creates a cookie with the session ID. This method is preferred because it does not append anything to the URL while the cookie provides good options for controlling the client-side session lifetime. You can make the cookie expire when the user closes the browser window, or define any time-based cookie lifetime you prefer. Remember to delete redundant session data on the server as well, if applicable.

Preventing hijacking

You can do two things to effectively fight hijacking attempts. Change the session ID on every request so an attacker cannot continue with an exposed session ID even if the attacker knows the current session identifier’s value.

// Change the session ID on every request
session_regenerate_id();

The second defense is adding some security checks to your session handler to make sure the client is the same that started the session. It is suggested that you check the client’s browser and IP address. Notice that whatever information you use in such checks can potentially be spoofed by the attacker, thus providing only a limited help for security. Furthermore beware that IP addresses for sessions can change for valid reasons, which should be considered in the check.

Additional checking could be done by adding another cookie with a value that changes on every request. Thereby not only the session ID has to be valid together with the browser and IP coming from the same device, but another secret value also has to be presented by the client in order to be trusted as the correct session owner.

References & more reading

• W3 Schools PHP Sessions
• PHP Session Handling