🤖 HackTricks / Cookie Jar Overflow

Cookie Jar Overflow

Cookie jar overflow abuses the fact that browsers cap how many cookies they keep for one site/jar. If you can run JavaScript in the victim origin (typically via XSS), you can keep creating cookies until older entries are evicted, then recreate the target cookie with attacker-controlled data.

The exact threshold is browser-dependent. The current spec only requires user agents to support at least 50 cookies per domain, while current Chromium builds use 180 cookies per eTLD+1 and 180 per partitioned jar. Therefore, do not hardcode 700 cookies and assume it will always work.

const attrs = "Path=/";
let prev = -1;

for (let i = 0; i < 400; i++) {
  document.cookie = `junk${i}=${"A".repeat(32)}; ${attrs}`;
  const visible = document.cookie ? document.cookie.split(/; */).length : 0;
  if (visible === prev) break;
  prev = visible;
}

document.cookie only shows non-HttpOnly cookies, so in practice it is common to go a bit above the visible plateau to force eviction of hidden cookies as well.

Overwriting HttpOnly Cookies

This technique can still be used to evict an HttpOnly cookie and then recreate it without HttpOnly, but only if you can match the original scope (name, Path, and host/Domain behavior):

const targetScope = "Path=/app; Secure";

for (let i = 0; i < 250; i++) {
  document.cookie = `junk${i}=${crypto.randomUUID()}; ${targetScope}`;
}

document.cookie = `session=attacker-controlled; ${targetScope}`;

If the original cookie was set for a different Path or with a wider Domain, you may only create a sibling cookie and the server will receive both. At that point, ordering rules and server parsing decide which one wins, so check cookie tossing as well.

Caution

This attack does not let JavaScript modify HttpOnly in place. The practical primitive is: evict first, then create a new non-HttpOnly cookie with the same scope.

Check the original lab in this post.

Reliability Notes

  • Eviction is not always "oldest cookie first". In Chromium the garbage collector is LRU-like and tends to preserve more valuable cookies longer, especially Secure and higher-priority cookies. A recently used session cookie is usually harder to evict than a stale low-priority one.
  • Profile the real cookie first. Before overflowing, capture the original Set-Cookie in Burp/DevTools and note Path, Domain, Priority, prefixes, and whether the cookie is Partitioned.
  • Prefer first-party execution. Modern browsers increasingly isolate or block third-party cookies. If the cookie is partitioned (Partitioned / CHIPS, or browser-enforced third-party partitioning), overflowing the jar of cdn.example while embedded in siteA.com will not evict the cookie that the same origin uses as a top-level site or while embedded in siteB.com.
  • New prefixed cookies reduce the impact. In browsers that enforce the newer __Http- and __Host-Http- prefixes, JavaScript cannot recreate those cookies with document.cookie. You may still evict them, but you cannot mint a same-named replacement client-side.

References