What is Session Fixation? Ways to Exploit, Examples and Impact

In the landscape of web security, session management is the backbone of user authentication. However, if not implemented correctly, it can become a primary target for attackers. Session fixation is a critical vulnerability where an attacker tricks a victim into using a specific session ID, allowing the attacker to hijack the user's session once they authenticate. Understanding this flaw is essential for developers and security professionals who aim to build resilient applications.

Understanding the Basics of Session Management

To understand session fixation, we must first understand how web applications maintain state. Because HTTP is a stateless protocol, servers do not "remember" users between requests. To solve this, developers use sessions. When a user visits a website, the server generates a unique identifier—a Session ID—and sends it to the user's browser, typically via a cookie. For every subsequent request, the browser sends this ID back, allowing the server to recognize the user.

In a secure environment, the session ID is generated only after a successful login. However, many applications generate a session ID the moment a user lands on the homepage, even before they provide credentials. This "pre-authentication" session is where the vulnerability lies.

What is Session Fixation?

Session fixation is a type of attack where an adversary provides a valid session ID to a victim and forces the victim's browser to use it. Unlike session hijacking, where an attacker steals an existing active session ID, session fixation involves the attacker choosing the session ID beforehand.

If the application does not change the session ID upon a successful login, the attacker—who already knows the ID—can use it to gain full access to the victim's account. Essentially, the attacker leaves a "trap" session ID, waits for the user to log in with it, and then walks through the front door using the same key.

How a Session Fixation Attack Works

The lifecycle of a session fixation attack generally follows three distinct phases: preparation, fixation, and exploitation.

1. Preparation

