# Cookie Tossing

> How to identify and exploit cookie tossing vulnerabilities in web applications. Use this skill whenever the user mentions cookie attacks, session manipulation, subdomain cookie control, session fixation, CSRF token manipulation, or wants to test for cookie-related vulnerabilities in web security assessments. Make sure to use this skill for any pentesting task involving cookies, session handling, or subdomain security.

- Skill: `abelrguezr/cookie-tossing` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add abelrguezr/cookie-tossing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/abelrguezr/cookie-tossing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: abelrguezr (https://skillmd.com/u/abelrguezr)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/abelrguezr/cookie-tossing

---


# 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:**
```javascript
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](https://twitter.com/blueminimal)
- [The Cookie Monster in Your Browsers](https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers)
- [Yummy Cookies Across Domains](https://github.blog/2013-04-09-yummy-cookies-across-domains/)
- [Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities](https://www.youtube.com/watch?v=F_wAzF4a7Xg)
- [Hijacking OAuth Flows via Cookie Tossing](https://snyk.io/articles/hijacking-oauth-flows-via-cookie-tossing/)