
Researching on the vulnrability CVE-2023-26136
Recherche zur Schwachstelle CVE-2023-26136
Versionen des Pakets tough-cookie vor 4.1.3 sind anfällig für Prototype Pollution aufgrund unsachgemäßer Handhabung von Cookies bei Verwendung von CookieJar im Modus rejectPublicSuffixes=false. Dieses Problem ergibt sich aus der Art und Weise, wie die Objekte initialisiert werden.
https://nvd.nist.gov/vuln/detail/CVE-2023-26136
JavaScript hat das Konzept von Objekten, die so etwas wie Wörterbücher sind. Ein Objekt kann eine Reihe von Variablen verschiedener Typen (z. B. string, Boolean, int usw.) enthalten, der Variablenname ist ein Schlüssel und sein Wert ist der Wert, wenn wir mit der Analogie von Wörterbüchern und Objekten fortfahren. Genauer gesagt ist das Objekt analog zur Datenstruktur des Wörterbuchs selbst, und jede Variable ist analog zu einem Schlüssel-Wert-Paar. Objekte haben auch das Schlüsselwort proto, das es ermöglicht, einem Objekt durch Änderung seines Prototyps zusätzliche Variablen hinzuzufügen. Prototype Pollution ist ein Angriff, bei dem der Angreifer sein Objekt durch Hinzufügen zusätzlicher Variablen über das proto-Schlüsselwort verunreinigt. Die folgende Interaktion mit der Browserkonsole zeigt den Angriff.
Wie wir sehen können, haben wir zwei Benutzer: admin1 und user1. Das Objekt admin1 hat eine Boolean-Variable: "isAdmin", die auf true gesetzt ist. User1 hat diese Variable überhaupt nicht. In Zeile 7 fügen wir die Variable isAdmin zum Prototyp von user1 hinzu, und obwohl aus Zeile 10 ersichtlich ist, dass die Variable nicht zum Objekt user1 selbst hinzugefügt wurde, antwortet die Konsole dieses Mal positiv, wenn wir den Wert von user1.isAdmin überprüfen. Das liegt daran, dass user1 die Eigenschaften seines Prototyps erbt.
Es ist auch erwähnenswert, dass der Prototyp selbst ein Objekt ist, das wiederum Eigenschaften und Methoden von seinem Prototyp erbt, wodurch eine Prototypenkette entsteht. Die Kette endet mit einem null-Prototyp, daher ist ein vernünftiger Ansatz, um Prototype Pollution zu verhindern, das Objekt, mit dem wir arbeiten, explizit von einem null-Prototyp erben zu lassen.
Cookies (oft als Internet-Cookies bekannt) sind Textdateien mit kleinen Datenstücken – wie einem Benutzernamen und Passwort – die verwendet werden, um Ihren Computer bei der Nutzung eines Netzwerks zu identifizieren. Bestimmte Cookies werden verwendet, um bestimmte Benutzer zu identifizieren und ihr Surferlebnis zu verbessern. Mit freundlicher Genehmigung von Kaspersky: https://www.kaspersky.com/resource-center/definitions/cookies
CookieJar ist ein Objekt zum Speichern von Cookies.
Laut Beschreibung der Schwachstelle ergibt sie sich aus der Art und Weise, wie Tough-Cookie Cookies initialisiert. Da Cookies Objekte sind, sind sie theoretisch zumindest anfällig für Prototype Pollution.
Durch die Möglichkeit, Objekte und insbesondere Cookies über den Objektprototyp zu manipulieren, kann der Angreifer potenziell auf unbefugte Daten zugreifen, Remote-Code ausführen, einen Denial-of-Service verursachen, die Sitzung übernehmen, wenn die Website Cookies zur Sitzungsverwaltung verwendet, und vertrauliche Daten aus den Cookies selbst extrahieren.
Der Patch wurde in der Datei memstore.js vorgenommen. Laut dem Issue-Tracking sowie dem Patch, der in Version 4.1.3 eingeführt wurde, müssen wir zum Patchen der Schwachstelle die Cookies in einer Map speichern oder das this.idx-Objekt erstellen. Indem wir this.idx mit: this.idx = Object.create(null); statt this.idx = {} erstellen, wenden wir meinen Vorschlag aus der Einführung an, um Prototype Pollution zu verhindern, indem wir von einem null-Prototyp erben und die Prototypkette unterbrechen.
Snyk hat einen Proof of Concept (PoC) für die besprochene Schwachstelle veröffentlicht. Ich habe index.js darauf aufgebaut. Habe es in eine try-catch-Logik eingebettet, um Ausnahmen abzufangen, falls sie auftreten, zusätzliche Ausgaben hinzugefügt, um den Fortschritt der Tests zu verfolgen, und bin mit der erforderlichen Ausgabe (z. B. "EXPLOITED SUCCESSFULLY" oder "EXPLOITED FAILED") gelandet. Bei Ausführung des Befehls: npm install [email protected] && node index.js erhalten wir die folgende Ausgabe:
Bei Ausführung des Befehls: npm install ./tough-cookie-2.5.0-PATCHED.tgz && node index.js erhalten wir die folgende Ausgabe:
In beiden Szenarien (Ausführen mit der veröffentlichten Version 2.5.0 und Ausführen mit meiner gepatchten Version) konnten wir sowohl das normale Cookie als auch das ausgenutzte Cookie einrichten, aber bei der gepatchten Version konnten wir nicht auf das ausgenutzte Cookie zugreifen.
In dieser Aufgabe habe ich etwas über den Prototype-Pollution-Angriff gelernt, etwas über das JavaScript-Objekt gelernt und wurde in das Tough-Cookie-Paket eingeführt.