Cookie Tossing
Beschreibung
Wenn ein Angreifer eine Subdomain oder die Domain eines Unternehmens kontrollieren kann oder ein XSS in einer Subdomain findet, kann er diesen Angriff durchführen.
Wie im Abschnitt Cookies Hacking angegeben, wenn ein Cookie auf eine Domain gesetzt wird (diese spezifiziert), wird es in der Domain und den Subdomains verwendet.
Daher kann ein Angreifer ein spezifisches Cookie für die Domain und Subdomains setzen, indem er etwas wie document.cookie="session=1234; Path=/app/login; domain=.example.com" tut.
Dies kann gefährlich sein, da der Angreifer möglicherweise:
Das Cookie des Opfers auf das Konto des Angreifers fixieren kann, 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 Sie die Suchhistorie des Benutzers auf der Plattform, das Opfer könnte seine Kreditkarte im Konto hinterlegt haben...)
Wenn das Cookie nach dem Login nicht geändert wird, 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, auch wenn sich die Sitzungscookies ändern, kann der Angreifer das vorherige verwenden und erhält auch das neue.
Wenn das Cookie einen anfänglichen Wert setzt (wie in Flask, wo das Cookie den CSRF-Token der Sitzung setzen kann und dieser Wert nach dem Einloggen des Opfers beibehalten wird), kann der Angreifer diesen bekannten Wert setzen und dann missbrauchen (in diesem Szenario kann der Angreifer dann den Benutzer dazu bringen, eine CSRF-Anfrage auszuführen, da er den CSRF-Token kennt).
Genau wie das Setzen des Werts könnte der Angreifer auch ein nicht authentifiziertes Cookie generieren, den CSRF-Token daraus erhalten und ihn verwenden.
Cookie-Reihenfolge
Wenn ein Browser zwei Cookies mit demselben Namen erhält, die teilweise denselben Bereich betreffen (Domain, Subdomains und Pfad), wird der Browser beide Cookie-Werte senden, wenn beide für die Anfrage gültig sind.
Abhängig davon, wer den spezifischeren Pfad hat oder welcher der ältere ist, wird der Browser zuerst den Wert des Cookies setzen und dann den Wert des anderen wie in: Cookie: iduser=SpezifischerUndÄltesterCookie; iduser=WenigerSpezifisch;
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.
Darüber hinaus ist die Fähigkeit, ein Cookie in einem spezifischeren Pfad zu setzen, sehr interessant, da Sie den Benutzer mit seinem Cookie arbeiten lassen können, außer im spezifischen Pfad, wo das bösartige Cookie gesetzt wird, bevor es 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 verschiedenen Werten akzeptiert.
Um das Szenario zu umgehen, in dem der Angreifer ein Cookie setzt, nachdem dem Opfer bereits das Cookie gegeben wurde, könnte der Angreifer einen Cookie-Überlauf verursachen und dann, sobald das legitime Cookie gelöscht ist, das bösartige setzen.
pageCookie Jar OverflowEine weitere nützliche Umgehung könnte sein, den Namen des Cookies URL-codiert zu verwenden, da einige Schutzmechanismen nach 2 Cookies mit demselben Namen in einer Anfrage suchen und dann der Server die Namen der Cookies decodiert.
Cookie-Bombe
Ein Cookie-Tossing-Angriff kann auch verwendet werden, um einen Cookie-Bomben-Angriff durchzuführen:
pageCookie BombVerteidigungen
Verwenden Sie das Präfix __Host im Cookienamen
__Host im CookienamenWenn ein Cookiename dieses Präfix hat, wird es nur akzeptiert, wenn es in einer Set-Cookie-Anweisung als Secure markiert ist, von einem sicheren Ursprung gesendet wurde, keinen Domain-Attribut enthält und das Pfadattribut auf / gesetzt ist.
Dies verhindert, dass Subdomains ein Cookie auf die Hauptdomain erzwingen, da diese Cookies als "domain-gesperrt" angesehen werden können
Referenzen
Last updated