Cookie Tossing: Escalating Low-Impact XSS into Criticals

Last updated: 2 Sep 2026

Ai generated thumbnail

Recently I came across a Nahamcon talk about Cookie Tossing (Cookie Counterfeiting) and it really changed my perspective on the severity and impact of XSS vulnerabilities

what would have been considered a low impact/OOS vulnerability (e.g finding an XSS on an out of scope subdomain or a Self XSS) could Become A critical issue with this Attack .

In this article I’ll be walking you through what cookie tossing is, how can we exploit it , how cookies and browsers work together and more .

NB: this article’s knowledge is not my own . However its a rewrite and rephrase of many resources I combined together all in one in my own style and understanding

Definition of Cookie Tossing

Cookie Tossing is a technique/Attack that allows one subdomain (e.g. sub.example.com) to set cookies on its parent domain (e.g. example.com)

Pre-requesites for this Attack to work

An attacker will be able to perform this attack

• If he can control a subdomain (many services provide subdommains when siging )

WordPress.com  <your‑name>.wordpress.co
GitHub Pages   <username>.github.io
Vercel         <project‑name>.vercel.app
...

(or a subdomain takeover)

• If he control the main domain of the company .
• If he finds an XSS in a subdomain .

Therefore, the attacker is going to be able to set to the domain and subdomains a specific cookie doing something like document.cookie=“session=Attacker_session; Path=/app/updateCardDetails; domain=.example.com”

The victim will then browse the app using their own session(Victim_session) and the Attacker_session goes unnoticed, unless accessing /app/updateCardDetailsPath then if the victim saves their payment details effectively binding his credit card details to the attacker session instead of theirs .

But How Does this Work ?

How Do Cookies and Browsers Work?

As we all know through cookies, user sessions can persist, preferences can be saved, and personalized experiences can be delivered.

Cookies come with various attributes and flags that define their behavior and scope. Here’s a primer on the key cookie attributes and flags:

https://labs.snyk.io/resources/hijacking-oauth-flows-via-cookie-tossing/

In our case the two crucial attributes for this attack are

• The Domain which Specifies the domain the cookie is valid for, allowing subdomains to access it. (e.g Domain=.example.com)
• The Path : Limits the cookie to a specific path within the domain.

A browser identifies a cookie with this combo

Name_of_the_cookie(e.g session)   +   Domain   +   Path

Cookie Order

When a browser receives two cookies with the same name partially affecting the same scope (domain, subdomains and path), the browser will send both values of the cookie when both are valid for the request.

Depending on who has the most specific path or which one is the oldest one, the browser will set the value of the cookie first and then the value of the other one like in: Cookie: session=/Very/Specific/Sensitive/Path; session=/LessSpecificPath;

Most websites will only use the first value. Then, if an attacker wants to set a cookie it’s better to set it before another one is set or set it with a more specific path.

https://book.hacktricks.wiki/en/pentesting-web/hacking-with-cookies/cookie-tossing.html

In short The Longest path wins

Cookie Domains

The Domain attribute of a cookie specifies which domains can access the cookie. By default, a cookie is only accessible to the domain that set it. However, you can use the Domain attribute to extend a cookie’s accessibility. For instance, if a cookie is set by blog.example.com with the Domain=.example.com attribute, it will be accessible to all subdomains of example.com, such as app.example.com and example.com itself. Conversely, while the parent domain (example.com) can set a cookie to be accessible by all its subdomains using Domain=.example.com, it cannot explicitly set a cookie for a specific subdomain like blog.example.com. This approach allows for enhanced flexibility in multi-subdomain applications while maintaining control over which domains can share cookie data.

in short .Domain=.example.com cookies are accessible by all subdomains and main domain

Setting the Victim’s Cookies

now lets discuss how an attacker can set the victim cookies

1- Through a custom response if the subdomain allows it with Set-Cookie header : Cookie Tossing By Design

HTTP/1.1 200 OK
Set-Cookie: session=Attacker_session; Domain=.example.com; Path=/Very/Specific/Sensitive/Path;  Secure; HttpOnly; SameSite=Lax

2- Through an XSS : Finding a vulnerability

document.cookie = "session=Attacker_session; Domain=.example.com; Path=/Very/Specific/Sensitive/Path;  Secure; HttpOnly; SameSite=Lax";

