mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
69 lines
5.2 KiB
Markdown
69 lines
5.2 KiB
Markdown
# Cookie Tossing
|
|
|
|
{{#include ../../banners/hacktricks-training.md}}
|
|
|
|
### Beschreibung
|
|
|
|
Wenn ein Angreifer **eine Subdomain oder die Domain eines Unternehmens kontrollieren kann oder eine XSS in einer Subdomain findet**, wird er in der Lage sein, diesen Angriff durchzuführen.
|
|
|
|
Wie im Abschnitt über Cookies Hacking angegeben, wenn ein **Cookie auf eine Domain (unter Angabe) gesetzt wird, wird es in der Domain und den Subdomains verwendet.**
|
|
|
|
> [!CAUTION]
|
|
> Daher **wird ein Angreifer in der Lage sein, ein spezifisches Cookie für die Domain und Subdomains zu setzen, indem er etwas wie** `document.cookie="session=1234; Path=/app/login; domain=.example.com"` **macht.**
|
|
|
|
Dies kann gefährlich sein, da der Angreifer möglicherweise:
|
|
|
|
- **Das Cookie des Opfers auf das Konto des Angreifers fixieren**, sodass, wenn der Benutzer es nicht bemerkt, **er die Aktionen im Konto des Angreifers ausführt** und der Angreifer möglicherweise einige interessante Informationen erhält (überprüfen der Suchhistorie des Benutzers auf der Plattform, das Opfer könnte seine Kreditkarte im Konto hinterlegen...)
|
|
- Ein Beispiel dafür [kann hier gefunden werden](https://snyk.io/articles/hijacking-oauth-flows-via-cookie-tossing/), wo der Angreifer sein Cookie in spezifischen Abschnitten gesetzt hat, die ein Opfer verwenden wird, um **Zugriff auf seine Git-Repos zu autorisieren, aber vom Konto des Angreifers aus**, da er seine Cookies in den benötigten Endpunkten setzen wird.
|
|
- Wenn das **Cookie sich nach dem Login nicht ändert**, kann der Angreifer einfach **ein Cookie fixieren (Session-Fixierung)**, warten, bis das Opfer sich einloggt, und dann **dieses Cookie verwenden, um sich als das Opfer einzuloggen**.
|
|
- Manchmal, selbst wenn sich die Session-Cookies ändern, verwendet der Angreifer das vorherige und erhält auch das neue.
|
|
- Wenn das **Cookie einen bestimmten Anfangswert setzt** (wie in Flask, wo das **Cookie** den **CSRF-Token** der Session **setzen** kann und dieser Wert nach dem Login des Opfers beibehalten wird), kann der **Angreifer diesen bekannten Wert setzen und dann missbrauchen** (in diesem Szenario könnte der Angreifer dann den Benutzer dazu bringen, eine CSRF-Anfrage auszuführen, da er den CSRF-Token kennt).
|
|
- Genau wie das Setzen des Wertes könnte der Angreifer auch ein nicht authentifiziertes Cookie generieren, das vom Server erstellt wurde, den CSRF-Token daraus erhalten und ihn verwenden.
|
|
|
|
### Cookie-Reihenfolge
|
|
|
|
Wenn ein Browser zwei Cookies mit demselben Namen **teilweise den gleichen Geltungsbereich** (Domain, Subdomains und Pfad) betreffen, wird der **Browser beide Werte des Cookies senden**, wenn beide für die Anfrage gültig sind.
|
|
|
|
Je nachdem, wer **den spezifischeren Pfad hat** oder welches das **ältere ist**, wird der Browser **zuerst den Wert des Cookies setzen** und dann den Wert des anderen wie in: `Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;`
|
|
|
|
Die meisten **Websites verwenden nur den ersten Wert**. Wenn ein Angreifer also ein Cookie setzen möchte, ist es besser, es zu setzen, bevor ein anderes gesetzt wird, oder es mit einem spezifischeren Pfad zu setzen.
|
|
|
|
> [!WARNING]
|
|
> Darüber hinaus ist die Fähigkeit, **ein Cookie in einem spezifischeren Pfad zu setzen**, sehr interessant, da Sie den **Opfer dazu bringen können, mit seinem Cookie zu arbeiten, außer im spezifischen Pfad, wo das bösartige Cookie gesetzt wird, das vorher gesendet wird**.
|
|
|
|
### Schutzumgehung
|
|
|
|
Ein möglicher Schutz gegen diesen Angriff wäre, dass der **Webserver keine Anfragen mit zwei Cookies mit demselben Namen, aber zwei unterschiedlichen Werten akzeptiert**.
|
|
|
|
Um das Szenario zu umgehen, in dem der Angreifer ein Cookie setzt, nachdem das Opfer bereits das Cookie erhalten hat, könnte der Angreifer einen **Cookie-Overflow** verursachen und dann, sobald das **legitime Cookie gelöscht ist, das bösartige setzen**.
|
|
|
|
{{#ref}}
|
|
cookie-jar-overflow.md
|
|
{{#endref}}
|
|
|
|
Eine weitere nützliche **Umgehung** könnte sein, **den Namen des Cookies URL-zu kodieren**, da einige Schutzmaßnahmen nach 2 Cookies mit demselben Namen in einer Anfrage suchen und der Server dann die Namen der Cookies dekodiert.
|
|
|
|
### Cookie-Bombe
|
|
|
|
Ein Cookie Tossing-Angriff kann auch verwendet werden, um einen **Cookie Bomb**-Angriff durchzuführen:
|
|
|
|
{{#ref}}
|
|
cookie-bomb.md
|
|
{{#endref}}
|
|
|
|
### Verteidigungen
|
|
|
|
#### **Verwenden Sie das Präfix `__Host` im Cookie-Namen**
|
|
|
|
- Wenn ein Cookie-Name dieses Präfix hat, **wird es nur akzeptiert**, wenn es in einer Set-Cookie-Direktive als sicher markiert ist, von einem sicheren Ursprung gesendet wurde, kein Domain-Attribut enthält und das Path-Attribut auf / gesetzt ist.
|
|
- **Dies verhindert, dass Subdomains ein Cookie auf die Hauptdomain zwingen, da diese Cookies als "domain-locked" angesehen werden können.**
|
|
|
|
### Referenzen
|
|
|
|
- [**@blueminimal**](https://twitter.com/blueminimal)
|
|
- [**https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers**](https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers)
|
|
- [**https://github.blog/2013-04-09-yummy-cookies-across-domains/**](https://github.blog/2013-04-09-yummy-cookies-across-domains/)
|
|
- [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg)
|
|
|
|
{{#include ../../banners/hacktricks-training.md}}
|