Exploiting Session Fixation via Stored XSS and Cookie Jar Overflow Attack

As a Pentester, I know that sometimes finding a vulnerability isn’t enough you also need to demonstrate the real impact to get it taken seriously. During Bug hunt, I came across a session fixation vulnerability in a PHP web application. But I knew that if I reported session fixation on its own, it might just be marked as “informative” with no further action.

To make sure the issue was recognized as a real threat, I decided to chain it with an XSS vulnerability I had already reported, along with a Cookie Jar Overflow Attack — a lesser-known but powerful technique. By combining these three attack vectors, I was able to demonstrate how an attacker could bypass traditional security measures and hijack user sessions.

This approach allowed me to show the full impact of the session fixation vulnerability, moving it from a potential “low-risk” issue to a high-severity exploit that required immediate attention.

Session fixation exploits the way web applications manage user sessions. In PHP, when users interact with an application, they are assigned a session ID that is stored in the PHPSESSID cookie. This cookie identifies the session across requests and persists during the user’s activity.

An attacker can exploit this mechanism by setting the victim’s session ID before they log into the application. The attacker then waits for the user to log in using the pre-set session ID. Once authenticated, the attacker can hijack the session, as they already know the session ID the victim is using.

Here’s how it typically works:

Once the attacker has control over this session, they can perform unauthorized actions, access sensitive data, or even impersonate the user.

At first glance, one might think Cross-Site Scripting (XSS) could allow attackers to easily steal session cookies. However, modern security practices set the HttpOnly flag on cookies, which prevents JavaScript from accessing or modifying them. While this defends against many common attacks, it doesn’t entirely solve the problem when session fixation is combined with a more obscure technique: the Cookie Jar Overflow Attack.

The Cookie Jar Overflow Attack takes advantage of the limited cookie storage capacity that browsers enforce, particularly in Chrome. Browsers can only store a set number of cookies per domain. This attack works by flooding the browser’s cookie storage, forcing the eviction (deletion) of older cookies to make room for new ones.

The goal of this attack is to evict critical cookies such as the PHPSESSID, which holds the session ID for a user and replace them with an attacker-controlled session ID. Once the legitimate session cookie is gone, the user is effectively logged out of their valid session, and the attacker’s session ID takes its place, giving the attacker full control of the user’s session.

This attack becomes even more potent when combined with XSS (Cross-Site Scripting). With XSS, an attacker can run malicious JavaScript code in the victim’s browser, automating the overflow of cookies. The JavaScript rapidly creates new cookies until the browser’s cookie jar is full, forcing the eviction of legitimate cookies like PHPSESSID and replacing them with a predefined, malicious session ID.

One of the most concerning aspects of this attack is that, even in modern versions of Chrome — regardless of the underlying OS — you can overwrite cookies that have the HttpOnly flag set. This means that even cookies meant to be protected from JavaScript access can be evicted and replaced through the overflow, rendering the HttpOnly flag ineffective in this scenario.

Executing the Cookie Jar Overflow Attack

I crafted a malicious payload that combined XSS with the Cookie Jar Overflow Attack. Here’s the payload I used:

<img src="x" onerror="for(let i=999;i--;)document.cookie=`c${i}=${i};Secure`;document.cookie='PHPSESSID=x';">Step 1: The broken image (src="x") triggered the onerror event, which executed the JavaScript.Step 2: The script rapidly created 999 cookies with names like c0, c1, c2… all the way to c998. Each cookie was marked as Secure and filled the browser’s cookie jar.Step 3: Once the cookie jar was full, the legitimate PHPSESSID cookie was evicted from the browser’s storage due to the overflow.Step 4: The script then injected my own session ID (PHPSESSID=x), replacing the legitimate session ID with one controlled by me.

Once the legitimate session cookie was evicted and replaced with my attacker-controlled session ID, the victim was essentially logged out.

When they logged in again, they authenticated using my session ID.

This meant that I could now access their session and take control of their account without needing their password or credentials. Additionally, I generated the private API key using my injected session cookie, as shown below.

By chaining vulnerabilities and showcasing the real-world impact, I was able to demonstrate the full potential of the session fixation vulnerability, ensuring it received the attention it deserved.

A few days after my report, the developers patched both the XSS and session fixation vulnerabilities. I was awarded $800 for my findings!