The “Cookie Sandwich Attack” showcases a sophisticated way of exploiting inconsistencies in cookie parsing by web servers.
This technique allows attackers to manipulate HTTP cookie headers to expose sensitive session cookies, including those marked with the HttpOnly flag, making it possible to access restricted data through client-side scripts.
By combining legacy cookie standards, special characters, and browser behavior, this attack represents a critical threat to poorly configured web applications.
Investigate Real-World Malicious Links & Phishing Attacks With Threat Intelligence Lookup - Try for Free
Exploiting Parsing Ambiguities in Cookies
The attack leverages differences in how web servers, frameworks, and browsers handle cookies based on legacy standards such as RFC2109, in contrast to the modern RFC6265 standard.
For example, browsers like Chrome allow JavaScript to create cookies with names prefixed by a $
(e.g., $Version
) even though such cookies are not directly supported.
Attackers can define quoted cookie values that create a “sandwich” around sensitive cookies, leading to misinterpretation by the server.
A sample manipulation looks like this:
document.cookie = `$Version=1;`;
document.cookie = `param1="start`;
document.cookie = `param2=end";`;
This results in the following HTTP request header:
GET / HTTP/1.1
Cookie: $Version=1; param1="start; sessionId=secret; param2=end"
When processed by servers like Apache Tomcat, which falls back to legacy parsing logic upon detection, $Version, the entire string, including the sensitive, sessionId
can be assigned toparam
1.
If this cookie value is reflected in a response without the HttpOnly flag, attackers can extract it using client-side scripts.
Python frameworks, such as Flask, are inherently vulnerable to such attacks due to their support for quoted cookie strings and automatic encoding of special characters.
This enables attackers to bypass traditional cookie parsing safeguards without requiring the $Version
attribute.
Combining XSS and Cookie Manipulation
An attack on a vulnerable web application using an analytics tracking domain demonstrated the theft of an HttpOnly PHPSESSID
cookie in four stages.
First, attackers exploited a Cross-Site Scripting (XSS) vulnerability by injecting JavaScript via unsanitized attributes, bypassing AWS WAF using an oncontentvisibilityautostatechange
event.
Next, they identified that a tracking domain exposed session details in cross-origin JSON responses.
The attackers then manipulated cookie headers, using the $Version
attribute and modifying the path to insert a PHPSESSID
value in a JSON response, which the Apache Tomcat server reflected back.
Finally, JavaScript was used to automate cookie exfiltration via a CORS request.
According to the Port Swigger, to prevent such attacks, web servers must strictly adhere to RFC6265, disable legacy standards like RFC2109, and ensure proper sanitization and security for cross-origin requests.
Always set the HttpOnly and Secure flags for sensitive cookies such as session cookies to prevent JavaScript access or transmission over insecure connections.
Sanitize user inputs and outputs rigorously, particularly for reflected values in HTTP responses or HTML attributes. Prevent the injection of arbitrary scripts or content.
Restrict cross-origin requests to trusted origins and avoid reflecting sensitive data in responses.
Integrating Application Security into Your CI/CD Workflows Using Jenkins & Jira -> Free Webinar