Session fixation protection: How to stop session fixation attacks

Question: What is session fixation and how can I protect my users from it?

Session fixation is a vulnerability caused by incorrectly handling user sessions in a Web application. A user’s session is usually tracked by a cookie, which is assigned when the user visits the page with the Web application for the first time. The problem occurs when this cookie does not change for the duration of the browsing session; users authenticate and log out, but their session cookie remains the same. This is often the default behaviour of an application.

This introduces a flaw into the authentication process. If a malicious user visits the Web application (usually from a shared computer, for example in a library), he or she would be assigned a session cookie. The malicious user could then record the cookie’s value and leave the browser open. If another user then arrives and authenticates from the same machine, the malicious user would now have the session cookie of an authenticated user, and, using simple tools, could send a request to the Web application that contains the compromised cookie. This would grant the malicious user full access to the authenticated user’s account until that user logs out, usually ample time to change the user’s password or registered email address.

Session fixation attacks occur in both vendor-supplied applications and custom-written applications, but are much more prevalent in the latter.

In certain cases, session fixation can be achieved remotely, which bypasses the hurdle of using a shared computer to complete the attack. This takes advantage of further mistakes in session management, and can be achieved in two ways.

In the first scenario, sessions are not handled by cookies, but by a static parameter in the URL of the Web application. This is usually a long, random value that is assigned to a user in a similar fashion to a cookie. However, if this value does not change when the user authenticates, it will be possible to remotely fix the user’s session. An attacker could send a phishing email to users of the application that contains a valid session identifier in the URL. When a user clicks the link, he or she will be taken to the legitimate website, but will be assigned a session identifier that is known by the attacker. Then, using the same technique as above, when the user authenticates, the attacker will be able to gain access to the user's account.

In the second scenario, the attacker takes advantage of a behaviour of applications that include the session cookie as a value in the URL. Some insecurely developed or configured applications will set the cookie based on the value specified in the URL, which allows an attacker to use the same phishing techniques as above to gain access to a user’s account.

There are no tools available for session fixation protection; the defence is in coding Web applications correctly. To defend against session fixation, ensure your Web application developers code their applications so they assign a different session cookie immediately after a user authenticates to the application, and also verify they do not include the cookie value in the URL. By taking these precautions, you’ll ensure no one can gain access to the cookie before the user authenticates.