web-dev-qa-db-de.com

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

JSON-Antworten können ausgenutzt werden, indem Array-Konstruktoren überschrieben werden oder wenn feindselige Werte nicht durch JavaScript-Zeichenfolgen ersetzt werden.

Nehmen wir an, beide Vektoren werden auf normale Weise adressiert. Bekannterweise fängt Google das direkte Sourcing von JSON-Antworten ein, indem es vor allen JSON-Codes folgende Angaben enthält:

throw 1; < don't be evil' >

Und dann folgt der Rest der JSON. Dr. Evil kann also nicht die hier beschriebene Art des Exploits verwenden http://sla.ckers.org/forum/read.php?2,25788 Sie können Ihren Cookie (sofern Sie angemeldet sind) erhalten, indem Sie die Folgendes auf seiner Website:

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

Was die String-Escape-Regeln angeht, müssen wir, wenn wir doppelte Anführungszeichen verwenden, jeweils einen Backslash und jeden Backslash einen anderen Backslash usw. voranstellen.

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

Burpsuite (das automatisierte Sicherheitstool) erkennt eingebettete XSS-Versuche, die in einer JSON-Antwort als unHTML-geschützt zurückgegeben werden, und meldet sie als XSS-Sicherheitsanfälligkeit. Ich habe einen Bericht, dass meine Anwendung Schwachstellen dieser Art enthält, aber ich bin nicht überzeugt. Ich habe es ausprobiert und kann keinen Exploit schaffen.

Ich denke nicht, dass dies richtig ist, aber ich bitte Sie, die StackOverflow-Community, sich einzumischen. 

Es gibt einen speziellen Fall, den von IE vom MIME-Typ, der meiner Meinung nach zu einem Exploit führen könnte. Schließlich hatte IE 7 immer noch das "Feature", dass in Bildkommentare eingebettete Skript-Tags unabhängig vom Content-Type-Header ausgeführt wurden. Lassen Sie uns auch ein solches eindeutig dummes Verhalten zunächst beiseite lassen.

Sicherlich würde der JSON entweder vom nativen JavaScript-Parser (Window.JSON in Firefox) oder von eval () gemäß dem alten Standardverhalten von jQuery analysiert werden. 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 irre ich mich

36
Chris Mountford

Obwohl ich eine Antwort akzeptierte, stimmte ich zu der genauen wörtliche Frage, die ich frage, hatte recht und es gab keine Sicherheitsanfälligkeit aufgrund des Vorhandenseins von HTML-fremden HTML-Inhalten, die in JSON-Werten vorhanden waren. Es könnte einen Fehler geben, wenn dieser Wert in das DOM ohne clientseitige Escape-Operation eingefügt wird. Burpsuite hat jedoch nur eine geringe Chance zu wissen, ob dies durch bloße Betrachtung des Netzwerkverkehrs geschehen würde. 

Im allgemeinen Fall der Feststellung einer Sicherheitsanfälligkeit unter diesen Umständen ist es aufschlussreich zu erkennen, dass der Antwortinhalt eines JSON-Werts zwar durchaus nicht als gutes Design empfunden wird, er jedoch durchaus berechtigt ist, sicher keine Benutzereingaben zu enthalten und beabsichtigt ist HTML bereits gerendert sein, um sicher in das DOM eingefügt zu werden. Es wäre ein (nicht sicherheitsrelevanter) Fehler, den ich in einem anderen Kommentar erwähnte.

0
Chris Mountford

Diese potenzielle xss-Schwachstelle kann durch Verwendung des korrekten Content-Type vermieden werden. Basierend auf RFC-4627 sollten alle JSON-Antworten den Typ application/json verwenden. Der folgende Code ist nicht anfällig für xss, testen Sie ihn: 

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

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

<?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 in modernen Versionen von Chrome, FireFox und Internet Explorer nicht ausgeführt. Dies wäre eine RFC-Verletzung.

Wenn Sie JavaScript für eval() des obigen JSON verwenden oder die Antwort auf die Seite schreiben, wird diese zu DOM-basiertes XSS . DOM-basiertes XSS wird auf dem Client durch Bereinigen des JSON-Patches gepatcht, bevor diese Daten verarbeitet werden.

26
rook

Burpsuite (das automatisierte Sicherheitstool) erkennt eingebettete XSS-Versuche Das wird in einer JSON-Antwort mit UnHTML-Escapeing zurückgegeben und meldet dies als XSS-Schwachstelle.

Möglicherweise wird versucht, die in der Regel 3.1 von OWASP XSS Cheat Sheet beschriebene Sicherheitsanfälligkeit zu verhindern.

Sie geben folgendes Beispiel für anfälligen Code:

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

Selbst wenn doppelte Anführungszeichen, Schrägstriche und Zeilenumbrüche ordnungsgemäß geschützt werden, können Sie JSON ausbrechen, wenn es in HTML eingebettet ist:

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

jsFiddle .

to_json() function kann dieses Problem verhindern, indem jedem Schrägstrich ein Backslash vorangestellt wird. Wenn JSON im HTML-Attribut verwendet wird, muss die gesamte JSON-Zeichenfolge HTML-geschützt sein. Wenn es in einem href="javascript:"-Attribut verwendet wird, muss es URL-Escape-Zeichen sein.

7
Alexey Lebedev

Wenn wir unseren Geltungsbereich auf IE (alle Versionen) beschränken, gehen Sie davon aus, dass Sie eine Site betreiben, die auf PHP oder ASP.NET basiert, und ignorieren den IE - Anti-Xss-Filter falsch: Ihre Benutzer sind anfällig. Die Einstellung 'Content-type: application/json' hilft auch nicht. 

Dies ist (wie Sie bereits erwähnt haben) auf das Verhalten bei der Inhaltserkennung von IE zurückzuführen, das über die Erkennung von HTML-Tags im Antworttextkörper hinausgeht und die URI-Analyse einschließt.

Dieser Blogeintrag erklärt das sehr gut:

http://blog.watchfire.com/wfblog/2011/10/json-based-xss-exploitation.html

0
anon