Skip to content

Kontext zuerst: der Teil von XSS-Tests, der zu oft übersprungen wird

Die Payload-Auswahl ist weniger wichtig als der Injektionskontext: HTML, Attribute, URLs, Scripts und DOM-Sinks scheitern unterschiedlich.

Veröffentlicht am 1 Min. Lesezeit

Viele schlechte XSS-Tests beginnen mit einer Payload-Liste.

Das wirkt hilfreich, bis die Anwendung die Eingabe in einem gequoteten Attribut, in einem JavaScript-String oder nach einem Sanitizer zurückspiegelt. Dann wird die Liste zu Rauschen.

Beginne mit dem Kontext.

Derselbe Payload ist nicht derselbe Test

"><svg onload=alert(1)>

Diese Zeichen bedeuten in einem HTML-Attribut etwas anderes als in JSON und fast nichts, wenn die Anwendung textContent verwendet. Ein Payload ist eine Hypothese darüber, wie der Browser die Zeichen nach Framework, Filter und Anwendung interpretiert.

Attribute haben unangenehme Kanten

Ist das Attribut gequotet? Einfach oder doppelt? Escaped das Framework Quotes, aber keine Backticks? Geht es um href, src, style, data-* oder bereits um einen Event Handler? Jeder Fall braucht eine andere Escape-Strategie.

DOM-XSS braucht Datenfluss statt Bauchgefühl

Die Quelle kann location.hash, postMessage, Query-Parameter oder Local Storage sein. Später schreibt eine Komponente den Wert in innerHTML oder insertAdjacentHTML. Diesen Pfad zu verfolgen erzeugt bessere Reports als zufälliges Payload-Spraying.

Verwandte Artikel

URL-Encoding, HTML-Entities und Base64 sind nicht austauschbar: Die Reihenfolge muss den Transformationen der Anwendung folgen.
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.