German - Ht
HackTricks Training Twitter Linkedin Sponsor

Cookies Hacking

Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Try Hard Security Group

LogoJoin the Try Hard Security Discord Server!Discord

Cookie Attribute

Cookies werden mit mehreren Attributen geliefert, die ihr Verhalten im Browser des Benutzers steuern. Hier ist eine Übersicht über diese Attribute in einer eher passiven Stimme:

Ablaufdatum und Max-Age

Das Ablaufdatum eines Cookies wird durch das Attribut Ablaufdatum bestimmt. Umgekehrt definiert das Attribut Max-Age die Zeit in Sekunden, bis ein Cookie gelöscht wird. Wählen Sie Max-Age, da es modernere Praktiken widerspiegelt.

Domäne

Die Hosts, die ein Cookie erhalten sollen, werden durch das Attribut Domäne angegeben. Standardmäßig ist dies auf den Host festgelegt, der das Cookie ausgestellt hat, ohne seine Subdomänen einzubeziehen. Wenn jedoch das Attribut Domäne explizit festgelegt ist, umfasst es auch Subdomänen. Dies macht die Spezifikation des Attributs Domäne zu einer weniger restriktiven Option, die in Szenarien nützlich ist, in denen ein Cookie-Austausch über Subdomänen erforderlich ist. Wenn beispielsweise Domäne=mozilla.org festgelegt ist, sind Cookies auf seinen Subdomänen wie developer.mozilla.org zugänglich.

Pfad

Ein spezifischer URL-Pfad, der in der angeforderten URL vorhanden sein muss, damit der Cookie-Header gesendet wird, wird durch das Attribut Pfad angezeigt. Dieses Attribut betrachtet das /-Zeichen als Verzeichnistrennzeichen und ermöglicht Übereinstimmungen in Unterverzeichnissen.

Bestellregeln

Wenn zwei Cookies denselben Namen haben, wird das zum Senden ausgewählte Cookie basierend auf folgendem ausgewählt:

  • Das Cookie, das am längsten zum Pfad in der angeforderten URL passt.

  • Das zuletzt gesetzte Cookie, wenn die Pfade identisch sind.

SameSite

  • Das Attribut SameSite bestimmt, ob Cookies bei Anfragen von Drittanbieterdomänen gesendet werden. Es bietet drei Einstellungen:

  • Strict: Beschränkt das Senden des Cookies bei Anfragen von Drittanbieter-Websites.

  • Lax: Ermöglicht das Senden des Cookies bei GET-Anfragen, die von Drittanbieter-Websites initiiert wurden.

  • None: Erlaubt das Senden des Cookies von jeder Drittanbieterdomäne.

Beachten Sie, dass beim Konfigurieren von Cookies das Verständnis dieser Attribute dazu beitragen kann, sicherzustellen, dass sie sich in verschiedenen Szenarien wie erwartet verhalten.

Anforderungstyp

Beispielcode

Gesendete Cookies bei

Link

<a href="..."></a>

NotSet*, Lax, None

Prerender

<link rel="prerender" href=".."/>

NotSet*, Lax, None

Formular GET

<form method="GET" action="...">

NotSet*, Lax, None

Formular POST

<form method="POST" action="...">

NotSet*, None

iframe

<iframe src="..."></iframe>

NotSet*, None

AJAX

$.get("...")

NotSet*, None

Bild

<img src="...">

NetSet*, None

Tabelle von Invicti und leicht modifiziert. Ein Cookie mit SameSite Attribut wird CSRF-Angriffe abmildern, bei denen eine angemeldete Sitzung erforderlich ist.

*Beachten Sie, dass ab Chrome80 (Feb/2019) das Standardverhalten eines Cookies ohne ein Cookie-Samesite-Attribut lax sein wird (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/). Beachten Sie vorübergehend, nach Anwendung dieser Änderung werden die Cookies ohne eine SameSite-Richtlinie in Chrome während der ersten 2 Minuten als None behandelt und dann als Lax für Cross-Site-POST-Anfragen auf höchster Ebene.

Cookies-Flags

HttpOnly

Dies verhindert, dass der Client auf das Cookie zugreift (zum Beispiel über Javascript: document.cookie)

