DOM-basierter XSS
Was ist DOM-basierter XSS?
DOM-basierter XSSXSS-Variante, bei der Injektion und Ausführung vollständig im Browser stattfinden, weil clientseitiges JavaScript ungeprüfte Daten in einen Sink schreibt.
DOM-basierter XSS (Typ 0) ist eine Cross-Site-Scripting-Schwachstelle, deren Ursache ausschließlich im clientseitigen Code liegt. Eine Datenquelle wie location.hash, document.referrer, window.name, postMessage oder localStorage wird ohne Sanitisierung an einen gefährlichen DOM-Sink (innerHTML, document.write, eval, jQuery.html) übergeben. Da der Server die Payload nie sieht, bleibt die Schwachstelle für klassische WAFs und Server-Logs unsichtbar. Schutz bieten sichere APIs wie textContent, Trusted Types in modernen Browsern, eine strikte Content Security Policy und Analysewerkzeuge, die Tainted-Data-Flows von Quellen zu Sinks verfolgen.
● Beispiele
- 01
document.getElementById('out').innerHTML = location.hash.substring(1);
- 02
Ein SPA-Router rendert window.location ungeprüft als HTML in einen Template-Slot.
● Häufige Fragen
Was ist DOM-basierter XSS?
XSS-Variante, bei der Injektion und Ausführung vollständig im Browser stattfinden, weil clientseitiges JavaScript ungeprüfte Daten in einen Sink schreibt. Es gehört zur Kategorie Angriffe und Bedrohungen der Cybersicherheit.
Was bedeutet DOM-basierter XSS?
XSS-Variante, bei der Injektion und Ausführung vollständig im Browser stattfinden, weil clientseitiges JavaScript ungeprüfte Daten in einen Sink schreibt.
Wie funktioniert DOM-basierter XSS?
DOM-basierter XSS (Typ 0) ist eine Cross-Site-Scripting-Schwachstelle, deren Ursache ausschließlich im clientseitigen Code liegt. Eine Datenquelle wie location.hash, document.referrer, window.name, postMessage oder localStorage wird ohne Sanitisierung an einen gefährlichen DOM-Sink (innerHTML, document.write, eval, jQuery.html) übergeben. Da der Server die Payload nie sieht, bleibt die Schwachstelle für klassische WAFs und Server-Logs unsichtbar. Schutz bieten sichere APIs wie textContent, Trusted Types in modernen Browsern, eine strikte Content Security Policy und Analysewerkzeuge, die Tainted-Data-Flows von Quellen zu Sinks verfolgen.
Wie schützt man sich gegen DOM-basierter XSS?
Schutzmaßnahmen gegen DOM-basierter XSS kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.
Welche anderen Bezeichnungen gibt es für DOM-basierter XSS?
Übliche alternative Bezeichnungen: Typ-0-XSS, Clientseitiges XSS.
● Verwandte Begriffe
- attacks№ 240
Cross-Site-Scripting (XSS)
Web-Schwachstelle, mit der Angreifer bösartige Skripte in Seiten injizieren, die andere Nutzer öffnen, sodass der Code im Browser des Opfers unter der Origin der Seite ausgeführt wird.
- attacks№ 1107
Stored XSS
Persistente Cross-Site-Scripting-Schwachstelle: vom Angreifer eingeschleuster Code wird serverseitig gespeichert und im Browser jedes Besuchers ausgeführt.
- attacks№ 912
Reflected XSS
Nicht-persistente XSS-Variante, bei der angreifergesteuerte Eingaben unmittelbar in der Antwort gespiegelt und im Browser des Opfers ausgeführt werden.
- appsec№ 214
Content Security Policy (CSP)
HTTP-Antwort-Header, der dem Browser mitteilt, welche Quellen für Skripte, Styles, Frames und andere Inhalte erlaubt sind, und so XSS- und Datendiebstahlangriffe begrenzt.
- vulnerabilities№ 869
Prototype Pollution
JavaScript-Schwachstelle, bei der nicht vertrauenswürdiger Input Object.prototype verändert, jedem Objekt Eigenschaften aufzwingt und so Verhalten ändert oder bis zu RCE führt.
- appsec№ 773
Ausgabeencodierung
Umwandlung unvertrauenswürdiger Daten in eine für einen bestimmten Ausgabekontext (HTML, JavaScript, URL, SQL, Shell) sichere Form, sodass sie nicht ausbrechen und als Code ausgeführt werden.
● Siehe auch
- № 104Blind XSS