2010-08-16 14 views
12

Es stellt sich die folgende aus, die wie gültig Javascript aussieht, ist nicht:Was ist der richtige Weg, um ein Inline-Javascript-Objekt zu verschlüsseln, um es vor XSS zu schützen?

<html> 
<body> 
<script> 
json = {test: "</script><script>alert('hello');</script>"}; 
</script> 
</body> 
</html> 

Der gleiche Text, wenn JSON über ein Ajax-api zurück funktioniert wie erwartet. Wenn es jedoch inline gerendert wird, führt dies zu grundlegenden XSS-Problemen.

Ist eine beliebige, richtige JSON-Zeichenfolge angegeben, was muss ich auf der Serverseite tun, um sie für das Inline-Rendering sicher zu machen? kann es

json = {test: "<\/script><script>alert('hello');<\/script>"};

Bedeutung, ich habe keine Ahnung, wie meine zugrunde liegende Bibliothek kodiert, das / char,:

EDIT Im Idealfall durch die folgende Zeichenfolge als auch ich möchte das Update arbeiten habe gewählt, es zu kodieren, oder es kann nicht haben. (So ​​seine wahrscheinlich ein regex fix robuster ist)

+0

Wenn Sie es inline darstellen möchten, müssen Sie sicherstellen, dass es nicht die Zeichenfolge "" enthält. –

+0

oder Ich denke ... Ich mache mir Sorgen über die Leistung mit einer einfachen String-Verkettung beheben und auch dass es andere seltsame Probleme, die ich nicht kenne –

+0

Es sei denn, es ist etwas seltsam passiert, entgeht die zugrunde liegende Bibliothek nicht den Schrägstrich . Es hat keine spezielle Bedeutung in einer JavaScript-Zeichenfolge, daher gibt es keinen Grund, der Zeichenfolge zu entkommen. – Guffa

Antwort

3

mit zu starten, ist dies nicht JSON überhaupt, Es ist ein Javascript-Objekt. JSON ist ein Textformat, das auf der Javascript-Syntax basiert.

können Sie entweder sicherstellen, dass der Code nicht die </ Zeichenkombination enthält:

var obj = { test: "<"+"/script><script>alert(\"hello\");<"+"/script>" }; 

Oder wenn Sie XHTML verwenden, können Sie sicherstellen, dass der Inhalt in dem Script-Tag als Klardaten interpretiert :

<script type="text/javascript"> 
//<![CDATA[ 
var obj = { test: "</script><script>alert(\"hello\");</script>" }; 
//]]> 
</script> 
+0

korrigiert die Phrasierung in der Frage, fühlen Sie sich frei, Schritt und korrigieren Sie es weiter. Die "" <"+"/"fühlt sich etwas leistungsschwach, die CDATA-Lösung ist wirklich elegant –

+0

Eigentlich darüber nachzudenken, sollte ein serverseitiges Update von' gsub ("

+0

@Sam Saffron: Ja, die Verwendung eines Backslash funktioniert auch, um die ' Guffa

2

