Reflected XSS.

Reflected XSS (auch nicht-persistent oder Typ-1) tritt auf, wenn eine Webanwendung Daten aus einer HTTP-Anfrage — meist Query-Parameter oder Formularfelder — ohne saubere Ausgabecodierung in die Antwort zurückschreibt. Da das Opfer einen präparierten Link anklicken muss, erfolgt die Auslieferung typischerweise über Phishing, Malvertising oder Messenger. Erfolgreiche Ausnutzung erlaubt das Stehlen von Session-Cookies, das Ausführen von Aktionen im Namen des Nutzers oder die Eskalation zur vollständigen Kontoübernahme. Schutz bieten kontextabhängiges HTML-Encoding, eine strikte Content Security Policy und Frameworks mit automatischer Template-Escaping.

Anatomie eines Reflected-XSS-Angriffs

flowchart LR
  A[Angreifer baut Link mit Skript in einem Parameter] --> B[Verteilung via Phishing / Werbung / Chat]
  B --> C[Opfer klickt den Link]
  C --> D[App spiegelt Eingabe ohne Encoding]
  D --> E[Browser fuehrt Skript in der Session aus]
  E --> F[Cookie-Diebstahl / Aktionen als Nutzer / Kontouebernahme]

Warum das Payload für seinen Kontext codiert werden muss

Der entscheidende Feinheit von XSS: „Encoding" ist kontextspezifisch — derselbe Wert ist an einer Stelle sicher und an einer anderen gefährlich. Daten in HTML-Text brauchen HTML-Entity-Encoding; in einem Attribut Attribut-Encoding und Anführungszeichen; in einem <script>-Block oder Event-Handler JavaScript-String-Encoding; und in einer URL URL-Encoding. Ein einzelner, blind angewandter Encoding-Schritt übersieht Fälle, in denen derselbe Parameter in mehreren Kontexten gespiegelt wird. Template-Engines, die standardmäßig escapen (JSX von React, Angular oder serverseitiges Templating mit kontextbezogenem Escaping), eliminieren die meisten Reflected-XSS-Fälle, sofern Entwickler Schlupflöcher wie dangerouslySetInnerHTML oder innerHTML meiden.

Browserseitige Filter sind keine Verteidigung mehr. Google entfernte den XSS Auditor in Chrome 78 (Oktober 2019), weil er leicht umgehbar war, Fehlalarme erzeugte und selbst missbraucht werden konnte, um legitime Skripte gezielt zu deaktivieren; der von ihm beachtete X-XSS-Protection-Header ist heute faktisch tot. Die belastbaren Kontrollen sind kontextbezogenes Output-Encoding, eine strikte Content Security Policy (idealerweise nonce- oder hash-basiert), HttpOnly-Cookies, damit ein gestohlenes Skript die Session nicht auslesen kann, und Eingabevalidierung als Defense-in-Depth statt als primäre Barriere.