What Is Session Fixation

Session fixation is a web attack technique. The attacker tricks the user into using a specific session ID. After the user logs in to the web application using the provided session ID, the attacker uses this valid session ID to gain access to the user’s account.

Session Identifiers: The Good, the Bad, and the Ugly

Session identifiers are used to authenticate users in web applications. This technology has its advantages and disadvantages. If not for session identifiers, we would have to log in to web applications much more frequently than we do. However, a session identifier has the same weakness as a password: the moment that someone knows it, they get access to your account, which may then be used for further attacks and potential privilege escalation.

Attackers get session identifiers in any way that they can. They can use social engineering, phishing, and other measures. There are several attack techniques related to sessions. Session hijacking is all about getting an existing session ID from a logged-in user, for example, using man-in-the-middle techniques to infiltrate communication between the victim’s browser and the web server. In the case of session fixation, the situation is reversed. The victim gets an existing session ID and is tricked into logging in using this identifier, which lets the attacker take over the user’s session later.

Anatomy of a Session Fixation Attack

A typical session fixation attack is performed as follows:

1. The attacker accesses the web application login page and receives a session identifier generated by the web application. This step is not necessary if the web application accepts arbitrary session IDs.
2. The attacker uses an additional technique such as CRLF Injection, man-in-the-middle attack, social engineering, etc., and gets the victim to use the provided session identifier. This depends on how the web application handles session IDs. It may be as simple as sending a malicious URL but may also require the attacker to create a fake website.
3. The victim accesses the web application login page and logs in to the application. After authenticating, the web application treats anyone who uses this session ID as if they were this user.
4. The attacker uses the session identifier to access the web application, take over the user session, and impersonate the victim. Further actions depend on the attacker and web application functionality.

The exact stages of the attack and its difficulty depend on several factors. For example, a lot depends on how the application handles session IDs. If the application accepts session IDs from the URL (via a GET request), the attack is trivial. If the application accepts session IDs from POST requests, the attacker may need to create a fake phishing site. It gets more difficult (but not impossible) if session IDs are only accepted from cookies – the attacker must then use techniques such as Cross-site Scripting (XSS).

Session Fixation Countermeasures

The only causes of session fixation are insufficient web application security and bad coding practices associated with session management:

• In the worst case, developers don’t check the validity of session identifiers and any string (or any string of a specific format) may be provided as a session ID. This makes session fixation attacks trivial.
• Very often, developers assign the session ID before the user is logged in and never change it. This is the main cause of typical session fixation attacks.
• If developers accept session IDs from GET or POST requests, they make it easier for the attacker to forcefully set a session ID for the user.

There are several ways to avoid session fixation vulnerabilities:

• The standard method is to change the session ID right after the user logs in. This eliminates most session fixation vulnerabilities.
• An additional countermeasure is to change the session ID with the slightest suspicion of potential wrongdoing. For example, the web application may test whether the IP address or the user-agent of the client changed and if it did – provide a new session ID.
• You should also invalidate session IDs after a timeout. For example, 10 minutes of no activity should cause an automatic logout. This gives the attacker a small window of opportunity to use the fixed session ID.
• Some sources recommend changing the session IDs with every user action. However, this is a drastic, unnecessary, and potentially harmful – it may impact user experience and performance (for example, it might be impossible when using applets). To minimize the impact, you may change the session ID before every important user action on the website.
• Remember to use session cookies for session management and do not accept session IDs from HTTP requests and HTTP headers.
• HTTPS (HSTS), anti-CSRF tokens, and suitable cookie flags (Secure, SameSite) can be helpful in avoiding session fixation, too.

You may use a web vulnerability scanner to check if your website or web application has any session fixation vulnerabilities but you must remember that session fixation is similar to logical vulnerabilities and very difficult to detect automatically.