Ich habe in letzter Zeit auf Pagedown.js geschaut, weil ich den Abdruck auf meinen Seiten anstelle von hässlichen, nur lesbaren Textareas verwenden wollte.
Ich bin jedoch sehr vorsichtig, da es leicht genug scheint, den sterilisierten Konverter zu täuschen. Ich habe einige Diskussionen um Angular.js und seine HTML-Bindungen gesehen und auch etwas gehört, als Knockout.js 3.0 herauskam, dass die HTML-Bindung vorher unsicher war.
Es scheint alles zu sein, was jemand tun müsste, um den Desinfizierer in Pagedown.js zu deaktivieren, zum Beispiel ist so etwas -
%Vor%und sie konnten eine Site bis zur Script-Injektion öffnen. Ist das nicht wahr?
Bearbeiten
Warum sollten Bibliotheken wie dieses Paket einen Desinfizierer verwenden, um clientseitig zu verwenden? Sicher sagen sie nicht unsanitisierten HTML-Wert zu machen, aber die nächste Zeile sagt Markdown.Sanitizer verwenden ..
Wie ist Angular nicht mit dem Sanitizer-Service zu öffnen oder ist das nur eine Farce?
Ich glaube, es gibt ein kleines Missverständnis über den Zweck und die Natur solcher "Sanitizer".
Der Zweck eines Desinfektionsmittels (z. B. Angulars ngSanitize ) ist nicht , um zu verhindern, dass "schlechte" Daten an die Serverseite gesendet werden. Es ist eher andersherum: Ein Desinfizierer ist da, um den nicht-böswilligen Benutzer vor bösartigen Daten zu schützen (entweder aufgrund einer Sicherheitslücke auf der Serverseite (ja, kein Setup ist perfekt). oder aus anderen Quellen geholt werden (von denen du nicht kontrollierst)).
Natürlich kann ein Desinfektionsmittel als clientseitiges Feature umgangen werden, aber da das Desinfektionsmittel dazu da ist, den Benutzer (nicht den Server) zu schützen, würde das Umgehen des Bypassors nur ungeschützt bleiben (was nicht möglich ist) tun Sie etwas, noch sollte es Ihnen egal sein - es ist ihre Wahl).
Darüber hinaus haben Desinfektionsmittel (können) eine andere (möglicherweise wichtigere) Rolle: Ein Desinfektionsmittel ist ein Werkzeug, das dem Entwickler hilft, seinen Code besser so zu organisieren, dass er für bestimmte Arten von Schwachstellen (z. B. XSS-Angriffe) besser getestet werden kann ) und hilft sogar beim eigentlichen Code-Auditing für solche Sicherheitslücken.
Meiner Meinung nach fassen Angular Docs das Konzept hübsch zusammen ordentlich:
Strict Contextual Escaping (SCE) ist ein Modus, in dem AngularJS Bindungen in bestimmten Kontexten erfordert, um einen Wert zu erhalten, der als sicher für diesen Kontext verwendet wird.
[...]
SCE unterstützt den Code so, dass (a) standardmäßig sicher ist und (b) Auditing für Sicherheitslücken wie XSS, Clickjacking usw. a viel einfacher .[...]
In einem realistischeren Beispiel kann man Benutzerkommentare, Blogartikel usw. per Binding darstellen. (HTML ist nur ein Beispiel für einen Kontext, in dem die vom Benutzer gesteuerte Eingabe Sicherheitsanfälligkeiten erzeugt.)Im Fall von HTML können Sie eine Bibliothek entweder auf der Clientseite oder auf der Serverseite verwenden, um unsiches HTML zu bereinigen, bevor Sie den Wert binden und im Dokument rendern.
Wie stellen Sie sicher, dass jeder Ort, an dem diese Bindungstypen verwendet wurden, an einen Wert gebunden wurde, der von Ihrer Bibliothek bereinigt wurde (oder von Ihrem Server als sicher für das Rendern zurückgegeben wird)? Wie können Sie sicherstellen, dass Sie nicht versehentlich < strong> löscht die Zeile, die den Wert bereinigt , oder hat einige Eigenschaften / Felder umbenannt und vergessen, die Bindung auf den bereinigten Wert zu aktualisieren?
Um standardmäßig sicher zu sein, möchten Sie sicherstellen, dass solche Bindungen nicht zulässig sind, es sei denn, Sie können feststellen, dass etwas ausdrücklich als sicher bezeichnet einen Wert für die Bindung in diesem Kontext verwendet. Sie können dann Ihren Code überprüfen (ein einfacher grep würde dies tun), um sicherzustellen, dass dies nur für die Werte geschieht, die Sie sicher erkennen können - weil sie von Ihrem Server empfangen und von Ihrer Bibliothek bereinigt wurden usw. Sie können Ihre Codebasis so organisieren, dass sie Ihnen dabei hilft . Dies können Sie möglicherweise nur den Dateien in einem bestimmten Verzeichnis gestatten. Wenn sichergestellt wird, dass die von diesem Code bereitgestellte interne API keine willkürlichen Werte als sicher markiert, wird sie zu einer besser verwaltbaren Aufgabe .
Anmerkung 1: Der Schwerpunkt liegt auf mir.
Anmerkung 2: Entschuldigung für das lange Zitat, aber ich halte das für sehr wichtig (z viel als sensible) Materie und eine, die zu oft missverstanden wird.
Sie können die Clientseite nicht bereinigen. Jeder könnte JavaScript ausschalten oder die Werte ändern und sie an Ihren Server senden.
Der Server braucht , um dies zu überprüfen. Client-Seite in meinem Kopf ist wirklich nur eine Usability-Funktion. So wissen sie, wie sie tippen, ob sie falsch oder richtig sind.
Als Antwort auf die Änderung:
Die meisten von ihnen sind Bequemlichkeit oder bieten Funktionalität. Zum Beispiel unauffällige Validierung werden meine Textfelder rot, wenn sie einen ungültigen eingeben Nummer. Das ist nett, und ich musste nicht posten und überprüfen und dann den Textfeldrand blablablabla ändern ...
Aber wenn sie posten, muss ich noch ihre Daten validieren. Ich behalte das normalerweise in einer Kernbibliothek, die über Anwendungen (Web, Webservice, mobile App, Thick Client usw.) gemeinsam genutzt werden kann.
Die Usability-Validierung variiert von Plattform zu Plattform. Bevor jedoch eine Anwendung den Daten vertraut, muss sie diese im Rahmen ihrer Vertrauensbarriere überprüfen. Niemand kann den Wert hinter meinem if auf dem Server ändern, aber jeder kann den Wert in seinem Browser ändern, ohne mein JS auszulösen.
Pagedown kann sowohl auf dem Server als auch auf dem Client ausgeführt werden.
Um HTML auf dem Client zu bereinigen, ist es sinnvoller, bei der Ausgabe statt bei der Eingabe zu bereinigen. Sie würden nicht vor dem Senden von Daten auf einen Server bereinigen, aber Sie könnten nach dem Empfangen von einem Server Daten bereinigen.
Stellen Sie sich vor, Sie führen einen Web-Service-Anruf auf dem Client aus und beziehen Daten von einem Drittanbieter-Dienst. Es könnte vor dem Rendern auf dem Client durch einen Desinfizierer übergeben werden. Der Benutzer könnte die Bereinigung auf seinem eigenen Computer deaktivieren, aber sie verletzen sich nur selbst.
Es ist auch außerhalb von Sicherheitsgründen nützlich, nur um zu verhindern, dass Benutzereingaben die Formatierung der umgebenden Seite versehentlich ändern. Wie beim Eintippen eines HTML-Posts mit einer Echtzeitvorschau (wie bei StackOverflow).
Überhaupt nicht sicher.
Kundenseitige Hygiene / Validierung sollte aus folgenden Gründen verwendet werden:
Alles, was Sie validieren, kann geändert werden, weil der Client nicht von Ihnen kontrolliert wird. Dinge wie Dev-Konsole, Fiddler , wireshark können Sie die Daten auf jede beliebige Weise manipulieren.
Es ist also nur der Server für die tatsächliche Hygiene / Validierung verantwortlich.
Tags und Links knockout.js javascript html angularjs javascript-injection