cookie-tossing.md (5437B)
1 --- 2 title: "Cookie Tossing" 3 section: "Web Pentesting" 4 sectionSlug: "pentesting-web" 5 sourcePath: "src/pentesting-web/hacking-with-cookies/cookie-tossing.md" 6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/pentesting-web/hacking-with-cookies/cookie-tossing.md" 7 sha: "188de82beb54e70956b2952367a0af91d26758b8" 8 isIndex: false 9 modified: true 10 license: "CC-BY-NC-4.0" 11 --- 12 13 # Cookie Tossing 14 15 ## Description 16 17 If an attacker controls a subdomain (or finds an XSS in one), they may be able to set a cookie whose `Domain` attribute covers the parent domain. A host may only set a Domain cookie for itself or a parent domain, never for an unrelated domain.<sup>[[1]](#references)</sup> 18 19 The original attack notes on this page credit security researcher **@blueminimal**.<sup>[[7]](#references)</sup> 20 21 A cookie with a `Domain` attribute is sent to that domain and its subdomains; omitting `Domain` creates a host-only cookie.<sup>[[1]](#references)</sup> 22 23 > [!CAUTION] 24 > Therefore, **an attacker is going to be able to set to the domain and subdomains a specific cookie doing something like** `document.cookie="session=1234; Path=/app/login; domain=.example.com"` 25 26 This can be dangerous because the attacker may be able to:<sup>[[2]](#references)</sup> 27 28 A conference presentation demonstrates additional session-integrity variants and is useful as a visual walkthrough of the attack family.<sup>[[6]](#references)</sup> 29 30 - **Fix the victim's cookie to the attacker's account.** If the victim does not notice, they may perform searches, add payment details, or enter other information into the attacker's account, where the attacker can retrieve it. 31 - In one documented OAuth example, a malicious cookie scoped to selected authorization endpoints caused the victim to authorize access under the attacker's session.<sup>[[3]](#references)</sup> 32 - If the **cookie does not change after login**, the attacker may **fixate a session cookie**, wait until the victim logs in, and then reuse that cookie as the victim. 33 - In some flawed renewal flows, presenting the pre-login cookie can also disclose or recover the renewed session. 34 - If the cookie initializes state that survives login (for example, a CSRF token), the attacker may set a known value and later forge a request using that known token. 35 - Just like setting the value, the attacker could also get an unauthenticated cookie generated by the server, get the CSRF token from it and use it. 36 37 ## Cookie Order 38 39 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. 40 41 RFC 6265 orders matching cookies by descending path length and then by ascending creation time, although servers should not rely on this serialization order. A request can therefore contain `Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;`.<sup>[[1]](#references)</sup> 42 43 Many server frameworks select one of the duplicate values. An attacker therefore tries to make the malicious cookie the value selected by the target stack, commonly by setting it earlier or with a more specific path.<sup>[[4]](#references)</sup> 44 45 > [!WARNING] 46 > Moreover, the capability to **set a cookie in a more specific path** is very interesting as you will be able to make the **victim work with his cookie except in the specific path where the malicious cookie set will be sent before**. 47 48 ## Protection Bypass 49 50 A possible protection is for the server to reject requests containing two cookies with the same name but different values.<sup>[[2]](#references)</sup> 51 52 To bypass the scenario where the attacker is setting a cookie after the victim was already given the cookie, the attacker could cause a **cookie overflow** and then, once the **legit cookie is deleted, set the malicious one**. 53 54 55 [Cookie Jar Overflow](/hacktricks/pentesting-web/hacking-with-cookies/cookie-jar-overflow) 56 57 Another useful **bypass** is to **URL-encode the cookie name** when a front-end protection compares raw names but the back end decodes them.<sup>[[2]](#references)</sup> 58 59 ## Cookie Bomb 60 61 A Cookie Tossing attack may also be used to perform a **Cookie Bomb** attack: 62 63 64 [Cookie Bomb](/hacktricks/pentesting-web/hacking-with-cookies/cookie-bomb) 65 66 ## Defenses 67 68 ### Use the `__Host-` cookie-name prefix 69 70 - A supporting user agent accepts a `__Host-` cookie only when it is set from a secure origin with `Secure`, has `Path=/`, and omits `Domain`. 71 - This makes the cookie host-only and prevents a subdomain from creating that cookie for the parent domain.<sup>[[5]](#references)</sup> 72 73 ## References 74 75 - [1] [RFC 6265 - HTTP State Management Mechanism](https://www.rfc-editor.org/rfc/rfc6265) 76 - [2] [Yummy cookies across domains](https://github.blog/2013-04-09-yummy-cookies-across-domains/) 77 - [3] [Hijacking OAuth flows via cookie tossing](https://snyk.io/articles/hijacking-oauth-flows-via-cookie-tossing/) 78 - [4] [The Cookie Monster in Your Browsers](https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers) 79 - [5] [MDN - Secure cookie configuration](https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides/Cookies) 80 - [6] [Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities](https://www.youtube.com/watch?v=F_wAzF4a7Xg) 81 - [7] [@blueminimal](https://twitter.com/blueminimal)