First, the attacker visits the target website (e.g., https://example.com) to obtain a valid session ID from the server.

GET / HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Set-Cookie: PHPSESSID=12345abcde; path=/; HttpOnly

The attacker now knows that 12345abcde is a valid, unauthenticated session ID recognized by the server.

2. Fixation

The attacker must now force the victim to use this specific ID. There are several ways to achieve this, depending on how the application accepts session identifiers.

• URL Parameters: If the application accepts session IDs in the URL, the attacker sends a link to the victim: https://example.com/login?PHPSESSID=12345abcde.
• Cross-Site Scripting (XSS): If the site is vulnerable to XSS, the attacker can execute a script in the victim's browser to set the cookie: document.cookie="PHPSESSID=12345abcde";.
• Meta Tags: In some cases, an attacker might use an injected <meta> tag: <meta http-equiv="Set-Cookie" content="PHPSESSID=12345abcde">.

3. Exploitation

The victim clicks the link and logs into the application using their legitimate credentials. Because the application is vulnerable, it associates the victim's authenticated state with the existing session ID (12345abcde) instead of generating a new one.

Now, the attacker simply refreshes their own browser using the same ID and gains access to the victim's dashboard, profile, and sensitive data.

Technical Attack Vectors

Let's dive deeper into the technical methods used to fixate a session. These methods vary based on the application's configuration and the attacker's ability to manipulate the user's environment.

Session IDs in GET Parameters

This is the simplest form of session fixation. Some legacy or poorly configured applications allow the session ID to be passed via the query string. This is often done to support users who have disabled cookies.

An attacker crafts a URL like this:
http://vulnerable-bank.com/auth?SID=ATTACKER_DEFINED_ID

When the victim logs in, the server sees the SID in the URL and binds the authenticated session to it. The attacker, possessing ATTACKER_DEFINED_ID, now has the session.

Cookie Injection via Subdomains

Cookies can often be shared across subdomains. If an attacker controls a malicious subdomain (e.g., attacker.example.com) or finds a vulnerability on a different subdomain of the same parent (e.g., dev.example.com), they can set a cookie for the main domain.

document.cookie = "sessionid=fixed_value; domain=.example.com; path=/";

When the victim visits https://www.example.com, the browser sends the fixed_value session ID. If the main site does not regenerate the ID upon login, the attack succeeds.

Using XSS to Set Session Cookies

Cross-Site Scripting is a frequent partner to session fixation. If an attacker can execute JavaScript on any page of the target site, they can overwrite the current session cookie with one they control. Even if the cookie is marked as HttpOnly, an attacker might be able to use a "Cookie Overflow" attack to clear existing cookies and force the browser to accept new ones via a crafted response.

Real-World Impact of Session Fixation

The impact of a successful session fixation attack is identical to that of a full account takeover. Depending on the nature of the application, an attacker could:

1. Steal Personal Data: Access PII (Personally Identifiable Information), such as addresses, phone numbers, and social security numbers.
2. Financial Fraud: In banking or e-commerce apps, attackers can transfer funds, change payment methods, or make unauthorized purchases.
3. Data Manipulation: Change account passwords, email addresses, or security settings to permanently lock the user out.
4. Corporate Espionage: In a B2B or internal company tool, an attacker could access proprietary data, client lists, or strategic plans.

Because the attacker is using a legitimate session, their actions often blend in with normal user behavior, making the attack difficult to detect via standard logs unless the system specifically monitors for concurrent sessions from different IP addresses using the same ID.

How to Prevent Session Fixation

Preventing session fixation is straightforward if developers follow modern security best practices. The most effective defense is a combination of session regeneration and strict cookie management.

1. Regenerate Session IDs on Authentication

This is the most critical defense. Whenever a user's privilege level changes (e.g., logging in, upgrading to an admin role), the application must invalidate the old session ID and issue a brand new one.

In PHP, this is handled with a simple function call:

// After verifying credentials
session_start();
session_regenerate_id(true); // The 'true' flag deletes the old session file
$_SESSION['authenticated'] = true;

In a Node.js Express environment using express-session, you would do the following:

req.session.regenerate(function(err) {
  // will have a new session here
  req.session.user = user;
  req.session.save();
});

2. Disallow Session IDs in URLs

Never accept session identifiers via GET or POST parameters. Ensure that your application only looks for session IDs within HTTP cookies. In many web servers and languages, this can be enforced in the configuration (e.g., session.use_only_cookies = 1 in php.ini).

3. Implement Strict Cookie Security

Use the following attributes when setting session cookies to limit their exposure:

• HttpOnly: Prevents JavaScript from accessing the cookie, mitigating XSS-based fixation.
• Secure: Ensures the cookie is only sent over encrypted HTTPS connections.
• SameSite=Strict: Ensures the cookie is only sent in a first-party context, providing defense against CSRF and some fixation vectors.

Example of a secure cookie header:

Set-Cookie: sessionid=xyz123; HttpOnly; Secure; SameSite=Strict

4. Session Timeouts and Concurrency Limits

Implement absolute timeouts (e.g., the session expires after 8 hours regardless of activity) and idle timeouts (e.g., the session expires after 30 minutes of inactivity). Additionally, consider alerting users if their account is accessed from two different geographical locations or IP addresses simultaneously.

How to Test for Session Fixation

If you are a pentester or a developer testing your own app, you can manually verify if your application is vulnerable:

1. Open the application in an Incognito window and note the current session ID (using DevTools -> Application -> Cookies).
2. Navigate to the login page and enter your credentials.
3. Check the session ID again after logging in.
4. If the session ID is exactly the same as the one you had before logging in, the application is vulnerable to session fixation.

Conclusion

Session fixation is a subtle but dangerous vulnerability that stems from a fundamental misunderstanding of how session lifecycles should work. By allowing a pre-authentication session ID to persist into an authenticated state, developers inadvertently provide attackers with a skeleton key to user accounts. Fortunately, by enforcing session regeneration and utilizing secure cookie attributes, this entire class of attack can be effectively eliminated.

To proactively monitor your organization's external attack surface and catch exposures like misconfigured session cookies before attackers do, try Jsmon.