Goal : Session tainting

the user then navigates the main app like nothing happened ,as the attacker session does not take effect yet ,but as soon as the victim navigates to the tainted endpoint the browser will send the attacker session instead

Exploiting Cookie Tossing: Attack Patterns

1. Secret Skimming

secret skimming is using cookie tossing to attack any endpoint where a victims submits sensitive data whether its payment details ,file uploads ,PIIs ,Internal messages …

Tom Anthony report of this Attack patern

Example : An attacker taints the endpoint /payment-method/submit ,when the victim updates their payment details ,the attacker session id is sent which allows associating the victim payment account details with the attacker’s effectively allowing the attacker to abuse the credit card to buy stuff with someone else’s money .

2. Privilege Hijacking

same drill , we taint a sensitive path this time a High Privileged **Endpoint ,**then the victim initiates the high privilege action allowing the attacker to effectively skipping privilege checks and easily obtaining high privileged rights

Tom Anthony report of this Attack patern

Example(context : video meeting app) : An attacker taints the endpoint /start-meeting/123 ,once the victim intiates a meeting ,the attacker now can join the meeting (as it is tied to their session) effectively applying the victim privileges to his account .

3. Identifier Rebinding

Identifier Rebinding is attacking any endpoint where there is some sort of identifier token that are associated with a specific account (Suplly endpoints), for example Deposit Addresses ,Download links …

Tom Anthony report of this Attack patern

Example(context : cryptocurrency money deposit) : An attacker taints the endpoint /api/deposit/adresses ,once the victim initiates a deposit ,the attacker session is sent in the api request effectively making the victim deposit money in the attacker’s wallet .

These are only examples of how to exploit Cookie Tossing — there is no limit. The important thing is to look for endpoints with impact affecting the CIA triad.

When Does Cookie Tossing Work?

as you might have noticed throughout the article to this point , the talk evolves solely around cookies , so for this type of attack to work , api request must be solely based on auth cookies , and it Fails as soon as there is an authorization header being utilized for identifying users . another requirement is path that are not being reused to make many different api request (graphql query based apps the only use one path /graphql for example ) . Furthermore, if a website doesnt allow duplicate cookie names this attack will not be effective .Lastly we need to find a trigger Bug

In short : For this Attack to work we need a tainting endpoint

- where auth is cookie based

- where the path is not being reused (e.g /graphql)

- where the website doesn’t block requests with duplicate cookie names

- finding a trigger Bug :

— XSS on a subdomain (OOS subdomains sound like a perfect target)

— Cookie/header reflection

— HTTP response splitting

— Subdomain takeover or an issued one

— Self-XSS ! ( forcing the victim to log into the attacker account and then tainting their session which stays that way : session-fixation )

https://www.youtube.com/watch?v=xLPYWim60jA

A Question I Had While Reading About This Topic

Doesn’t csrf tokens have any role in protecting against this ?

1- SameSite attribute

• for the SameSite attribute (even if set to Strict) relies on the definition of a “Site” (like example.com), not the “Origin” (scheme + host + port). thus subdomain.example.com and example.com are considered the same site, the browser will happily send the tainted cookies. unlike CORS (which enforces strict Same-Origin Policy)

2- Session being tied to the csrf token

• to bypass a cryptographically tied token, we taint both our CSRF token and Session ID (performing a Session Fixation attack via cookie tossing). By overwriting both, the server validates the tossed CSRF token against the tossed Session ID, and the attack succeeds.

Mitigation Techniques

The __Host cookie prefix can be used to restrict cookies from being sent to any host other than the one that set the cookie. Additionally, the cookies with the __Host prefix cannot modify the domain or path attributes, which prevents a malicious subdomain from being able to set cookies on the parent domain or target a specific path.

Final Words

Hope you enjoyed reading about this attack as much as i did writing and learning about it , note that the only ai generated part of this article is the thumbnail image , so if any writing errors bother you point them out and i’ll fix them ! Hopefully you learned something new . Cya !!!

Real-World Case Studies

https://labs.snyk.io/resources/hijacking-oauth-flows-via-cookie-tossing/

Resources

please note that all the resources I used to write this article are embedded throughout it ,including images too .