Drei Hochrufe auf (Entwurfsphase) Fortschritte bei einer Sanitizer API! Es ist ein unumstößliches Gesetz, dass man Benutzereingaben nicht trauen kann. Und tatsächlich hat jede Anwendung, an der ich je gearbeitet habe, sich mit bösartigen Akteuren befasst, die versucht haben, schädlichen Code einzuschleusen und auszuführen, wo er nicht hingehört.
Es ist die Aufgabe des Webentwicklers, Benutzereingaben zu bereinigen, bevor sie wieder auf der Seite verwendet (oder gespeichert oder serverseitig genutzt) werden. Dies geschieht normalerweise mit eigenem Code oder heruntergeladenen Bibliotheken, die helfen. Wir schreiben vielleicht einen regulären Ausdruck, um alles zu entfernen, was wie HTML (oder Ähnliches) aussieht, was das Risiko von Fehlern birgt und dass diese bösartigen Akteure einen Weg finden, das zu umgehen, was unser Code tut.
Anstatt auf Benutzer-Bibliotheken oder unser eigenes Herumgehampel zu setzen, könnten wir den Browser machen lassen
// some function that turns a string into real nodes
const untrusted_input = to_node("<em onclick='alert(1);'>Hello!</em>");
const sanitizer = new Sanitizer();
sanitizer.sanitize(untrusted_input); // <em>Hello!</em>Dann soll es im Laufe der Zeit weiterhin eine Browser-Verantwortung bleiben. Wie im Entwurfsbericht heißt:
Der Browser weiß ziemlich gut, wann er Code ausführen wird. Wir können die User-Space-Bibliotheken verbessern, indem wir dem Browser beibringen, wie er HTML aus einer beliebigen Zeichenfolge auf sichere Weise rendern kann, und dies auf eine Weise tun, die viel wahrscheinlicher mit der eigenen sich ändernden Parser-Implementierung des Browsers gepflegt und aktualisiert wird.
So etwas sind Webstandards vom Feinsten. Man entdeckt etwas Ärgerliches (und/oder Gefährliches), das unzählige Leute tun müssen, und greift ein, um es sicherer, schneller und besser zu machen.
Helfen Sie mir hier: Ich finde keinen Grund, Benutzereingaben auf Browserebene zu bereinigen. Um bösartige Eingaben zu verhindern, die in einer Datenbank gespeichert oder später ausgegeben werden, müssen wir auf Serverebene bereinigen. Das liegt daran, dass ein bösartiger Benutzer nicht zögern wird, die API zu suchen und die bösartigen Eingaben direkt dort zu posten und dabei jegliche Browser-Level-Prüfungen zu umgehen.
Diese API ist eher für Informationen gedacht, die *aus* der Datenbank *auf* die Seite gelangen, als eine letzte Verteidigungslinie, nachdem die Daten bei der Eingabe in die Datenbank validiert/bereinigt wurden.
Systeme sollten einander nicht vertrauen. Ihre Client-Anwendung sollte davon ausgehen, dass die Antwort Ihrer API bösartig ist und beispielsweise durch einen Man-in-the-Middle-Angriff kompromittiert wurde. Bereinigen Sie immer die Ein- und Ausgaben jedes Systems.
Wenn meine Client-App HTML aus einer API-Antwort erhält (z. B. von einem Headless-CMS usw.), sollte sie dies IMMER bereinigen, bevor sie gerendert wird. Das bisherige Mittel der Wahl dafür war https://github.com/cure53/DOMPurify. Ich frage mich, wie diese neue Spezifikation im Vergleich abschneiden wird.
Dies kann XSS verhindern. Ja, Sie sollten serverseitig bereinigen, aber einige Anwendungen müssen die Daten nicht speichern. Zum Beispiel ein nicht persistenter Chat. Möglicherweise möchten Sie, dass Benutzer HTML teilen können, ohne das Risiko von XSS einzugehen, ohne dass eine Middleware serverseitig bereinigt. WebRTC ist zum Beispiel Client-zu-Client, Sie möchten das empfangende Ende vor der Ausführung von bösartigem JavaScript schützen.
Es geht hier nicht um die meisten Daten, sondern speziell darum, wenn Sie von Benutzern bereitgestelltes HTML anzeigen möchten, ohne das Risiko eines XSS-Angriffs einzugehen.
Auch wenn es vernünftig erscheinen mag, JavaScript aus dem HTML auf dem Server zu entfernen, ist das Parsen von HTML eine nicht triviale Aufgabe, die Browser leicht unterschiedlich handhaben. Es ist daher für einen Angreifer möglich, eine HTML-Nutzlast zu erstellen, die in Firefox JavaScript ausführt, während sie in Chrome oder JSDOM völlig sicher ist.
Da Sie nicht vorhersagen können, wie jeder Browser, über den jemand Ihre Website betrachtet, eine bestimmte HTML-Datei parst, ist es besser, sie unverändert zu speichern und später die Fähigkeiten des Browsers des Betrachters zu nutzen, um für diesen bestimmten Browser sicheres HTML zu generieren.
Das klingt großartig! So viele Websites müssen Benutzereingaben bereinigen. Der Code dafür wurde wahrscheinlich millionenfach neu geschrieben, jede Neufassung mit dem Potenzial für Fehler. Es ist so sinnvoll, dass dies Teil der Plattform ist!