Umgehungen

  • Wenn die Seite die Cookies als Antwort auf eine Anfrage sendet (zum Beispiel auf einer PHPinfo-Seite), ist es möglich, XSS zu missbrauchen, um eine Anfrage an diese Seite zu senden und die Cookies aus der Antwort zu stehlen (überprüfen Sie ein Beispiel unter https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/.

  • Dies könnte mit TRACE HTTP-Anfragen umgangen werden, da die Antwort des Servers (falls diese HTTP-Methode verfügbar ist) die gesendeten Cookies widerspiegelt. Diese Technik wird als Cross-Site-Tracking bezeichnet.

  • Moderne Browser verhindern diese Technik, indem sie das Senden einer TRACE-Anfrage von JS nicht zulassen. Es wurden jedoch einige Umgehungen für spezifische Software gefunden, wie z.B. das Senden von \r\nTRACE anstelle von TRACE an IE6.0 SP2.

  • Ein anderer Weg ist die Ausnutzung von Zero-Day-Schwachstellen der Browser.

  • Es ist möglich, HttpOnly-Cookies zu überschreiben, indem ein Cookie-Jar-Überlaufangriff durchgeführt wird:

pageCookie Jar Overflow

  • Es ist möglich, einen Cookie-Smuggling-Angriff zu verwenden, um diese Cookies zu exfiltrieren

Secure

Die Anfrage sendet das Cookie nur, wenn die Anfrage über einen sicheren Kanal übertragen wird (typischerweise HTTPS).

Cookies-Präfixe

Cookies, die mit __Secure- beginnen, müssen zusammen mit dem secure-Flag von Seiten gesetzt werden, die durch HTTPS gesichert sind.

Für Cookies, die mit __Host- beginnen, müssen mehrere Bedingungen erfüllt sein:

  • Sie müssen mit dem secure-Flag gesetzt werden.

  • Sie müssen von einer Seite stammen, die durch HTTPS gesichert ist.

  • Es ist verboten, eine Domäne anzugeben, um deren Übertragung an Subdomänen zu verhindern.

  • Der Pfad für diese Cookies muss auf / festgelegt sein.

Es ist wichtig zu beachten, dass Cookies, die mit __Host- beginnen, nicht an Superdomänen oder Subdomänen gesendet werden dürfen. Diese Einschränkung trägt dazu bei, Anwendungscookies zu isolieren. Daher kann die Verwendung des Präfix __Host- für alle Anwendungscookies als bewährte Praxis zur Verbesserung von Sicherheit und Isolierung betrachtet werden.

Überschreiben von Cookies

Eine der Schutzmaßnahmen für mit __Host- vorangestellten Cookies besteht darin, zu verhindern, dass sie von Subdomains überschrieben werden. Dies verhindert beispielsweise Cookie-Tossing-Angriffe. In dem Vortrag Cookie Crumbles: Enthüllung von Schwachstellen bei der Web-Sitzungsintegrität (Paper) wurde dargestellt, dass es möglich war, __HOST- vorangestellte Cookies von Subdomains aus zu setzen, indem man den Parser austrickste, zum Beispiel indem man "=" am Anfang oder am Anfang und am Ende hinzufügte...:

Oder in PHP war es möglich, andere Zeichen am Anfang des Cookie-Namens hinzuzufügen, die durch Unterstrichzeichen ersetzt werden sollten, was es ermöglichte, __HOST- Cookies zu überschreiben:

Cookies-Angriffe

Wenn ein benutzerdefinierter Cookie sensible Daten enthält, überprüfen Sie ihn (insbesondere wenn Sie an einem CTF teilnehmen), da er anfällig sein könnte.

Dekodieren und Manipulieren von Cookies

In Cookies eingebettete sensible Daten sollten immer überprüft werden. Cookies, die in Base64 oder ähnlichen Formaten codiert sind, können oft dekodiert werden. Diese Schwachstelle ermöglicht es Angreifern, den Inhalt des Cookies zu ändern und sich als andere Benutzer auszugeben, indem sie ihre modifizierten Daten zurück in das Cookie codieren.

Sitzungsübernahme

Bei diesem Angriff wird ein Benutzercookie gestohlen, um unbefugten Zugriff auf sein Konto innerhalb einer Anwendung zu erlangen. Indem der gestohlene Cookie verwendet wird, kann ein Angreifer den legitimen Benutzer imitieren.

Sitzungsfestlegung

In diesem Szenario täuscht ein Angreifer ein Opfer, ein bestimmtes Cookie zum Einloggen zu verwenden. Wenn die Anwendung beim Einloggen kein neues Cookie vergibt, kann der Angreifer, der das ursprüngliche Cookie besitzt, das Opfer imitieren. Diese Technik basiert darauf, dass das Opfer sich mit einem vom Angreifer bereitgestellten Cookie einloggt.

Wenn Sie ein XSS in einer Subdomain gefunden haben oder Sie eine Subdomain kontrollieren, lesen Sie:

pageCookie Tossing

Sitzungsspende

Hier überzeugt der Angreifer das Opfer, das Sitzungscookie des Angreifers zu verwenden. Das Opfer, das glaubt, in sein eigenes Konto eingeloggt zu sein, wird unbeabsichtigt Aktionen im Kontext des Kontos des Angreifers ausführen.

Wenn Sie ein XSS in einer Subdomain gefunden haben oder Sie eine Subdomain kontrollieren, lesen Sie:

pageCookie Tossing

JWT-Cookies

Klicken Sie auf den vorherigen Link, um auf eine Seite zuzugreifen, die mögliche Schwachstellen bei JWT erklärt.

JSON Web Tokens (JWT), die in Cookies verwendet werden, können ebenfalls Schwachstellen aufweisen. Für detaillierte Informationen zu potenziellen Schwachstellen und wie sie ausgenutzt werden können, wird empfohlen, das verlinkte Dokument zum Hacken von JWT zu lesen.

Cross-Site Request Forgery (CSRF)

Dieser Angriff zwingt einen eingeloggten Benutzer, unerwünschte Aktionen auf einer Webanwendung auszuführen, für die er derzeit authentifiziert ist. Angreifer können Cookies ausnutzen, die automatisch bei jeder Anfrage an die verwundbare Website gesendet werden.

Leere Cookies

(Weitere Details finden Sie in der Originalforschung) Browser erlauben die Erstellung von Cookies ohne Namen, was durch JavaScript wie folgt demonstriert werden kann:

document.cookie = "a=v1"
document.cookie = "=test value;" // Setting an empty named cookie
document.cookie = "b=v2"

Der Wert im gesendeten Cookie-Header lautet a=v1; Testwert; b=v2;. Interessanterweise ermöglicht dies die Manipulation von Cookies, wenn ein Cookie mit leerem Namen gesetzt wird, wodurch möglicherweise andere Cookies kontrolliert werden können, indem das leere Cookie auf einen bestimmten Wert gesetzt wird:

function setCookie(name, value) {
document.cookie = `${name}=${value}`;
}

setCookie("", "a=b"); // Setting the empty cookie modifies another cookie's value

Chrome-Bug: Unicode-Ersatzcodepunkt-Problem

In Chrome wird, wenn ein Unicode-Ersatzcodepunkt Teil eines gesetzten Cookies ist, document.cookie beschädigt, und gibt anschließend einen leeren String zurück:

document.cookie = "\ud800=meep";

Dies führt dazu, dass document.cookie eine leere Zeichenfolge ausgibt, was auf eine dauerhafte Beschädigung hinweist.

Cookie-Schmuggel aufgrund von Analyseproblemen

(Überprüfen Sie weitere Details in der Originalforschung) Mehrere Webserver, darunter solche von Java (Jetty, TomCat, Undertow) und Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), behandeln Cookie-Zeichenfolgen aufgrund veralteter RFC2965-Unterstützung falsch. Sie lesen einen in Anführungszeichen gesetzten Cookie-Wert als einzelnen Wert, auch wenn er Semikolons enthält, die normalerweise Schlüssel-Wert-Paare trennen sollten:

RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";

Cookie-Injection-Schwachstellen

(Überprüfen Sie weitere Details in der ursprünglichen Forschung) Die inkorrekte Analyse von Cookies durch Server, insbesondere Undertow, Zope und solche, die Python's http.cookie.SimpleCookie und http.cookie.BaseCookie verwenden, schafft Möglichkeiten für Cookie-Injection-Angriffe. Diese Server versäumen es, den Beginn neuer Cookies ordnungsgemäß zu begrenzen, was es Angreifern ermöglicht, Cookies zu fälschen:

  • Undertow erwartet ein neues Cookie unmittelbar nach einem in Anführungszeichen gesetzten Wert ohne Semikolon.

  • Zope sucht nach einem Komma, um mit der Analyse des nächsten Cookies zu beginnen.

  • Die Cookie-Klassen von Python beginnen mit der Analyse bei einem Leerzeichen.

Diese Schwachstelle ist besonders gefährlich in Webanwendungen, die auf cookiebasierten CSRF-Schutz angewiesen sind, da sie es Angreifern ermöglicht, gefälschte CSRF-Token-Cookies einzufügen und möglicherweise Sicherheitsmaßnahmen zu umgehen. Das Problem wird durch die Behandlung von doppelten Cookienamen in Python verschärft, wo das letzte Auftreten frühere überschreibt. Es wirft auch Bedenken hinsichtlich __Secure- und __Host--Cookies in unsicheren Kontexten auf und könnte zu Autorisierungsumgehungen führen, wenn Cookies an anfällige Backend-Server weitergeleitet werden, die anfällig für Fälschungen sind.

Zusätzliche Überprüfungen für gefährdete Cookies

