Session Fixation Exploitation

Hello! In our last lesson, we focused on identifying weaknesses in how session tokens are generated. We saw how predictable or low-entropy tokens can be a major flaw. Now, we'll take that concept a step further to exploit a common, related vulnerability.

Today's lesson addresses the learning outcome: Exploit session fixation vulnerabilities to hijack authenticated user sessions. This attack doesn't rely on guessing or stealing a user's active session token. Instead, it tricks the user into authenticating into a session that you, the attacker, already control. It's a subtle but powerful way to achieve account takeover.

We will cover:

1. The core concept and attack flow of session fixation.
2. A practical method for detecting this vulnerability using Burp Suite.
3. An advanced technique for exploiting it by chaining it with other vulnerabilities.

Let's get started.

1. The Concept of Session Fixation

In the previous lesson, we established that when you visit a web application, it often assigns you a session token (like a PHPSESSID cookie) even before you log in. A session fixation vulnerability occurs when the application fails to generate a new, different session token for you after you successfully authenticate. The application simply "promotes" your pre-login session to a post-login, authenticated session.

This creates a dangerous window of opportunity for an attacker.

The core idea is: if an attacker can determine a valid session ID before the victim logs in, and can then force the victim's browser to use that same ID, the attacker simply has to wait for the victim to log in. Once they do, that session ID becomes authenticated, and the attacker can use it to access the victim's account.

To see a clear explanation of this, let's watch a short segment from a video on session hijacking.

As the video explained, the attacker's main challenge is getting the victim to use the attacker-controlled session ID. This can be done in several ways:

• Through a link: http://vulnerable-site.com/login?PHPSESSID=attacker-controlled-id
• Via a man-in-the-middle attack: Intercepting traffic and injecting the Set-Cookie header.
• Through Cross-Site Scripting (XSS): Using JavaScript to set the cookie in the victim's browser (we'll explore this advanced method later).

The fundamental vulnerability, however, is always the same: the application trusts a pre-existing session identifier after a user authenticates. The proper defense is to always destroy the old session and generate a completely new one upon login.

2. Detecting Session Fixation with Burp Suite

Now for the practical part: how do you find this vulnerability? The test is straightforward and relies on the principles we've just discussed. You need to compare the session token before login with the token after login.

The "Burp Suite Cookbook" provides a clear, step-by-step recipe for this test.

To summarize the process outlined in the reading:

1. Capture the Unauthenticated Session:

   • Navigate to the target application's login page in your browser (proxied through Burp).
   • In Burp's Proxy > HTTP history tab, find the request for the login page.
   • In the response, locate the Set-Cookie header and note the value of the session token (e.g., PHPSESSID).
   • Send this request to Comparer.

2. Capture the Authenticated Session:

   • Log in to the application.
   • In the HTTP history, find the request immediately following the successful login (often a GET request to the user's dashboard).
   • Note the value of the session token in this new request's Cookie header.
   • Send this request to Comparer.

3. Compare:

   • In the Comparer tab, select the two requests you sent.
   • Use the "Words" comparison feature.
   • Examine the Cookie header in both requests. If the session ID value is identical, you have confirmed a session fixation vulnerability.

This simple comparison is a critical check in any web application assessment.

3. Advanced Exploitation: Chaining with XSS and Cookie Jar Overflow

Finding a session fixation flaw is a great start. But for a bug bounty report, demonstrating a realistic and high-impact exploit path is key. What if you can't just send the victim a link? And what if the session cookie is protected by the HttpOnly flag, preventing JavaScript from directly modifying it?

This is where you can chain vulnerabilities. The following article describes a brilliant and creative exploit chain that combines Stored XSS with a lesser-known technique called a "Cookie Jar Overflow" to achieve session fixation. Given your background in CS and JS, you'll appreciate the ingenuity here.

Let's break down the attack payload from the article. It's a Stored XSS payload that triggers on a broken image:

<img src="x" onerror="for(let i=999;i--;)document.cookie=c${i}=${i};Secure;document.cookie='PHPSESSID=x';">

Here's how this clever exploit works:

1. Trigger: A Stored XSS vulnerability allows the attacker to save this HTML on a page that the victim will visit. The browser fails to load the image (src="x"), triggering the onerror event which contains the malicious JavaScript.
2. Cookie Jar Overflow: The for loop runs 999 times, rapidly creating 999 simple cookies (c0=0, c1=1, etc.). Browsers have a limit on how many cookies they can store for a single domain (e.g., around 150-180 in Chrome). This flood of new cookies "overflows" the cookie jar.
3. Eviction: To make room for the new cookies, the browser starts deleting old ones. Critically, this eviction process often removes the legitimate PHPSESSID cookie, even if it has the HttpOnly flag set. The HttpOnly flag only prevents direct access by scripts, not eviction due to storage limits.
4. Fixation: After the legitimate cookie is gone, the final part of the script runs: document.cookie='PHPSESSID=x';. The attacker's session ID (x in this example, but would be a real attacker-controlled ID) is now set in the victim's browser.

When the victim next tries to perform an action that requires authentication, they will be prompted to log in. They do so, and their new authenticated session is now tied to the attacker's PHPSESSID, completing the hijack.

Conclusion

Today you learned how to identify and exploit session fixation, a critical vulnerability in how applications manage user state. This moves beyond simply finding a weak token to understanding and manipulating the entire session lifecycle.

Key Takeaways:

• The Flaw: Session fixation occurs when an application fails to generate a new session ID after a user authenticates.
• The Test: Detection is simple: compare the session token from before and after login. If they are the same, the application is vulnerable. Burp Comparer is your friend here.
• The Exploit: An attacker must force a victim to use a pre-determined session ID. This can range from simple social engineering with a crafted link to advanced chains involving XSS and techniques like Cookie Jar Overflow to bypass HttpOnly protections.
• The Fix: The remediation is for the application to always invalidate the current session and generate a new, cryptographically random session ID immediately upon any change in privilege level, especially login.

Next Lesson Preview:
We will continue exploring flaws in authentication and identity management. In the next lesson, we will shift our focus to another critical workflow: password resets. You will learn how to test password reset workflows for logic flaws, such as token leakage or parameter tampering, to achieve account takeover.