Modernes XSS: DOM, Stored und Reflected mit Beispielen aus dem Testlabor

Der HackerOne-Report 2025 fuehrte XSS als zweithaeufigsten gemeldeten Bug in oeffentlichen Bug Bountys, mit einem Median von 750 USD pro Fund und Spitzen um 20.000 USD bei Enterprise-Zielen. Die Bug-Klasse stirbt nicht, weil Browser sich weiterentwickeln, waehrend Frontend-Pipelines weiter Strings in innerHTML kleben. Das Basilisk-Team baut ein Labor mit drei absichtlich loechrigen Apps auf, faengt jeden Request in Burp Suite Community 2026.4 ab und zeigt jeden Vektor mit Payload, Kontext und Patch. Bevor du irgendetwas kopierst, stelle sicher, dass dein Lab isoliert ist wie in Web-Pentest von Null: Ein Sicheres Lab mit DVWA, Juice Shop und Burp Suite Bauen beschrieben, denn Skripte ohne schriftliche Beauftragung auf Dritte zu feuern bleibt in Deutschland nach Paragraph 202c StGB strafbar.

Reflected XSS taucht auf, wenn Benutzereingabe ohne saubere Kodierung in der HTTP-Antwort landet, typisch ueber Querystring oder GET-Formular. In unserem Lab klebt eine Suche auf /search?q= den Begriff in ein

, weshalb das klassische

Stored XSS ist die gefaehrlichste Spielart, weil sie in der Datenbank festsitzt und jeden kuenftigen Besucher trifft. In DVWA stellen wir Stufe medium ein, schicken im Kommentarfeld den Payload und sehen das Webhook in Sekunden Moderator-Sessions sammeln. Die reale Angriffsflaeche umfasst Markdown-Renderer, transaktionale E-Mail-Templates, CSV-Exporte, die in Excel oeffnen, sogar EXIF-Metadaten in internen Dashboards, wie in Metadaten-Hygiene: EXIF, PDF und Office vor der Veroffentlichung saubern erlaeutert. Robuste Verteidigung kombiniert Input-Sanitisierung mit Output-Escaping; eines ohne das andere ist Theater.

DOM-based XSS passiert komplett im Browser, der Payload erreicht nie das Server-Log. Der Klassiker location.hash in document.write steckt weiter in Legacy-Chat-Widgets und in React-Apps, die Hash-Daten an dangerouslySetInnerHTML weiterreichen. Wir adaptieren Level 1 des Google XSS Game im Lab und demonstrieren Sink-Hunting durch DevTools, aktiviertes 'Pause on exceptions' und die DOM-Invader-Erweiterung aus Burp. Der Triage-Flow folgt derselben Methodik wie SQL Injection in der Praxis: Ausnutzen, Erkennen und Mitigieren im Kontrollierten Lab: Source identifizieren, bis zum Sink verfolgen, mit minimalem Payload validieren, dann eskalieren.

Moderne Mitigation hat aufgehoert, ueber Filter fuer spitze Klammern zu reden. Content Security Policy Level 3 mit Nonce pro Request blockiert Inline-Injection sogar, wenn der Angreifer HTML auf die Seite zwingt, sofern du nicht in die Falle gehst und 'unsafe-inline' als Fallback ergaenzt. Trusted Types, in Chromium seit 83 und endlich in Firefox 135 unterstuetzt, verwandelt innerHTML-Zuweisungen in TypeErrors, ausser sie laufen durch eine registrierte Policy. Kombiniert mit DOMPurify 3.2 fuer reiches HTML misst Google rund 90% weniger Angriffsflaeche. Verdrahte das in die CI nach AppSec Shift-Left: SAST, SCA und Secrets Scanning ohne das Team auszubremsen, indem du Semgrep mit der Regel javascript.lang.security.audit.xss auf jedem PR laufen laesst.

Praktisches Takeaway: stell heute das Labor mit DVWA, Juice Shop und einer abgespeckten Next.js-App auf, reproduziere alle drei Vektoren bis je ein Popup feuert, schraube dann Nonce-CSP, Trusted Types und DOMPurify dazu und spiele exakt dieselben Payloads erneut ab. Was noch zuendet, verdient eine Policy-Anpassung, bis es bricht. Pflege jede Iteration in einem persoenlichen Runbook, denn gute XSS-Reports bei HackerOne, Intigriti oder im Shopify-Programm verlangen Ein-Satz-Reproduktion, belegten Impact und Patch-Vorschlag. Lies zusaetzlich STRIDE Threat Modeling im Sprint: Vollstaendiges Beispiel an einem Microservice, um jede Injection vor dem Ticket den Buckets Tampering und Elevation zuzuordnen, allein dieser Reflex hebt das Triage spuerbar auf P1.