Grundlegende Überprüfungen

  • Der Cookie ist jedes Mal gleich, wenn Sie sich anmelden.

  • Melden Sie sich ab und versuchen Sie denselben Cookie zu verwenden.

  • Versuchen Sie, sich mit 2 Geräten (oder Browsern) beim selben Konto mit demselben Cookie anzumelden.

  • Überprüfen Sie, ob der Cookie Informationen enthält und versuchen Sie, ihn zu ändern.

  • Versuchen Sie, mehrere Konten mit fast demselben Benutzernamen zu erstellen und prüfen Sie, ob Sie Ähnlichkeiten feststellen können.

  • Überprüfen Sie die Option "Angemeldet bleiben", falls vorhanden, um zu sehen, wie sie funktioniert. Wenn sie vorhanden ist und gefährdet sein könnte, verwenden Sie immer nur den Cookie von Angemeldet bleiben ohne andere Cookies.

  • Überprüfen Sie, ob der vorherige Cookie auch nach einer Passwortänderung funktioniert.

Fortgeschrittene Cookie-Angriffe

Wenn der Cookie beim Einloggen gleich bleibt (oder fast gleich), bedeutet dies wahrscheinlich, dass der Cookie mit einem Feld Ihres Kontos zusammenhängt (wahrscheinlich dem Benutzernamen). Dann können Sie:

  • Versuchen Sie, viele Konten mit sehr ähnlichen Benutzernamen zu erstellen und versuchen Sie zu erraten, wie der Algorithmus funktioniert.

  • Versuchen Sie, den Benutzernamen bruteforce. Wenn der Cookie nur als Authentifizierungsmethode für Ihren Benutzernamen gespeichert wird, können Sie ein Konto mit dem Benutzernamen "Bmin" erstellen und jeden einzelnen Bit Ihres Cookies bruteforcen, da eines der Cookies, die Sie ausprobieren werden, dem von "admin" gehört.

  • Versuchen Sie Padding Oracle (Sie können den Inhalt des Cookies entschlüsseln). Verwenden Sie padbuster.

Padding Oracle - Padbuster-Beispiele

padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
# When cookies and regular Base64
padbuster http://web.com/index.php u7bvLewln6PJPSAbMb5pFfnCHSEd6olf 8 -cookies auth=u7bvLewln6PJPSAbMb5pFfnCHSEd6olf

# If Base64 urlsafe or hex-lowercase or hex-uppercase --encoding parameter is needed, for example:
padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2

Padbuster wird mehrere Versuche unternehmen und Sie nach der Fehlerbedingung fragen (die ungültige).

Dann wird es beginnen, das Cookie zu entschlüsseln (es kann mehrere Minuten dauern).

Wenn der Angriff erfolgreich war, könnten Sie versuchen, einen String Ihrer Wahl zu verschlüsseln. Zum Beispiel, wenn Sie user=administrator verschlüsseln möchten.

padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator

Diese Ausführung gibt Ihnen das Cookie korrekt verschlüsselt und codiert mit dem String user=administrator darin.

CBC-MAC

Möglicherweise könnte ein Cookie einen Wert haben und mit CBC signiert werden. Dann ist die Integrität des Werts die Signatur, die durch Verwendung von CBC mit dem gleichen Wert erstellt wurde. Da empfohlen wird, als IV einen Nullvektor zu verwenden, könnte diese Art der Integritätsprüfung anfällig sein.

Der Angriff

  1. Erhalten Sie die Signatur des Benutzernamens administ = t

  2. Erhalten Sie die Signatur des Benutzernamens rator\x00\x00\x00 XOR t = t'

  3. Setzen Sie im Cookie den Wert administrator+t' (t' wird eine gültige Signatur von (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00 sein

ECB

Wenn das Cookie mit ECB verschlüsselt ist, könnte es anfällig sein. Wenn Sie sich anmelden, muss das Cookie, das Sie erhalten, immer dasselbe sein.

Wie man erkennt und angreift:

Erstellen Sie 2 Benutzer mit fast denselben Daten (Benutzername, Passwort, E-Mail usw.) und versuchen Sie, ein Muster im erhaltenen Cookie zu entdecken

Erstellen Sie einen Benutzer mit dem Namen "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" und prüfen Sie, ob im Cookie ein Muster vorhanden ist (da ECB mit dem gleichen Schlüssel jeden Block verschlüsselt, könnten dieselben verschlüsselten Bytes erscheinen, wenn der Benutzername verschlüsselt ist).

Es sollte ein Muster geben (mit der Größe eines verwendeten Blocks). Daher, wenn Sie wissen, wie eine Menge von "a" verschlüsselt ist, können Sie einen Benutzernamen erstellen: "a"*(Größe des Blocks)+"admin". Dann könnten Sie das verschlüsselte Muster eines Blocks von "a" aus dem Cookie löschen. Und Sie haben das Cookie des Benutzernamens "admin".

Referenzen

Try Hard Security Group

LogoJoin the Try Hard Security Discord Server!Discord
Lernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

PreviousCSP bypass: self + 'unsafe-inline' with IframesNextCookie Tossing

Last updated