Session Fixation Attack

In this article…
What is Session Fixation?
Is your site vulnerable?
Protecting against Session Fixation?

What is Session Fixation?
In a session fixation attack, the attacker fixes the user’s session ID before the user even logs into the target server, thereby eliminating the need to obtain the user’s session ID afterwards. This is accomplished by the attacker first going to the website and obtaining a valid session ID. Then the attacker sends a link that contains that session ID to an unsuspecting victim. The victim clicks on the link, goes to the website and logs in. Now, the attacker sends another request to the website, say for the account information page. Since the attacker also sends the same session ID as the logged in victim, the website thinks they are the same user and sends the attacker the requested information. This results in the session being hijacked.

Session Fixation

  1. Attacker connects to the server
  2. The server generates a session token and sends it to the attacker
  3. Crafts a URL containing the session token and emails it out
  4. Victim clicks on the link and logs in to the site with the same session token
  5. Server thinks it is the same user and retains session token
  6. Attacker sends another request to the server with the session token and hijacks the victim’s session

Crafting a URL and emailing it out is just one method among many to set a victim’s cookie. If some page or sub host on the same domain is also vulnerable to XSS (cross-site scripting) attacks, that can be exploited to set the client’s cookie value with the appropriate session token. This method stands a better chance of success since email links may not be clicked on by users, but users may visit the vulnerable URL(s) on the website that they are already on.

Is your site vulnerable?
This type of attacks typically happens when the server accepts arbitrary session tokens. This can be found in ‘permissive’ servers such as PHP which create a new session with proposed session ID if one doesn’t exist yet. ‘Strict” servers such as IIS only accept known session IDs, which have been locally generated at some point in the past.

Protecting against Session Fixation
The best way to protect your applications from session fixation attacks is to regenerate session ID immediately after the user logs in or whenever the user’s privilege level changes. This ensures that the session ID that the attacker knows will not be used by the intended victim anymore. The session cannot be hijacked anymore, at least with this method.

PHP
session_regenerate_id(TRUE);
The 'TRUE' parameter value will ensure that the old session data is deleted on the server.

.Net
Session.Abandon()
Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", ""));
The second line will ensure that a new session id is generated, instead of just the session state being cleared and session id reused.

J2EE
session.invalidate()
session.putValue("User",strUserId);

Irrespective of the programming language, regenerating the session ID on login is good practice.

The length of the timeout interval may need to be considered based on the type of application. Most servers use a default value of 20 minutes. Any increase should be carefully evaluated. Increasing the session timeout interval increases the risk of sessions being hijacked. High risk applications should typically have a timeout interval of 5 minutes and medium/low risk should generally not have a timeout more than 20 minutes.

If the tokens are application generated, care should be taken that they are not reused and that the token generation algorithm does not come up with duplicate tokens.