Cookies Hacking
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)
Cookies verfügen über mehrere Attribute, die ihr Verhalten im Browser des Benutzers steuern. Hier ist eine Übersicht über diese Attribute in einer passiveren Stimme:
Das Ablaufdatum eines Cookies wird durch das Expires-Attribut bestimmt. Im Gegensatz dazu definiert das Max-age-Attribut die Zeit in Sekunden, bis ein Cookie gelöscht wird. Bevorzuge Max-age, da es modernere Praktiken widerspiegelt.
Die Hosts, die ein Cookie empfangen sollen, werden durch das Domain-Attribut festgelegt. Standardmäßig ist dies auf den Host eingestellt, der das Cookie ausgegeben hat, ohne seine Subdomains einzuschließen. Wenn das Domain-Attribut jedoch ausdrücklich festgelegt wird, umfasst es auch Subdomains. Dies macht die Spezifikation des Domain-Attributs zu einer weniger restriktiven Option, die nützlich ist, wenn das Teilen von Cookies über Subdomains erforderlich ist. Zum Beispiel macht die Einstellung Domain=mozilla.org Cookies auf seinen Subdomains wie developer.mozilla.org zugänglich.
Ein spezifischer URL-Pfad, der in der angeforderten URL vorhanden sein muss, damit der Cookie-Header gesendet wird, wird durch das Path-Attribut angezeigt. Dieses Attribut betrachtet das /-Zeichen als Verzeichnistrenner, was auch Übereinstimmungen in Unterverzeichnissen ermöglicht.
Wenn zwei Cookies denselben Namen tragen, wird dasjenige, das zum Senden ausgewählt wird, basierend auf:
Dem Cookie, das den längsten Pfad in der angeforderten URL übereinstimmt.
Dem zuletzt gesetzten Cookie, wenn die Pfade identisch sind.
Das SameSite-Attribut bestimmt, ob Cookies bei Anfragen von Drittanbieter-Domains gesendet werden. Es bietet drei Einstellungen:
Strict: Beschränkt das Cookie, sodass es bei Anfragen von Drittanbietern nicht gesendet wird.
Lax: Erlaubt das Senden des Cookies mit GET-Anfragen, die von Drittanbieter-Websites initiiert werden.
None: Erlaubt das Senden des Cookies von jeder Drittanbieter-Domain.
Denke daran, dass das Verständnis dieser Attribute bei der Konfiguration von Cookies helfen kann, um sicherzustellen, dass sie in verschiedenen Szenarien wie erwartet funktionieren.
Anfragetyp
Beispielcode
Cookies werden gesendet, wenn
Link
<a href="..."></a>
NotSet*, Lax, None
Prerender
<link rel="prerender" href=".."/>
NotSet*, Lax, None
Form GET
<form method="GET" action="...">
NotSet*, Lax, None
Form 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 mildern, bei denen eine angemeldete Sitzung erforderlich ist.
*Beachte, dass ab Chrome80 (Februar 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/). Beachte, dass temporär, nach Anwendung dieser Änderung, die Cookies ohne eine SameSite Richtlinie in Chrome während der ersten 2 Minuten als None behandelt werden und dann als Lax für Top-Level-Cross-Site-POST-Anfragen.
Dies verhindert, dass der Client auf das Cookie zugreift (zum Beispiel über Javascript: document.cookie)
Wenn die Seite die Cookies als Antwort auf eine Anfrage sendet (zum Beispiel auf einer PHPinfo-Seite), ist es möglich, XSS auszunutzen, um eine Anfrage an diese Seite zu senden und die Cookies aus der Antwort zu stehlen (siehe ein Beispiel in 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 (wenn diese HTTP-Methode verfügbar ist) die gesendeten Cookies widerspiegelt. Diese Technik wird als Cross-Site Tracking bezeichnet.
Diese Technik wird von modernen Browsern vermieden, indem sie das Senden einer TRACE-Anfrage von JS nicht erlauben. Einige Umgehungen dafür wurden jedoch in spezifischer Software gefunden, wie das Senden von \r\nTRACE anstelle von TRACE an IE6.0 SP2.
Eine andere Möglichkeit ist die Ausnutzung von Zero-Day-Sicherheitsanfälligkeiten der Browser.
Es ist möglich, HttpOnly-Cookies durch einen Cookie-Jar-Overflow-Angriff zu überschreiben:
Es ist möglich, den Cookie Smuggling Angriff zu verwenden, um diese Cookies zu exfiltrieren.
Die Anfrage sendet das Cookie nur, wenn die Anfrage über einen sicheren Kanal (typischerweise HTTPS) übertragen wird.
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 durch HTTPS gesicherten Seite stammen.
Es ist verboten, eine Domain anzugeben, was ihre Übertragung an Subdomains verhindert.
Der Pfad für diese Cookies muss auf / gesetzt werden.
Es ist wichtig zu beachten, dass Cookies, die mit __Host- beginnen, nicht an Superdomains oder Subdomains gesendet werden dürfen. Diese Einschränkung hilft, Anwendungscookies zu isolieren. Daher kann die Verwendung des __Host--Präfixes für alle Anwendungscookies als gute Praxis zur Verbesserung der Sicherheit und Isolation angesehen werden.
Eine der Schutzmaßnahmen von __Host--präfixierten Cookies besteht darin, sie daran zu hindern, von Subdomains überschrieben zu werden. Dies verhindert beispielsweise Cookie Tossing-Angriffe. In dem Vortrag Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (Paper) wird präsentiert, dass es möglich war, __HOST- präfixierte Cookies von einer Subdomain zu setzen, indem man den Parser täuschte, zum Beispiel, indem man "=" am Anfang oder am Ende hinzufügte...:
Oder in PHP war es möglich, andere Zeichen am Anfang des Cookie-Namens hinzuzufügen, die durch Unterstriche ersetzt werden sollten, was es ermöglichte, __HOST- Cookies zu überschreiben:
Wenn ein benutzerdefiniertes Cookie sensible Daten enthält, überprüfe es (insbesondere wenn du an einem CTF teilnimmst), da es anfällig sein könnte.
Sensible Daten, die in Cookies eingebettet sind, sollten immer überprüft werden. Cookies, die in Base64 oder ähnlichen Formaten kodiert sind, können oft dekodiert werden. Diese Sicherheitsanfälligkeit ermöglicht es Angreifern, den Inhalt des Cookies zu ändern und sich als andere Benutzer auszugeben, indem sie ihre modifizierten Daten wieder in das Cookie kodieren.
Dieser Angriff besteht darin, das Cookie eines Benutzers zu stehlen, um unbefugten Zugriff auf dessen Konto innerhalb einer Anwendung zu erlangen. Durch die Verwendung des gestohlenen Cookies kann ein Angreifer den legitimen Benutzer imitieren.
In diesem Szenario bringt ein Angreifer ein Opfer dazu, ein bestimmtes Cookie zum Anmelden zu verwenden. Wenn die Anwendung beim Anmelden kein neues Cookie zuweist, kann der Angreifer, der das ursprüngliche Cookie besitzt, das Opfer imitieren. Diese Technik beruht darauf, dass das Opfer sich mit einem vom Angreifer bereitgestellten Cookie anmeldet.
Wenn du ein XSS in einer Subdomain gefunden hast oder eine Subdomain kontrollierst, lies:
Cookie TossingHier überzeugt der Angreifer das Opfer, das Sitzungscookie des Angreifers zu verwenden. Das Opfer, das glaubt, in seinem eigenen Konto angemeldet zu sein, wird unbeabsichtigt Aktionen im Kontext des Kontos des Angreifers ausführen.
Wenn du ein XSS in einer Subdomain gefunden hast oder eine Subdomain kontrollierst, lies:
Cookie TossingKlicke auf den vorherigen Link, um auf eine Seite zuzugreifen, die mögliche Schwächen in JWT erklärt.
JSON Web Tokens (JWT), die in Cookies verwendet werden, können ebenfalls Sicherheitsanfälligkeiten aufweisen. Für detaillierte Informationen zu potenziellen Schwächen und wie man sie ausnutzen kann, wird empfohlen, das verlinkte Dokument über das Hacken von JWT zu lesen.
Dieser Angriff zwingt einen angemeldeten Benutzer, unerwünschte Aktionen in einer Webanwendung auszuführen, in der er derzeit authentifiziert ist. Angreifer können Cookies ausnutzen, die automatisch mit jeder Anfrage an die anfällige Seite gesendet werden.
(Überprüfe weitere Details in der originalen Forschung) Browser erlauben die Erstellung von Cookies ohne Namen, was durch JavaScript wie folgt demonstriert werden kann:
Das Ergebnis im gesendeten Cookie-Header ist a=v1; test value; 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:
Dies führt dazu, dass der Browser einen Cookie-Header sendet, der von jedem Webserver als ein Cookie mit dem Namen a und dem Wert b interpretiert wird.
In Chrome, wenn ein Unicode-Surrogat-Codepunkt Teil eines gesetzten Cookies ist, wird document.cookie beschädigt und gibt anschließend einen leeren String zurück:
Dies führt dazu, dass document.cookie einen leeren String ausgibt, was auf eine permanente Beschädigung hinweist.
(Weitere Details finden Sie in der originalen Forschung) Mehrere Webserver, einschließlich der von Java (Jetty, TomCat, Undertow) und Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), behandeln Cookie-Strings aufgrund veralteter RFC2965-Unterstützung falsch. Sie lesen einen doppelt zitierten Cookie-Wert als einen einzelnen Wert, selbst wenn er Semikolons enthält, die normalerweise Schlüssel-Wert-Paare trennen sollten:
(Check further details in theoriginal research) Die falsche 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-Injektionsangriffe. Diese Server versäumen es, den Beginn neuer Cookies ordnungsgemäß zu kennzeichnen, was es Angreifern ermöglicht, Cookies zu fälschen:
Undertow erwartet ein neues Cookie sofort nach einem zitierten Wert ohne Semikolon.
Zope sucht nach einem Komma, um mit der Analyse des nächsten Cookies zu beginnen.
Python's Cookie-Klassen beginnen die Analyse bei einem Leerzeichen.
Diese Schwachstelle ist besonders gefährlich in Webanwendungen, die auf cookie-basiertem CSRF-Schutz basieren, da sie es Angreifern ermöglicht, gefälschte CSRF-Token-Cookies einzuschleusen, was potenziell Sicherheitsmaßnahmen umgeht. Das Problem wird durch die Handhabung von doppelten Cookie-Namen in Python verschärft, bei der das letzte Vorkommen 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 Backend-Server weitergegeben werden, die anfällig für Spoofing sind.
Laut diesem Blogbeitrag könnte es möglich sein, das Cookie-Attribut $Version=1 zu verwenden, um das Backend dazu zu bringen, eine alte Logik zur Analyse des Cookies aufgrund der RFC2109 zu verwenden. Darüber hinaus können andere Werte wie $Domain und $Path verwendet werden, um das Verhalten des Backends mit dem Cookie zu ändern.
Diese Analyse deutet darauf hin, dass escaped Werte innerhalb der Cookies unescaped werden, sodass "\a" zu "a" wird. Dies kann nützlich sein, um WAFS zu umgehen, da:
eval('test') => forbidden
"\e\v\a\l\(\'\t\e\s\t\'\)" => allowed
In der RFC2109 wird angegeben, dass ein Komma als Trennzeichen zwischen Cookie-Werten verwendet werden kann. Außerdem ist es möglich, Leerzeichen und Tabs vor und nach dem Gleichheitszeichen hinzuzufügen. Daher erzeugt ein Cookie wie $Version=1; foo=bar, abc = qux nicht das Cookie "foo":"bar, admin = qux", sondern die Cookies foo":"bar" und "admin":"qux". Beachten Sie, wie 2 Cookies generiert werden und wie der Admin den Raum vor und nach dem Gleichheitszeichen entfernt hat.
Schließlich würden verschiedene Backdoors in einem String verschiedene Cookies zusammenführen, die in verschiedenen Cookie-Headern übergeben werden, wie in:
Was es ermöglichen könnte, eine WAF zu umgehen, wie in diesem Beispiel:
Das Cookie ist jedes Mal, wenn Sie sich einloggen, gleich.
Melden Sie sich ab und versuchen Sie, dasselbe Cookie zu verwenden.
Versuchen Sie, sich mit 2 Geräten (oder Browsern) mit demselben Cookie in dasselbe Konto einzuloggen.
Überprüfen Sie, ob das Cookie Informationen enthält, und versuchen Sie, es zu ändern.
Versuchen Sie, mehrere Konten mit fast demselben Benutzernamen zu erstellen, und überprüfen Sie, ob Sie Ähnlichkeiten sehen können.
Überprüfen Sie die Option "angemeldet bleiben", falls vorhanden, um zu sehen, wie sie funktioniert. Wenn sie vorhanden ist und anfällig sein könnte, verwenden Sie immer das Cookie von angemeldet bleiben ohne ein anderes Cookie.
Überprüfen Sie, ob das vorherige Cookie funktioniert, selbst nachdem Sie das Passwort geändert haben.
Wenn das Cookie beim Einloggen gleich bleibt (oder fast gleich bleibt), bedeutet dies wahrscheinlich, dass das Cookie mit einem Feld Ihres Kontos (wahrscheinlich dem Benutzernamen) verbunden ist. Dann können Sie:
Versuchen, viele Konten mit sehr ähnlichen Benutzernamen zu erstellen und versuchen, zu erraten, wie der Algorithmus funktioniert.
Versuchen, den Benutzernamen zu bruteforcen. Wenn das 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 versuchen werden, das von "admin" sein wird.
Versuchen Sie Padding Oracle (Sie können den Inhalt des Cookies entschlüsseln). Verwenden Sie padbuster.
Padding Oracle - Padbuster Beispiele
Padbuster wird mehrere Versuche unternehmen und Sie fragen, welche Bedingung die Fehlerbedingung ist (die, die nicht gültig ist).
Dann beginnt es mit der Entschlüsselung des Cookies (es kann mehrere Minuten dauern).
Wenn der Angriff erfolgreich durchgeführt wurde, können Sie versuchen, eine Zeichenfolge Ihrer Wahl zu verschlüsseln. Zum Beispiel, wenn Sie encrypt user=administrator verschlüsseln möchten.
Diese Ausführung gibt Ihnen das Cookie korrekt verschlüsselt und kodiert mit dem String user=administrator darin.
CBC-MAC
Vielleicht könnte ein Cookie einen Wert haben und mit CBC signiert werden. Dann ist die Integrität des Wertes die Signatur, die durch die Verwendung von CBC mit demselben Wert erstellt wird. Da empfohlen wird, als IV einen Nullvektor zu verwenden, könnte diese Art der Integritätsprüfung anfällig sein.
Der Angriff
Holen Sie sich die Signatur des Benutzernamens administ = t
Holen Sie sich die Signatur des Benutzernamens rator\x00\x00\x00 XOR t = t'
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 gegebenen Cookie zu entdecken.
Erstellen Sie einen Benutzer mit dem Namen "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" und überprüfen Sie, ob es ein Muster im Cookie gibt (da ECB mit demselben Schlüssel jeden Block verschlüsselt, könnten die gleichen verschlüsselten Bytes erscheinen, wenn der Benutzername verschlüsselt wird).
Es sollte ein Muster geben (mit der Größe eines verwendeten Blocks). 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".
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
