FlawOpen

flawopen.com/XSS in JavaScript/dangerouslySetInnerHTML

Ist dangerouslySetInnerHTML in React sicher?

Referenzseite
Kurzantwort

Stell dir gewöhnliches JSX wie einen Etikettendrucker vor: Text bleibt Text. dangerouslySetInnerHTML wechselt zu einer Presse, die die Zeichenfolge als HTML interpretiert. Enthält sie angreiferkontrollierte Inhalte, kann der Browser sie als aktives Markup behandeln. Verwende diese Senke nur für bewusst vertrauenswürdiges oder für genau diesen HTML-Kontext bereinigtes HTML.

Warum gewöhnliches JSX das nicht braucht

RISKANT — ungeprüftes HTML
function Comment({ html }) {
  return <p dangerouslySetInnerHTML=
    {{ __html: html }} />;
}
SICHER — gewöhnliche JSX-Interpolation
function Comment({ text }) {
  return <p>{text}</p>;
}

Wann ist dangerouslySetInnerHTML sinnvoll?

Verwende es nur, wenn das Produkt ein eingeschränktes Rich-Text-Format erhalten muss, das sich nicht als gewöhnliche React-Kinder darstellen lässt. Ein CMS, Editor oder Markdown-Renderer ist nicht automatisch vertrauenswürdig: Gespeicherte Inhalte und Renderer-Ausgaben können weiterhin nicht vertrauenswürdiges Markup enthalten. Lege erlaubte Elemente und Attribute fest, bereinige mit einer gepflegten Bibliothek wie DOMPurify und übergib das bereinigte Ergebnis direkt an diese Senke.

Richtige Verwendung

An der Rendergrenze bereinigen

Bereinige den Wert unmittelbar vor der Zuweisung an dangerouslySetInnerHTML mit einer gepflegten Bibliothek wie DOMPurify. Verwende keine regulären Ausdrücke als HTML-Sanitizer. Verändere die bereinigte Zeichenfolge danach möglichst nicht; eine spätere Transformation kann die Garantien aufheben. Halte den Sanitizer und seine Parsing-Umgebung aktuell.

Erlaubtes Markup begrenzen

Eine Sperrliste bekannter Tags ist unvollständig: Risiken können auch von Attributen, URL-Feldern, Namespaces und dem Parserverhalten ausgehen. Lege eine kleine Liste der benötigten Elemente und Attribute fest und konfiguriere den Sanitizer entsprechend. Prüfe Links und andere URL-Attribute zusätzlich anhand der im Produkt erlaubten Ziele.

Codebasis prüfen

grep -rn "dangerouslySetInnerHTML" --include="*.jsx" --include="*.tsx" .
Verfolge bei jedem Treffer den Wert vom Ursprung durch alle Transformationen. Behandle Benutzereingaben, importierte Inhalte und gespeicherten Rich Text als nicht vertrauenswürdig. Prüfe, ob die Sanitizer-Richtlinie zum Ausgabekontext passt und keine spätere Verarbeitung das bereinigte Ergebnis verändert.

Häufige Fragen

Ist Markdown-Rendering automatisch sicher?

Das hängt vom Renderer und seiner Konfiguration ab. Prüfe, ob rohes HTML zugelassen und die Ausgabe bereinigt wird; die Markdown-Konvertierung allein macht HTML nicht sicher.

Gilt das auch für Vues v-html?

Ja. Auch v-html übergibt HTML ohne gewöhnliche Textinterpolation des Frameworks an den Browser. Behandle den Wert als HTML-Senke und bereinige nicht vertrauenswürdige Inhalte mit einer passenden Richtlinie.

Quellen

Siehe auch Cross-Site-Scripting (XSS, CWE-79): Funktionsweise und Schutz in jeder Sprache — flawopen.com Reicht DOMPurify für sicheres innerHTML? Ist Markdown-Rendering vor XSS sicher? Schützt Svelte standardmäßig vor XSS? Ist ein SVG-Upload ein XSS-Risiko? XSS-Risiko durch Vue v-html WKWebView: Nicht vertrauenswürdiges HTML?