flawopen.com/XSS/XSS-Typen
Reflected, Stored und DOM-basiertes XSS: Wo liegt der Unterschied?
Reflected, Stored und DOM-basiertes XSS beschreiben verschiedene Wege von nicht vertrauenswürdigen Daten in einen unsicheren Browserkontext. Sie können sich überschneiden: Entscheidend ist, woher der Wert stammt, ob er gespeichert wird, welcher Code ihn rendert und wen er erreicht.
Die drei Typen
Ein Anfragewert wird ohne kontextgerechte Kodierung in die Antwort übernommen und vom Browser als Markup oder Skript interpretiert. Ein Angreifer kann ein präpariertes Linkziel senden; die eigentliche Schwachstelle ist jedoch die unsichere Ausgabe von Anfragedaten. Korrigieren Sie die Ausgabe am Rendering-Punkt.
Nicht vertrauenswürdige Inhalte werden gespeichert und später unsicher für andere Nutzer gerendert, etwa in Kommentaren oder Profilfeldern. Jeder Besucher, der den Inhalt lädt, kann denselben unsicheren Kontext erhalten, bis der gespeicherte Wert oder der Rendering-Pfad korrigiert ist.
Clientseitiges JavaScript liest eine nicht vertrauenswürdige Quelle (etwa location.hash, einen URL-Parameter oder Serverdaten) und schreibt sie in eine unsichere DOM-Senke wie innerHTML. Der Wert muss den Server nicht erreichen: DOM-XSS beschreibt den clientseitigen Source-to-Sink-Pfad und kann sich mit Reflected oder Stored XSS überschneiden. Korrigieren Sie den Datenfluss im Client.
Warum der Unterschied für die Behebung wichtig ist
Beheben Sie XSS an der Rendering-Senke mit kontextgerechter Ausgabekodierung oder einer sicheren DOM-API. Reflected und Stored XSS betreffen oft serverseitig gerenderte Ausgabe, doch auch clientseitiges Rendering kann eine unsichere Senke schaffen. Für DOM-XSS verwenden Sie für Text textContent statt innerHTML; falls HTML nötig ist, nutzen Sie einen gepflegten Sanitizer mit expliziter Policy. Serverseitige Kodierung ersetzt nicht die Prüfung clientseitiger Source-to-Sink-Flüsse.
Diese Kategorien können sich überschneiden
Reflected und Stored XSS beschreiben, wie Eingaben eine Seite erreichen und ob sie gespeichert bleiben. DOM-basiert beschreibt einen clientseitigen Source-to-Sink-Pfad. Die Kategorien schließen sich nicht gegenseitig aus: Persistenter Profiltext, den Clientcode in innerHTML einfügt, kann zugleich Stored und DOM-basiertes XSS sein.
DOM-basiertes XSS: unsicherer Sink und reine Textausgabe
const value = new URLSearchParams(location.search).get("q") ?? "";
target.innerHTML = value;
const value = new URLSearchParams(location.search).get("q") ?? "";
target.textContent = value;
Quellen
- OWASP XSS Prevention Cheat Sheet
- OWASP DOM-based XSS Prevention Cheat Sheet
- flawopen.com — Cross-Site Scripting