Ist es möglich, JSON-Antworten mit dem richtigen JavaScript-String-Escape durch XSS auszunutzen?

Question 1

JSON-Antworten können ausgenutzt werden, indem Array-Konstruktoren überschrieben werden oder wenn feindliche Werte nicht mit JavaScript-String-Escapezeichen versehen werden.

Nehmen wir an, beide Vektoren werden auf normale Weise adressiert. Google fängt die direkte Beschaffung von JSON-Antworten bekanntermaßen ab, indem es allen JSON-Dateien etwas voranstellt wie:

throw 1; < don't be evil' >

Und dann folgt der Rest des JSON. Dr. Evil kann dies also nicht, indem er die Art von Exploit verwendet, die besprochen wurde hier. Holen Sie sich Ihr Cookie (vorausgesetzt, Sie sind eingeloggt), indem Sie Folgendes auf seine Website stellen:

<script src="http://yourbank.com/accountStatus.json">

Was die String-Escape-Regeln angeht, nun, wenn wir doppelte Anführungszeichen verwenden, müssen wir jedem Backslash einen Backslash voranstellen und jedem Backslash einen weiteren Backslash usw.

Aber meine Frage ist, was ist, wenn Sie das alles tun?

Burp-Suite (das automatisierte Sicherheitstool) erkennt eingebettete XSS-Versuche, die in einer JSON-Antwort ohne HTML-Escapezeichen zurückgegeben werden, und meldet dies als XSS-Schwachstelle. Mir wurde gemeldet, dass meine Anwendung Sicherheitslücken dieser Art enthält, aber ich bin nicht davon überzeugt. Ich habe es versucht und kann einen Exploit nicht zum Laufen bringen.

Also das finde ich nicht richtig.

Es gibt einen speziellen Fall, nämlich das IE-MIME-artige Sniffing, von dem ich glaube, dass es zu einem Exploit führen könnte. Immerhin hatte IE 7 noch das “Feature”, dass in Bildkommentare eingebettete Script-Tags unabhängig vom Content-Type-Header ausgeführt wurden. Lassen wir ein solches offensichtlich dummes Verhalten erstmal beiseite.

Sicherlich würde der JSON entweder vom nativen JavaScript-Parser (Window.JSON in Firefox) oder von einem eval() gemäß dem alten Standard-jQuery-Verhalten. In keinem Fall würde der folgende Ausdruck dazu führen, dass die Warnung ausgeführt wird:

{"myJSON": "legit", "someParam": "12345<script>alert(1)</script>"}

Habe ich recht oder liege ich falsch?

Question 2

Diese potenzielle xss-Schwachstelle kann vermieden werden, indem die richtige verwendet wird Content-Type. Bezogen auf RFC-4627 Alle JSON-Antworten sollten die verwenden application/json Typ. Der folgende Code ist nicht angreifbar zu xss, testen Sie es:

<?php
header('Content-type: application/json'); 
header("x-content-type-options: nosniff");
print $_GET['json'];
?>

Das nosniff Header wird verwendet, um Content-Sniffing in alten Versionen von Internet Explorer zu deaktivieren. Eine andere Variante ist wie folgt:

<?php
header("Content-Type: application/json");
header("x-content-type-options: nosniff");
print('{"someKey":"<body onload=alert(\'alert(/ThisIsNotXSS/)\')>"}');
?>

Wenn der obige Code von einem Browser angezeigt wird, wurde der Benutzer aufgefordert, eine JSON-Datei herunterzuladen. das JavaScript wurde auf modernen Versionen von Chrome, FireFox und Internet Explorer nicht ausgeführt. Dies wäre eine RFC-Verletzung.

Wenn Sie JavaScript verwenden, um eval() das JSON oben oder schreiben Sie die Antwort auf die Seite, dann wird es DOM-basiertes XSS. DOM-basiertes XSS wird auf dem Client gepatcht, indem JSON bereinigt wird, bevor auf diese Daten reagiert wird.

Question 3

Burpsuite (das automatisierte Sicherheitstool) erkennt eingebettete XSS-Versuche, die in einer JSON-Antwort ohne HTML-Escapezeichen zurückgegeben werden, und meldet dies als XSS-Schwachstelle.

Möglicherweise versucht es, die im beschriebene Schwachstelle zu verhindern Regel 3.1 des OWASP XSS-Spickzettels.

Sie geben das folgende Beispiel für anfälligen Code:

<script>
    var initData = <%= data.to_json %>;
</script>

Selbst wenn doppelte Anführungszeichen, Schrägstriche und Zeilenumbrüche korrekt maskiert sind, können Sie aus JSON ausbrechen, wenn es in HTML eingebettet ist:

<script>
    var initData = {"foo":"</script><script>alert('XSS')</script>"};
</script>

jsFiddle.

to_json() -Funktion kann dieses Problem verhindern, indem jedem Schrägstrich ein umgekehrter Schrägstrich vorangestellt wird. Wenn JSON im HTML-Attribut verwendet wird, muss die gesamte JSON-Zeichenfolge HTML-escaped sein. Wenn es in einem verwendet wird href="javascript:" -Attribut muss URL-escaped sein.

Question 4

Wenn wir unseren Anwendungsbereich auf IE (alle Versionen) beschränken, davon ausgehen, dass Sie eine Website auf Basis von PHP oder ASP.NET betreiben und den IE-Anti-XSS-Filter ignorieren, dann liegen Sie falsch: Ihre Benutzer sind anfällig. Einstellung 'Content-type: application/json' wird auch nicht helfen.

Dies ist (wie Sie bereits erwähnt haben) auf das Inhaltserkennungsverhalten von IE zurückzuführen, das über das Sniffing nach HTML-Tags im Antworttext hinausgeht und eine URI-Analyse umfasst.

Dieser Blogbeitrag erklärt dies sehr gut:

https://www.adico.me/post/json-based-xss-exploitation

Question 5

Für die Aufzeichnung, obwohl ich eine Antwort akzeptiert habe, hatte ich für die genaue wörtliche Frage, die ich stelle, Recht und es gab keine Schwachstelle aufgrund des Vorhandenseins von nicht HTML-escaped, aber korrekt JSON-escaped HTML in JSON-Werten. Es könnte dort einen Fehler geben, wenn dieser Wert ohne clientseitiges Escaping in das DOM eingefügt würde, aber Burpsuite hat kaum eine Chance zu wissen, ob dies passieren würde, indem es sich nur den Netzwerkverkehr ansieht.

Im allgemeinen Fall der Bestimmung, was unter diesen Umständen eine Sicherheitslücke ist, ist es aufschlussreich zu erkennen, dass der Antwortinhalt eines JSON-Werts, obwohl es sich nicht wie ein gutes Design anfühlt, legitimerweise bekannt sein könnte, dass er sicherlich keine Benutzereingaben enthält und dies beabsichtigt ist bereits gerenderter HTML-Code sein, um ohne Escapezeichen sicher in das DOM eingefügt zu werden. Es zu umgehen, wäre ein (nicht sicherheitsrelevanter) Fehler, wie ich in einem anderen Kommentar erwähnt habe.