DOM-basierter XSS.

DOM-basierter XSS (Typ 0) ist eine Cross-Site-Scripting-Schwachstelle, deren Ursache ausschliesslich im clientseitigen Code liegt. Der Begriff wurde 2005 von Amit Klein in der Arbeit „DOM Based Cross Site Scripting or XSS of the Third Kind“ geprägt. Eine vertrauenswürdige Quelle — location.hash, location.search, document.referrer, window.name, postMessage oder localStorage — fliesst ohne Sanitisierung in einen gefährlichen Sink wie innerHTML, document.write, eval, setTimeout oder jQuery.html(). Da die schädliche Payload oft im URL-Fragment (nach #) mitreist, wird sie nie an den Server gesendet, was die Schwachstelle für WAFs, Server-Logs und die meisten Scanner für Reflected XSS unsichtbar macht.

Die reale Auswirkung ist gross: DOM-XSS ist wiederholt in Werbe- und Analytics-Tags, in postMessage-Handlern, die Cross-Origin-Daten vertrauen, und in veralteten jQuery-Selektoren ($(location.hash), gepatcht in CVE-2011-4969 für Versionen vor 1.6.3) aufgetaucht. Googles eigene Analyse ergab, dass die Mehrheit der XSS in ihren Produkten DOM-basiert war, was die Entwicklung von Trusted Types motivierte. Gegenmassnahmen: bevorzuge inerte Sinks wie textContent und setAttribute; bereinige mit DOMPurify oder der eingebauten Sanitizer-API; erzwinge Trusted Types plus eine strikte Content Security Policy; und setze Taint-Tracking-Werkzeuge ein, die während des Code-Reviews Datenflüsse von der Quelle zum Sink nachverfolgen.

flowchart LR
  A["Quelle<br/>location.hash / postMessage"] --> B[Clientseitiges JS<br/>liest Wert]
  B --> C{Sanitisiert?}
  C -->|"textContent / DOMPurify"| D[Sicher gerendert]
  C -->|"roher String an innerHTML,<br/>eval, document.write"| E[Sink führt Payload aus]
  E --> F[Angreifer-Skript läuft<br/>in der Sitzung des Opfers]
  F --> G[Cookie-Diebstahl, Konto-<br/>übernahme, Keylogging]
  E -.->|Trusted Types blockiert| H[TypeError, keine Ausführung]