| name | cookie-tossing |
| description | 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. |
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:
- Set it before the legitimate cookie is set, OR
- 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:
- Cause a cookie overflow to delete the legitimate cookie
- 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:
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
-
Reconnaissance:
- Identify all subdomains of the target
- Check for XSS vulnerabilities on subdomains
- Map cookie attributes (domain, path, secure, httponly)
-
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
-
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
