XSSI (Cross-Site Script Inclusion)
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)
Cross-Site Script Inclusion (XSSI) ist eine Schwachstelle, die sich aus der Natur des script
-Tags in HTML ergibt. Im Gegensatz zu den meisten Ressourcen, die der Same-Origin Policy (SOP) unterliegen, können Skripte von verschiedenen Domains eingebunden werden. Dieses Verhalten soll die Nutzung von Bibliotheken und anderen Ressourcen, die auf verschiedenen Servern gehostet werden, erleichtern, bringt jedoch auch ein potenzielles Sicherheitsrisiko mit sich.
Umgehung der SOP: Skripte sind von der Same-Origin Policy ausgenommen, was es ihnen ermöglicht, über Domains hinweg eingebunden zu werden.
Datenexposition: Ein Angreifer kann dieses Verhalten ausnutzen, um Daten zu lesen, die über das script
-Tag geladen werden.
Auswirkungen auf dynamisches JavaScript/JSONP: XSSI ist besonders relevant für dynamisches JavaScript oder JSON mit Padding (JSONP). Diese Technologien verwenden häufig "ambient-authority"-Informationen (wie Cookies) zur Authentifizierung. Wenn eine Skriptanfrage an einen anderen Host gesendet wird, werden diese Anmeldeinformationen (z. B. Cookies) automatisch in die Anfrage aufgenommen.
Leckage von Authentifizierungstoken: Wenn ein Angreifer den Browser eines Benutzers dazu bringen kann, ein Skript von einem Server anzufordern, den er kontrolliert, könnte er möglicherweise auf sensible Informationen zugreifen, die in diesen Anfragen enthalten sind.
Statisches JavaScript - Dies stellt die konventionelle Form von XSSI dar.
Statisches JavaScript mit Authentifizierung - Dieser Typ ist besonders, da er eine Authentifizierung zum Zugriff erfordert.
Dynamisches JavaScript - Bezieht sich auf JavaScript, das Inhalte dynamisch generiert.
Nicht-JavaScript - Bezieht sich auf Schwachstellen, die JavaScript nicht direkt betreffen.
Die folgenden Informationen sind eine Zusammenfassung von https://www.scip.ch/en/?labs.20160414. Überprüfe es für weitere Details.
In diesem Ansatz sind private Informationen in einer global zugänglichen JavaScript-Datei eingebettet. Angreifer können diese Dateien mit Methoden wie Dateilesen, Schlüsselwortsuche oder regulären Ausdrücken identifizieren. Sobald sie gefunden sind, kann das Skript, das private Informationen enthält, in bösartigen Inhalten eingebunden werden, was unbefugten Zugriff auf sensible Daten ermöglicht. Eine Beispielausnutzungstechnik ist unten dargestellt:
Diese Arten von XSSI-Angriffen beinhalten, dass vertrauliche Informationen dynamisch in das Skript hinzugefügt werden, als Reaktion auf eine Anfrage des Benutzers. Die Erkennung kann durchgeführt werden, indem Anfragen mit und ohne Cookies gesendet und die Antworten verglichen werden. Wenn die Informationen unterschiedlich sind, kann dies auf das Vorhandensein vertraulicher Informationen hinweisen. Dieser Prozess kann mit Tools wie der DetectDynamicJS Burp-Erweiterung automatisiert werden.
Wenn vertrauliche Daten in einer globalen Variablen gespeichert sind, können sie mit ähnlichen Methoden wie bei Regular XSSI ausgenutzt werden. Wenn die vertraulichen Daten jedoch in einer JSONP-Antwort enthalten sind, können Angreifer die Callback-Funktion hijacken, um die Informationen abzurufen. Dies kann entweder durch Manipulation globaler Objekte oder durch das Einrichten einer Funktion geschehen, die von der JSONP-Antwort ausgeführt wird, wie unten gezeigt:
Für Variablen, die sich nicht im globalen Namensraum befinden, kann Prototype Tampering manchmal ausgenutzt werden. Diese Technik nutzt das Design von JavaScript aus, bei dem die Code-Interpretation das Durchlaufen der Prototypenkette umfasst, um die aufgerufene Eigenschaft zu finden. Durch das Überschreiben bestimmter Funktionen, wie Array
's slice
, können Angreifer auf nicht globale Variablen zugreifen und diese leaken:
Weitere Details zu Angriffvektoren finden Sie in der Arbeit des Sicherheitsforschers Sebastian Lekies, der eine Liste von Vektoren führt.
Die Forschung von Takeshi Terada führt eine weitere Form von XSSI ein, bei der Non-Script-Dateien, wie CSV, cross-origin durch die Einbindung als Quellen in einem script
-Tag geleakt werden. Historische Fälle von XSSI, wie Jeremiah Grossmans Angriff im Jahr 2006, um ein vollständiges Google-Adressbuch zu lesen, und Joe Walkers JSON-Datenleck im Jahr 2007, heben die Schwere dieser Bedrohungen hervor. Darüber hinaus beschreibt Gareth Heyes eine Angriffsvariante, die UTF-7-kodiertes JSON verwendet, um das JSON-Format zu umgehen und Skripte auszuführen, was in bestimmten Browsern effektiv ist:
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)