Einfügen von beliebigem JSON in das Skript-Tag von HTML

9

Ich möchte den Inhalt eines JSON in der Quelle eines HTML-Dokuments in einem Skript-Tag speichern.

Der Inhalt dieses JSON hängt von der vom Benutzer übergebenen Eingabe ab. Daher ist große Sorgfalt erforderlich, um diese Zeichenfolge für XSS zu bereinigen.

Ich habe zwei Konzepte hier auf SO gelesen.

1. Ersetzen Sie alle Vorkommen des </script -Tags in <\/script oder ersetzen Sie alle </ in <\/ Serverseite.

Codeweise sieht es wie folgt aus (mit Python und jinja2 für das Beispiel):

%Vor%

2. Kodieren Sie die Daten als HTML-Entity-codierte JSON-Zeichenfolge, und unescape + parsen Sie sie auf der Clientseite. Unescene stammt aus dieser Antwort: Ссылка

%Vor%

Diese Methode funktioniert nicht, weil \" in einer Skriptquelle zu " in einer JS-Variablen wird. Außerdem erzeugt es ein viel größeres HTML-Dokument und ist auch nicht wirklich lesbar, also würde ich mit dem ersten gehen, wenn es kein großes Sicherheitsrisiko bedeutet.

Gibt es ein Sicherheitsrisiko bei der Verwendung der ersten Version? Reicht es aus, eine JSON-codierte Zeichenfolge mit .replace('</script', r'<\/script') zu bereinigen?

Verweis auf SO:
Beste Methode zum Speichern von JSON in einem HTML-Attribut?
Warum das & lt; script & gt; Tag beim Schreiben mit document.write ()?
Skript-Tag in JavaScript string
Sanitize & lt; script & gt; element contents
Escape & lt; / in script tag-inhalten

Einige großartige externe Ressourcen zu diesem Thema:
Flask's tojson Filter Implementierung Quelle
Die Methode der Methode der Schiene und Quelle
Eine 5-jährige Diskussion in Django Ticket und vorgeschlagener Code

    
zsero 28.08.2016, 16:39
quelle

1 Antwort

1

Zunächst einmal ist Ihre Paranoia gut begründet.

  • Ein HTML-Parser könnte durch ein schließendes Skript-Tag (besser durch irgendein schließendes Tag) ausgetrickst werden
  • Ein JS-Parser könnte durch Backslashes und Anführungszeichen (mit einem wirklich schlechten Encoder) betrogen werden

Ja wäre es viel "sicherer", alle Zeichen zu codieren, die die verschiedenen beteiligten Parser verwirren könnten. Es lesbar zu halten könnte Ihrem Sicherheitsparadigma widersprechen.

Hinweis : Das Ergebnis der JSON-String-Codierung sollte kanonisch und OFC sein, nicht gebrochen, wie in Parsable. JSON ist eine Teilmenge von JS und kann daher ohne jegliches Risiko JS-parsierbar sein. Alles, was Sie tun müssen, ist sicherzustellen, dass die HTML-Parser-Instanz, die den JS-Code extrahiert, nicht durch Ihre Benutzerdaten ausgetrickst wird.

Der wahre Fallstrick ist also die Verschachtelung beider Parser. Eigentlich möchte ich Sie auffordern, so etwas in eine separate Anfrage zu stellen. Auf diese Weise würden Sie dieses Szenario vollständig vermeiden.

Unter der Annahme aller möglichen Stile und Fehlerkorrekturen, die in einem solchen Parser auftreten könnten, könnte es sein, dass andere Tags (Öffnen oder Schließen) eine ähnliche Leistung erzielen könnten.

Wie in: dem Parser vorschlagen, dass das Script-Tag implizit beendet wurde.

Es ist also ratsam, slash und alle Tag-Klammern (/, & ​​lt;, & gt;) zu codieren, nicht nur das Schließen eines Skript-Tags, in welcher reversiblen Methode Sie auch wählen, solange es nicht verwirren würde der HTML-Parser:

  • Die beste Wahl wäre base64 (aber Sie wollen lesbarer)
  • HTMLentitäten werden, obwohl verwirrende Menschen:)
  • Auch das Ausführen eigener Escapes funktioniert, entkomme einfach den einzelnen Zeichen und nicht dem </script Fragment

Zusammenfassend, ja, es ist wahrscheinlich am besten mit ein paar Änderungen, aber bitte beachten Sie, dass Sie bereits einen Schritt von "sicher" entfernt sind, indem Sie so etwas in erster Linie versuchen, anstatt den JSON über XHR oder zumindest mit einer rigorosen String-Codierung wie base64.

P.S .: Wenn Sie aus dem Code anderer Leute lernen können, der die Zeichenketten codiert, ist das schön, aber Sie sollten nicht auf "Bibliotheken" oder die Funktionen anderer Leute zurückgreifen, wenn sie nicht genau das tun, was Sie brauchen. Schreiben Sie also lieber Ihren eigenen (de / en) Coder und prüfen Sie, ob dieser Fall versiegelt ist.

    
anx 30.08.2017 02:17
quelle

Tags und Links