Cookie Tossing
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Wenn ein Angreifer eine Subdomain oder die Domain eines Unternehmens kontrollieren kann oder ein 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 gesetzt wird (indem es spezifiziert wird), wird es in der Domain und den Subdomains verwendet.
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 in der Lage sein könnte:
Das Cookie des Opfers auf das Konto des Angreifers zu 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...)
Wenn das Cookie sich nach dem Login nicht ändert, könnte 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), könnte 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.
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.
Darüber hinaus ist die Fähigkeit, ein Cookie in einem spezifischeren Pfad zu setzen, sehr interessant, da du in der Lage sein wirst, den Benutzer mit seinem Cookie arbeiten zu lassen, außer im spezifischen Pfad, wo das bösartige Cookie zuvor gesetzt wurde.
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.
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.
Ein Cookie Tossing-Angriff kann auch verwendet werden, um einen Cookie Bomb-Angriff durchzuführen:
__Host im Cookie-NamenWenn 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.
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
