XSS (Cross-Site Scripting)

Kurz: Ein Angriff, bei dem fremder JavaScript-Code auf einer vertrauenswürdigen Website im Browser anderer Besucher ausgeführt wird — meist, weil die Seite Eingaben ungeprüft als HTML ausgibt.

Genauer: Der Angreifer schleust Code über ein Formular, einen Kommentar oder einen Link ein. Zeigt die Seite das später anderen Nutzern an, läuft der Code mit deren Rechten: Er kann Sitzungen stehlen, Aktionen im Namen des Opfers auslösen oder Inhalte fälschen. Man unterscheidet gespeichertes XSS (Code liegt dauerhaft in der Datenbank), reflektiertes XSS (Code steckt im Link) und DOM-basiertes XSS (Fehler im Browser-Skript).

Kontext bei uns: React escaped Text standardmäßig. Die wenigen Stellen mit dangerouslySetInnerHTML (News-Artikel, Wiki-Metadaten, JSON-LD) geben nur bereinigten Inhalt aus: HTML von Admins wird beim Speichern mit einer Allow-/Deny-Liste bereinigt, JSON-LD läuft durch eine Sicherungsfunktion. Die Vorschau im Editor steckt in einem iframe mit sandbox, in dem keine Skripte laufen.

Im Detail

Schutzmaßnahmen

1. Ausgabe escapen: Nutzereingaben nie als HTML ausgeben (Frameworks tun das standardmäßig).
2. HTML bereinigen: Wenn Formatierung nötig ist, mit einer bewährten Bibliothek und Allow-Liste bereinigen — nicht selbst mit Regex.
3. Content Security Policy: blockiert fremde Skripte als zweite Schranke.
4. Cookies absichern: HttpOnly verhindert, dass Skripte das Sitzungs-Cookie lesen (siehe Cookies).
5. Gefährliche URLs filtern: javascript:-Links und data:text/html sind klassische Einfallstore.

Warnungen von Scannern

Code-Scanner (SAST) melden jede Verwendung von dangerouslySetInnerHTML als Fund. Ob das ein echtes Risiko ist, hängt davon ab, woher der Inhalt kommt und ob er bereinigt wurde — deshalb gehört zu jedem Fund eine Prüfung im Einzelfall, siehe SAST, SCA und Secret-Scanning.

Siehe auch: CSP, SQL-Injection, Cookies