Session fixation

What is session fixation?

In a session fixation attack, the attacker tricks the user into using a specific session ID. When the user logs in to a web application using that ID, the attacker knows the victim’s valid session ID and can use it to gain access to the user’s account.

How do session identifiers work?

Session identifiers (SIDs), sometimes called session keys or session tokens, are character strings used to authenticate users in web applications. These strings are generated by an application after the user successfully logs in, presented to the user’s browser, and used across different pages or functions of the application, usually via a session cookie. Since the web browser shares the session cookie with the application in every HTTP request, the application can use the session identifier to recognize a known user.

If it weren’t 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: it is only secure while it is secret. As soon as a malicious user knows your session ID, they can get access to your account and use it for further attacks and potential privilege escalation.

What attacks are related to session identifiers?

In general, malicious hackers will try to get access to session identifiers to impersonate users and gain access to their accounts/privileges. There are several specific attack techniques targeting sessions:

• Session hijacking is all about getting an existing session ID from a logged-in user, for example, using man-in-the-middle (MITM) techniques to infiltrate communication between the victim’s browser and the web server.
• Session fixation uses a different approach to obtain a valid ID. The attacker generates a session ID or has the web application generate one and then tricks the victim into logging in using this identifier, allowing the attacker to take over the user’s session later.
• Session prediction exploits weaknesses in the way that session IDs are generated. If the process is not fully random and the attacker figures out the algorithm, they can generate valid session IDs. If the session identifiers are short enough, attackers could even use brute force to guess a valid identifier.

What makes a web application vulnerable to session fixation attacks?

Session fixation is not a specific type of vulnerability like SQL injection or cross-site scripting. An application may be vulnerable to session fixation attacks due to insufficient web application security and bad coding practices associated with session management:

• The worst-case scenario is when developers don’t check the validity of session identifiers, so the application will accept any string of a specific format 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 allow session IDs to be set or reset from GET or POST requests, they make it easier for attackers to forcefully set a session ID for the user.

Vulnerabilities that make an application susceptible to session fixation attacks are classified in the OWASP Top 10 2021 as A07:2021 – Identification and Authentication Failures.

Session fixation attack example

A typical session fixation attack is performed as follows:

1. The attacker accesses the login page of a vulnerable application and receives a session identifier generated by the web application. This step is not necessary if the application accepts arbitrary session IDs.
2. The attacker uses an additional technique, such as CRLF Injection, man-in-the-middle attack, social engineering, open redirection, and so on, to get the victim to use the provided session identifier. The specific method depends on how the web application handles session IDs. It may be as simple as sending a malicious URL or may require the attacker to create a fake website.
3. The victim accesses the login page and logs in to the application. After authentication, the application will treat anyone using the same session ID as if they were the targeted user.
4. The attacker uses the victim’s session identifier to access the web application, take over the user session, and impersonate the victim. Further actions will depend on the attacker and web application functionality.

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

Example of code vulnerable to session fixation

The following is an example of PHP code that is vulnerable to session fixation:

<?php
  session_start();
  if (isset($_GET['SESSIONID'])) 
  {
    session_id($_GET['SESSIONID']);
  }
  $_SESSION['logged_in'] = true;
?>

The SESSIONID parameter is passed in the query string of the URL, for example, https://www.example.com/index.php?SESSIONID=b9e9cfd3f8b72e2af3e3c3f, and the server uses it to set the session ID. An attacker can simply send the victim a link with a specific SESSIONID value and when this is opened, the victim's browser will use that value as the session ID.

To fix this code and prevent session fixation, you can use the session_regenerate_id function to generate a random session ID every time the user logs in or performs a sensitive action:

<?php
  session_start();
  if (isset($_POST['username']) && isset($_POST['password'])) 
  {
    if (login_successful())
    {
      session_regenerate_id(true);
      $_SESSION['logged_in'] = true;
    }
  }
?>

How to detect session fixation vulnerabilities?

The best way to detect if your application is vulnerable to session fixation depends on whether you use ready-made software or whether you develop software on your own.

• If you only use commercial or open-source software and do not develop software of your own, it may be enough to identify the exact version of the system, application, or add-on you are using. If the identified version is known to be vulnerable to session fixation attacks, you can assume that your software is also vulnerable. You can identify the version manually or use a suitable security tool, such as a software composition analysis (SCA) solution.
• If you develop your own software or want the ability to potentially find previously unknown session fixation vulnerabilities (zero-days) in known applications, you need to perform manual penetration testing with the help of security researchers and use a vulnerability scanner tool that supports session fixation vulnerability detection. Examples of such tools are Invicti and Acunetix by Invicti. Note that many session fixation vulnerabilities are similar to logical vulnerabilities and impossible to detect automatically, so automatic vulnerability scanning without additional penetration testing may not be enough.

How to prevent session fixation attacks?

There are several ways to prevent session fixation attacks by using secure coding practices:

• 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 upon every slightest suspicion of malicious action. For example, a web application might check for changes to the client’s IP address or user-agent string and generate a new session ID every time a change is detected.
• You should also invalidate session IDs based on a timeout. For example, 10 minutes of inactivity might cause an automatic logout. This limits the window of opportunity available to attackers attempting to fix a session ID.
• Some sources recommend changing the session ID with every user action. In practice, this is unnecessarily drastic and potentially even harmful to the user experience and application performance (for example, it might be impossible when using applets). To minimize the impact of such frequent changes, you may want to change the session ID only before especially important user actions on the website.
• Remember to only use session cookies for session management and do not accept session IDs from HTTP requests or HTTP headers.
• General security best practices such as using HTTPS (HSTS), anti-CSRF tokens, and suitable cookie security flags (setting Secure and SameSite) can also be helpful in avoiding session fixation.