In Literalzeichenfolgen, setzen Sie einen umgekehrten Schrägstrich (\), bevor alle „unsicher“ Zeichen, einschließlich dem Schrägstrich die (  →   \//) in „</script>“ auftritt.

json = {test: "<\/script><script>alert(\"hello\");<\/script>"}; 

und es wäre immer noch gültig JSON sein:

Dies würde Ihr Beispiel ändern.

Natürlich müssen Sie auch die doppelten Anführungszeichen ("   →   \") entkommen und den Backslash selbst (\   →   \\), aber man würde schon die sowieso zu tun hat. Sie sollten auch in Betracht ziehen, das einfache Angebot zu umgehen ('   →   \'), um auf der sicheren Seite zu sein.

+0

also sollte ein einfaches ersetzen ("/", "\ /") tun? irgendwelche anderen Randfälle? –

+0

@Sam Saffron: Ja, achten Sie auf doppelte Anführungszeichen, einfache Anführungszeichen und Backslashes. Siehe meine bearbeitete Antwort. – Timwi

+0

cool, yerp hatte ich schon die codiert, meine Frage mit einem etwas haarigeren Beispiel erweitert. –

1

fand ich this Liste von Zeichen für JSON-Strings maskiert werden:

\b Backspace (ascii code 08) 
\f Form feed (ascii code 0C) 
\n New line 
\r Carriage return 
\t Tab 
\v Vertical tab 
\' Apostrophe or single quote 
\" Double quote 
\\ Backslash character 

PHP? Wenn ja: json_encode

echo json_encode("<\/script><script>alert(\"hello\");<\/script>"); 

Ausgang:

"<\\\/script><script>alert(\"hello\");<\\\/script>" 

Ein weiteres Beispiel:

echo json_encode("</script><script>alert(\"hello\");</script>"); 

Ausgang:

"<\/script><script>alert(\"hello\");<\/script>" 
+0

Entkommt der Schrägstrich? Die Hilfeseite sagt nicht. (In der Tat, es sagt nicht, was * alle * der Optionen bedeuten.) – Timwi

+0

Beispiel hinzugefügt, sieht aus wie es den Schrägstrich Flucht :) –

+0

können Sie auf den Algorithmus erweitern, den ich verwenden sollte? Ich verwende kein PHP –

4

Siehe OWASP's XSS prevention guide (Regel # 3) Siehe -

Außer für alphanumerische Zeichen, Escape alle Zeichen kleiner als 256 mit dem Format \ xHH zu verhindern aus dem Datenwert in den Skriptkontext oder in ein anderes Attribut zu wechseln. Verwenden Sie keine Flucht Abkürzungen wie \“, weil das Zitat Charakter durch das HTML Attribut-Parser, die erste läuft angepasst werden kann

Angenommen, das ist, wie Sie Ihr Objekt aussieht -.


var log = { 
trace: function(m1, m2, m3){}, 
debug: function(m1, m2, m3){}, 
currentLogValue : "trace {].a23-%\/^&", 
someOtherObject : {someKey:"somevalue", someOtherKey:"someothervalue"} 
}; 

Dies sollte bis am Ende wie folgt -


var log = { 
trace : "function\x28m1,\x20m2,\x20m3\x29\x7B\x7D", 
debug : "function\x28m1,\x20m2,\x20m3\x29\x7B\x7D", 
currentLogValue : "trace\x20\x7B\x5D.a23\x2D\x25\x5C\x2F\x5E\x26", 
someOtherObject : {someKey : "somevalue", someOtherKey:"someothervalue"} 
}; 

Die Regeln sind einfach -

  1. Untrusted Daten werden nur innerhalb eines Paares von Zitaten erlaubt
  2. Was auch immer in Anführungszeichen ist entkommen wird wie folgt - „Mit Ausnahme von alphanumerischen Zeichen, Flucht alles andere mit dem \ xHH Format“

Dies stellt sicher, dass Nicht vertrauenswürdige Daten werden immer als String interpretiert und nicht als Funktion/Objekt/irgendetwas anderes.

2

Ein Problem, auf das Sie möglicherweise stoßen, ist die Tatsache, dass die HTML- und JavaScript-Interpreter im Browser interleaved ausgeführt werden.

<html> 
<body> 
<script> 
json = {test: "</script><script>alert('hello');</script>"}; 
</script> 
</body> 
</html> 

In Ihrem Beispiel wird das HTML-Interpreter json = {test: " zum js Dolmetscher geben und dann wird es den nächsten Javascript-Block (begrenzt durch <script> und </script> Tags) und gibt alert('hello'); zum js Interpreter finden. Es spielt keine Rolle, dass das </script>-Tag in einer JavaScript-Zeichenfolge ist, da der HTML-Interpreter derjenige ist, der nach js-Codeblöcken sucht und js-Zeichenfolgen nicht versteht.

Der erste Abschnitt verursacht einen JS-Syntaxfehler, während der zweite Abschnitt die Warnung erstellt. Ich weiß, dass dies deine Frage, was zu tun ist, nicht beantwortet, aber vielleicht wird es mehr Licht auf das werfen, was unter der Haube passiert.

Verwandte Themen