Entwicklertools · HTML-WYSIWYG-Editor
Eingefügtes HTML bereinigen: Was Sie entfernen müssen, bevor es Ihr CMS oder Ihre E-Mail erreicht
· Wie es funktioniert
html Sicherheit Textbereinigung
Erklärt, was ein HTML-Desinfektionsmittel tut, von Tags und Attributen auf der Zulassungsliste bis hin zu entfernten Skripten und neutralisierten URLs, und wie die erste Überprüfung des Markups das Schreiben von Sanitiser-Regeln erleichtert.
Das eingefügte Snippet, das einen Onclick enthielt – wird mit dem versteckten Risiko in der Rich-Text-Eingabe geöffnet
Ein eingefügter Anker kann einen Onclick neben einem harmlosen Ziel verbergen. ToolAcre schreibt jeden Attributnamen in Kleinbuchstaben und behält nur die Attribute bei, die explizit für das akzeptierte Element aufgelistet sind, sodass onclick auch dann verschwindet, wenn die Groß-/Kleinschreibung geändert wird. Der Entfernungsbericht identifiziert diesen Ereignishandler, anstatt stillschweigend die unveränderte Quelle anzuzeigen.
Diese Grenze gilt vor dem Einfügen von Rich Paste, wenn die Quelle in den visuellen Modus zurückkehrt, vor dem Kopieren, vor der Nur-Text-Extraktion und erneut während der Erstellung von Vorschaudokumenten. Durch Wiederholung wird das versehentliche Umgehen zwischen Aktionen reduziert, aber das Projekt weigert sich immer noch, den handgeschriebenen Tokenizer als Allzweck-XSS-Filter zu bezeichnen.
Warum Zulassungslisten Sperrlisten schlagen – erklärt, dass es sicherer ist, zu benennen, was erlaubt ist, als zu versuchen, jedes gefährliche Konstrukt aufzulisten
Eine Zulassungsliste beginnt mit der Benennung zulässiger Strukturen: Absätze, Überschriften, semantische Inline-Elemente, Listen, Beschreibungslisten, Zitate, codeähnliche Elemente und Anker. Ein unbekannter gewöhnlicher Wrapper verliert sein Tag, während der Text erhalten bleibt. Ein gefährlicher Container wie Skript, Stil, Iframe, Formular, SVG oder MathML verliert ebenfalls seinen Inhalt.
Eine Sperrliste müsste jede gefährliche oder nicht unterstützte Konstruktion vorhersehen. Die Zulassungsliste lehnt ab, was sie nicht versteht. Dies ist eine gute Wahl für die eingeschränkte Ausgabe eines Editors, bleibt jedoch durch seinen Tokenizer begrenzt. Die Browser-HTML5-Fehlerbehebung kann einen anderen Baum erzeugen als ein kleinerer Parser, wenn es sich um absichtlich fehlerhafte Eingaben handelt.
Tags, Attribute und URL-Schemata – deckt die drei Ebenen eines Desinfektionsfilters ab, mit typischen Entscheidungen für jede
Die Filterung erfolgt auf drei Ebenen. Elemente bestimmen das Strukturvokabular. Attribute pro Element erlauben nur wenige Werte wie Link-Href und -Titel, Zitatzitierung, Abkürzungstitel sowie Anfang und Typ der geordneten Liste. Anschließend dekodiert die URL-Inspektion Entitäten, entfernt Steuerelemente und Leerzeichen aus einer Sonde und überprüft das resultierende Schema.
Akzeptierte Schemata sind http, https, mailto, tel und ftp sowie relative Formen ohne explizites Schema. JavaScript, Daten, Dateien, Blobs, VBScripts und About-Beispiele werden in Tests abgelehnt. Überlebende Links erhalten relative Werte, dieser Zusatz ist jedoch kein Ersatz für Zielrichtlinien oder Linküberprüfungen.
Stile: entfernen, zulassen oder umschreiben – erläutert die Handhabung von Inline-Stilen und warum viele Systeme sie vollständig aufgeben
Stilattribute werden vollständig entfernt. Das Modul versucht nicht, Deklarationen zu analysieren, eine sichere Teilmenge beizubehalten oder Design-Tokens neu zu schreiben. Diese Richtlinie entfernt kopierte Erscheinungsbilder und CSS-basierte Anforderungsoberflächen zusammen. Auch Klassen-, ID- und Datenattribute verschwinden, wodurch portables, aber bewusst weniger ausdrucksstarkes Markup entsteht.
Systeme mit einer echten Stilanforderung benötigen eine andere überprüfte Richtlinie. Das Hinzufügen von Stil zu dieser Zulassungsliste ohne CSS-Bereinigung würde ihre Sicherheitsoberfläche erheblich verändern. Die aktuelle Implementierung vermeidet dieses Problem, anstatt zu behaupten, die CSS-Sicherheit für beliebige feindliche Fragmente zu lösen.
Funktioniertes Beispiel: Leiten Sie die Regel von der dokumentierten Zulassungsliste von ToolAcre ab, nicht von einer Word-spezifischen Vorrichtung
Beginnen Sie mit `<div class="WordSection"><p style="color:red" onclick="x()">Notice <strong>today</strong></p></div>`. Das div wird entpackt, Klasse und Stil können nicht überleben, onclick wird entfernt und der Absatz sowie das starke Element bleiben erhalten. Das Ergebnis folgt einer allgemeinen Richtlinie, ohne anzugeben, welche Anwendung den Wrapper erstellt hat.
Fügen Sie eine Javascript-Href und einen Skriptblock hinzu. Der Anker behält seine sichtbaren Wörter, verliert aber href; Schrift und Text verschwinden. Lesen Sie die gemeldeten Gründe. Diese Übung hilft beim Definieren einer Serverrichtlinie, aber das blinde Kopieren der genauen Teilmenge von ToolAcre kann dazu führen, dass Elemente weggelassen werden, die Ihre Anwendung benötigt, oder URLs zugelassen werden, die Ihr Bedrohungsmodell verbietet.
Serverseitige und clientseitige Bereinigung – erklärt, warum der Server eine Bereinigung durchführen muss, auch wenn der Browser dies bereits getan hat
Client-Filterung verbessert die lokale Erstellung von Entwürfen, kann aber von einem Server, der benutzergesteuerte Anfragen empfängt, nicht als vertrauenswürdig eingestuft werden. Angreifer können die Seite umgehen, einen Endpunkt direkt aufrufen oder einen Parser-Unterschied ausnutzen. Der Server muss erneut mit einer verwalteten HTML5-fähigen Implementierung analysieren und bereinigen, die für seinen Rendering-Kontext konfiguriert ist.
Die Ausgabekodierung bleibt ebenfalls getrennt. Als Text gedachter HTML-Code muss von der Vorlage maskiert und nicht als Markup eingefügt werden. Ein absichtlich als HTML gerendertes Fragment muss je nach Architektur vor der Speicherung oder Ausgabe bereinigt werden. Eine Sandbox-Vorschau beweist nur, dass diese Vorschau keine Skripte, Formulare oder Same-Origin-Zugriff gewährt.
Was dieses Tool abdeckt – eine eingeschränkte Editor-Ausgabefilterung, keine allgemeine Bereinigung feindseliger Eingaben
ToolAcre filtert seine eigene Ausgabeoberfläche, im Gegensatz zur Behauptung der Arbeitsmappe, dass es sich lediglich um ein Inspektionstool handelt. Die genaue Korrektur ist enger gefasst: Es handelt sich nicht um ein Allzweck-XSS-Desinfektionsmittel für willkürliche feindselige Eingaben. Die Quelle sagt dies ausdrücklich und dokumentiert einen möglichen Parser-Unterschied.
Der Iframe dient der Tiefenverteidigung für das Rendering in ToolAcre. Sein leeres Sandbox-Attribut gewährt keine Skriptausführung, keine Formularübermittlung oder keinen Zugriff auf denselben Ursprung, und die Referrer-Richtlinie lautet „No-Referrer“. Sobald HTML an eine andere Stelle kopiert wird, wird es durch diesen Frame nicht mehr geschützt. Die Sicherheit der Veröffentlichung liegt beim empfangenden System.
Takeaway: Lokal prüfen, auf dem Server desinfizieren – fasst den Arbeitsablauf zusammen und wie der Editor Ihnen hilft, zu erkennen, was auf einen Desinfizierer zukommt
Lokal prüfen, auf dem Server bereinigen und je nach Kontext rendern. Das sind drei verschiedene Schritte. ToolAcre hilft dabei, eingefügten Ballast aufzudecken und bietet eine konservative Entwurfsteilmenge, während Entfernungshinweise Richtlinieneffekte sichtbar machen, bevor ein Fragment ein CMS oder einen E-Mail-Workflow erreicht.
Vermarkten Sie eine erfolgreiche Vorschau nicht als Beweis gegen XSS. Verwenden Sie Testnutzlasten nur in Einweginhalten, bewahren Sie die Rohquelle separat auf, wenn eine Untersuchung erforderlich ist, und überprüfen Sie die Zielbereinigung unabhängig. Sicherheitsansprüche sollten genau dort enden, wo die Code- und Rendering-Grenze aufhört.