Cookie Tossing From Subdomains: Session Fixation's Cousin

Cookie Tossing From Subdomains: Session Fixation's Cousin

Cookie tossing is the art of planting a cookie that the browser will send to a more sensitive host. You do not steal the real session cookie. You arrange for the victim to carry one you chose—or two cookies with the same name so the app reads the wrong value.

The usual foothold is a subdomain you control: XSS, subdomain takeover, or a feature that sets cookies too broadly.

The parent-domain footgun

If app.example.com sets SessionId without pinning Domain, the default host-only cookie is relatively safe from sister subdomains. Trouble starts when someone sets Domain=.example.com. Then evil.example.com can write cookies that travel to app.example.com.

From your foothold, try:

Set-Cookie: session=ATTACKER_VALUE; Domain=.example.com; Path=/

Visit app.example.com and see whether the server accepts the tossed value, ignores it, or confuses it with a host-only cookie of the same name. Some stacks keep both; order depends on the browser. That ambiguity is exploitable when the app trusts the first session= it parses.

Shadow cookies also work: toss session with a path like /login so it overrides only on sensitive routes.

What you can actually achieve

Classic wins:

• Session fixation: victim authenticates into a session identifier you planted.
• CSRF token defeat: if the CSRF secret lives in a readable cookie you can overwrite.
• Preference injection: language, currency, or callback URL cookies that change security-sensitive behavior.
• Cache or CDN variation keys keyed on a tossed cookie.

Pair tossing with a real login form. Show that after the victim signs in, your pre-set session id becomes privileged—or that the app issues a new id (which weakens the finding; say so).

Browser differences matter. Chrome's handling of duplicate cookies has shifted over the years; test the browsers listed in scope. Document name, path, domain, and which value the server echoed.

Reporting without drama

You need a credible subdomain foothold in scope. "Theoretical if we had XSS on a sibling" is a maybe. Concrete takeover of old-staging.example.com plus a tossed admin session cookie is a report.

User-generated subdomains—username.product.com—are the gift that keeps giving when sessions are scoped to .product.com. If the product must share cookies across tenants, at least isolate session names per environment and reject unknown session ids instead of adopting them.

Recommend host-only cookies for session material, __Host- prefixed names where possible, strict Path, separate site names for untrusted user content, and rejecting unknown session identifiers instead of silently adopting them. On the ops side, inventory cookie Domain attributes the same way you inventory CORS origins.

One strong opinion: if your untrusted UGC lives on the same eTLD+1 as the login session, cookie tossing is not an edge case—it is an eventuality. Plan the cookie jar before the next takeover lands.

Also probe Secure, HttpOnly, and SameSite on both the real cookie and the tossed one. A tossed non-HttpOnly CSRF double-submit token can be enough even when the session cookie itself resists overwrite. Impact is narrower than full fixation, but it still breaks the CSRF model the app claims to use.