Skip to content

XSS-Encoding-Pipelines: warum die Reihenfolge das Ergebnis verändert

URL-Encoding, HTML-Entities und Base64 sind nicht austauschbar: Die Reihenfolge muss den Transformationen der Anwendung folgen.

Veröffentlicht am 1 Min. Lesezeit

Bei XSS ist Encoding keine Dekoration. Eine andere Reihenfolge kann im Browser eine völlig andere Zeichenkette erzeugen.

URL-Encoding, HTML-Entities, Base64 und JavaScript-Escapes wirken auf unterschiedlichen Schichten. Wer sie ohne echten Eingabepfad kombiniert, erzeugt False Positives und False Negatives.

Folge dem Dekodierpfad

Wenn ein Parameter zuerst URL-dekodiert, dann in HTML eingefügt und später von JavaScript gelesen wird, muss der Test diese Kette widerspiegeln. Transformationen sind kein Wunschkonzert.

Jeden Schritt anzeigen

Ein gutes Werkzeug zeigt Raw Input, Mutationen und finales Ergebnis. So sieht der Tester, wann %253C zu %3C wird und wann schließlich < ankommt.

Reihenfolge reporten

Das Team braucht die fehlerhafte Schicht. „Doppeltes URL-Decoding vor innerHTML“ ist deutlich hilfreicher als „kodierter Payload funktioniert“.

Verwandte Artikel

Die Payload-Auswahl ist weniger wichtig als der Injektionskontext: HTML, Attribute, URLs, Scripts und DOM-Sinks scheitern unterschiedlich.
Lokale Payload-Sammlungen helfen beim Wiederholen von Tests, ohne das Werkzeug zu einem entfernten Speicher sensibler Daten zu machen.
Verantwortungsvolle XSS-Tests hängen von Scope, sauberer Evidenz, Datenminimierung und dem richtigen Zeitpunkt zum Stoppen ab.