Cookie Tossing Attack Guide

A comprehensive guide for identifying and exploiting cookie tossing vulnerabilities in web applications.

What is Cookie Tossing?

Cookie tossing is an attack where an attacker who controls a subdomain or has XSS access can set cookies that affect the parent domain and all subdomains. This works because when a cookie is set with a domain attribute, it's automatically sent to that domain and all its subdomains.

Attack Prerequisites

You can perform cookie tossing if you:

• Control a subdomain of the target domain
• Have XSS access on a subdomain
• Can set cookies with the target domain attribute

Attack Vectors

1. Account Fixation

Goal: Force the victim to perform actions in the attacker's account.

How it works:

• Attacker sets their session cookie on the victim's browser
• Victim unknowingly performs actions in attacker's account
• Attacker can harvest sensitive information (search history, credit cards, etc.)

Example:

document.cookie="session=ATTACKER_SESSION_ID; Path=/app/login; domain=.example.com"

Real-world case: OAuth flow hijacking where attacker sets their cookie on authorization endpoints, causing victim to authorize attacker's account instead of their own.

2. Session Fixation

Goal: Steal the victim's authenticated session.

How it works:

• Attacker sets a known session cookie value
• Victim logs in with that cookie value
• Attacker uses the same cookie to authenticate as the victim

Variation: Even if the session cookie changes after login, the attacker may receive the new cookie value if the application doesn't properly regenerate sessions.

3. CSRF Token Manipulation

Goal: Bypass CSRF protections by controlling the token value.

How it works:

• Some frameworks (like Flask) store CSRF tokens in cookies
• Attacker sets a known cookie value before victim logs in
• After login, the known CSRF token persists
• Attacker can craft CSRF requests with the known token

Alternative: Get an unauthenticated cookie from the server, extract the CSRF token, and use it for attacks.

Cookie Order Mechanics

How Browsers Handle Multiple Cookies

When a browser receives two cookies with the same name affecting the same scope:

• Both values are sent in the Cookie header
• Order depends on path specificity and age
• Format:

  Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;

Key insight: Most websites only use the first value.

Exploitation Strategy

To ensure your malicious cookie is used:

1. Set it before the legitimate cookie is set, OR
2. Use a more specific path than the legitimate cookie

Advanced technique: Set a malicious cookie on a specific path where it will be sent first, while the victim's legitimate cookie works on other paths. This allows you to target specific endpoints.

Protection Bypass Techniques

1. Cookie Overflow

Scenario: Server rejects requests with duplicate cookie names.

Bypass:

1. Cause a cookie overflow to delete the legitimate cookie
2. Set your malicious cookie once the legitimate one is gone

2. URL Encoding

Scenario: Server checks for duplicate cookie names before decoding.

Bypass: URL encode the cookie name so it appears different to the check, but decodes to the same name the server uses.

Example:

%69%64%75%73%65%72

decodes to

iduser

3. Cookie Bomb

Use cookie tossing to perform a cookie bomb attack (see cookie-bomb.md for details).

Detection Checklist

When assessing a target for cookie tossing vulnerabilities:

• Can you control a subdomain of the target?
• Is there XSS on any subdomain?
• Do cookies use the

  domain

  attribute?
• Does the application accept cookies from subdomains?
• Are session cookies regenerated after login?
• Is the CSRF token stored in a cookie?
• Does the server reject duplicate cookie names?
• What path specificity do cookies use?

Defenses

Use

__Host

Prefix

The

__Host

prefix provides strong protection:

Requirements for

__Host

cookies:

• Must be marked

  Secure

• Must be sent from a secure origin (HTTPS)
• Cannot include a

  Domain

  attribute
• Must have

  Path

  set to

  /

Effect: These cookies are "domain-locked" and cannot be set by subdomains, preventing cookie tossing attacks.

Additional Defenses

• Regenerate session cookies after authentication
• Don't store CSRF tokens in cookies
• Validate cookie values server-side
• Reject requests with duplicate cookie names
• Use

  SameSite

  attribute on cookies
• Implement proper subdomain isolation

Practical Testing Steps

1. Reconnaissance:

   • Identify all subdomains of the target
   • Check for XSS vulnerabilities on subdomains
   • Map cookie attributes (domain, path, secure, httponly)

2. Exploitation:

   • Attempt to set cookies from controlled subdomains
   • Test session fixation by setting known cookie values
   • Try to manipulate CSRF tokens via cookies
   • Test cookie order by setting cookies with different paths

3. Verification:

   • Check if your cookies are sent to the main domain
   • Verify if the application uses your cookie values
   • Test if you can perform actions with the victim's session

References

• @blueminimal
• The Cookie Monster in Your Browsers
• Yummy Cookies Across Domains
• Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities
• Hijacking OAuth Flows via Cookie Tossing