Skip to content

DOM-XSS debuggen, indem man den echten Datenfluss verfolgt

DOM-XSS versteht man besser über Quellen, Transformationen und Sinks als über zufällige Payload-Versuche.

Veröffentlicht am 1 Min. Lesezeit

DOM-XSS steckt selten in einer einzelnen offensichtlichen Zeile. Die Quelle kann in der URL, einer Nachricht, Local Storage oder einer JSON-Antwort liegen. Der Sink erscheint oft später in einer anderen Komponente.

Darum ist der Datenfluss wichtiger als der erste Payload.

Beginne an der Quelle

Bestimme, woher der kontrollierte Wert kommt: location.search, location.hash, postMessage, document.referrer oder persistierter Zustand. Beobachte danach, ob die Anwendung dekodiert, verkettet oder transformiert, bevor sie rendert.

Ende am Sink

Suche Schreibvorgänge in innerHTML, outerHTML, insertAdjacentHTML, document.write oder Framework-APIs, die Escaping deaktivieren. Der Befund muss Quelle und Sink reproduzierbar verbinden.

Reporte den Pfad

Ein guter Report sagt nicht nur „Payload zeigt Alert“. Er erklärt: Query q wird gelesen, an die Preview-Komponente übergeben, in HTML verkettet und landet in innerHTML. Das ist behebbar.

Verwandte Artikel

Verantwortungsvolle XSS-Tests hängen von Scope, sauberer Evidenz, Datenminimierung und dem richtigen Zeitpunkt zum Stoppen ab.
Ein praktischer Blick darauf, warum XSS-Werkzeuge interne URLs, private Fragmente und sensible Testnotizen nicht serverseitig verarbeiten sollten.
Die Payload-Auswahl ist weniger wichtig als der Injektionskontext: HTML, Attribute, URLs, Scripts und DOM-Sinks scheitern unterschiedlich.