Was ist Cross-Site-Scripting?
Cross-Site-Scripting (kurz: XSS) ist eine Angriffstechnik, bei der ein Angreifer bösartigen JavaScript-Code in eine Website einschleust. Wenn andere Nutzer diese Seite aufrufen, wird der Schadcode in ihrem Browser ausgeführt – ohne dass sie davon wissen. Das Gefährliche: Der Code läuft im Kontext der legitimen Website und hat damit Zugriff auf alles, was der Browser dieser Website erlaubt.
XSS unterscheidet sich grundlegend von SQL-Injection: Während SQLi die Datenbank des Servers angreift, richtet XSS sich gegen den Browser des Besuchers.
Die drei XSS-Typen
Reflected XSS (nicht-persistent): Der Schadcode wird über einen manipulierten Link an die Website übergeben und sofort im Browser des Nutzers ausgeführt. Der Code wird nicht gespeichert. Typisches Szenario: Eine Phishing-E-Mail enthält einen Link zu einer legitimen Website, in dessen URL ein XSS-Payload eingebettet ist.
Stored XSS (persistent): Der Schadcode wird dauerhaft in der Datenbank gespeichert – z.B. über einen Kommentar, ein Profil oder ein Formularfeld. Jeder Besucher, der die Seite aufruft, die diesen Inhalt anzeigt, ist betroffen. Diese Variante ist besonders gefährlich, weil sie kein aktives Zutun des Opfers erfordert.
DOM-based XSS: Der Schadcode manipuliert direkt das Document Object Model (DOM) im Browser, ohne den Server zu involvieren. Für Scanner besonders schwer zu erkennen.
Wie werden WordPress-Websites durch XSS angegriffen?
Einfallstore sind überall dort, wo Nutzereingaben unzureichend bereinigt werden:
- Kommentarfelder (wenn die Bereinigung im Plugin fehlt)
- Kontaktformulare
- Suchfelder
- Nutzerprofile (z.B. Anzeigename, Biografie)
- WordPress-Shortcodes in Plugins
Wenn ein Plugin Nutzereingaben direkt in die Ausgabe übergibt, ohne schädliche Zeichen zu escapen, kann Schadcode eingeschleust werden. Dies ist in der CVE-Datenbank unter dem Typ „Stored XSS" oder „Reflected XSS" dokumentiert.
Was können Angreifer mit XSS erreichen?
- Session-Cookie-Diebstahl: Der Angreifer erhält die Session des eingeloggten Nutzers und kann sich als dieser ausgeben – ohne das Passwort zu kennen
- Keylogging: Alle Tastatureingaben eines Nutzers auf der Seite werden mitgeschnitten
- Weiterleitung: Besucher werden auf externe Phishing-Seiten weitergeleitet
- Formular-Manipulation: Eingaben in Formulare werden abgegriffen oder umgeleitet
- Admin-Übernahme: Wenn ein eingeloggter Admin die Seite mit XSS-Payload aufruft, kann der Angreifer Admin-Aktionen auslösen
Schutzmaßnahmen
Plugins aktuell halten: XSS-Schwachstellen in Plugins werden regelmäßig entdeckt und durch Updates geschlossen. → WordPress Sicherheitslücken
Web Application Firewall (WAF): Eine WAF erkennt typische XSS-Muster und blockiert entsprechende Anfragen automatisch.
Content Security Policy (CSP): Ein HTTP-Response-Header, der festlegt, welche Skriptquellen ein Browser auf einer Seite ausführen darf. Gut konfiguriert, verhindert CSP die Ausführung eingeschleusten Codes.
Kommentare moderieren: Wenn Kommentare auf der Website erlaubt sind, sollten sie erst nach manueller Freigabe erscheinen.
Fazit
XSS ist nach SQL-Injection eine der häufigsten Schwachstellen in Webanwendungen und dauerhaft in der OWASP Top 10 vertreten. Für WordPress-Betreiber gilt dasselbe Prinzip wie bei allen anderen Angriffsvektoren: aktuelle Plugins sind der wichtigste Schutz – ergänzt durch eine WAF als zusätzliche Sicherheitsschicht.
