Dipl.-Inform. Carsten Eilers

Allgemein wird mit Cross-Site Scripting (XSS) das Einschleusen von HTML- und JavaScript-Code in eine Webseite bezeichnet. Normalerweise gilt der Grundsatz "Von einer vertrauenswürdigen Webseite mitgelieferter JavaScript-Code ist vertrauenswürdig": Er darf die Seite ändern und vom eigenen Server Daten nachladen. Durch Cross-Site Scripting wird dieser Grundsatz verletzt, indem bösartiger JavaScript-Code eingeschleust wird. Dafür gibt es verschiedene Möglichkeiten:

Reflektiertes XSS

Der Schadcode wird vom Client an den Webserver gesendet und von diesem an den Browser des Clients zurückgegeben.
Für diesen Angriff ist der Aufruf eines präparierten URL oder das Absenden eines präparierten Formulars durch das Opfer nötig.

Persistentes XSS (auch JavaScript-Injection genannt)

Der Schadcode wird auf dem Webserver gespeichert, zum Beispiel in einem Kommentar oder einem Gästebuch-Eintrag, und danach bei jedem Aufruf der Seite mit dem betroffenen Eintrag ausgeliefert.
Der Angriff erfolgt bei jedem Aufruf der Seite mit dem eingeschleusten Schadcode. Wie der Benutzer diese Seite erreicht, ist egal.

DOM-basiertes oder lokales XSS

Der Schadcode wird durch eine Schwachstelle im clientseitigen JavaScript-Code eingeschleust, also über eine Funktion, die übergebene Daten ungeprüft ausgibt.
Für den Angriff ist wie beim reflektierten XSS der Aufruf eines präparierten URL durch das Opfer nötig.

Resident XSS

ist die neueste Art von XSS-Angriffen und schlägt hier etwas aus der Reihe: Der auf herkömmlichen Weg eingeschleuste XSS-Code wird zum Beispiel im Local Storage oder der SQL-Datenbank des Webbrowsers gespeichert und bleibt zusätzlich in einem versteckten iframe oder Tab aktiv.
Während beim herkömmlichen XSS der Schadcode mit dem Verlassen der betroffenen Seite beendet wird, bleibt er beim Resident XSS weiterhin aktiv.

Betrachten wir diese Angriffe (mit Ausnahme des Resident XSS, das bereits im verlinkten Eintrag beschrieben wurde) näher:

Reflektiertes XSS

Der Schadcode wird an den Webserver gesendet und von diesem an den Client zurückgegeben. Für den Angriff ist der Aufruf eines präparierten URL oder das Absenden eines präparierten Formulars durch das Opfer nötig.

Für seinen Angriff benötigt der Angreifer eine entsprechende Schwachstelle. Die besteht im Fall von Reflektierten XSS darin, dass die Webanwendung die Eingaben nicht ausreichend prüft, bevor sie sie als Bestandteil einer Webseite an den Benutzer zurückgibt.

Die einfachsten Fälle sind dabei die Fehlermeldung für eine nicht gefundene Datei mit dem HTTP-Fehlercode 404 und Suchergebnisse. Meist wird in der Fehlermeldung der Name der nicht gefundenen Datei ausgegeben, es erscheint eine Meldung nach dem Muster "404 - Datei [Dateiname] nicht gefunden". Wird der Dateiname nicht ausreichend geprüft, kann ein Angreifer darüber seinen Cross-Site-Scripting-Code einschleusen. Ähnlich sieht es bei der Ausgabe von Suchergebnissen aus, bei denen der gesuchte Begriff auf der Ergebnisseite ausgegeben wird. Wird der nicht ausreichend geprüft, kann darüber Cross-Site-Scripting-Code eingeschleust werden.

Als Beispiel soll im Folgenden eine Webmail-Anwendung dienen:

http://www.mailprovider.example/webmail/login.php?user=[User-ID]

Die Schwachstelle besteht darin, dass der Wert des Parameters user nicht ausreichend geprüft wird, bevor er auf der Login-Seite angezeigt wird. Der Angreifer stellt einen Link zusammen, der statt eines Benutzernamens XSS-Code enthält:

http://www.mailprovider.example/webmail/login.php?user=[XSS-Code]

Dann bringt er einen Benutzer dazu, diesen Link anzuklicken. Dazu kann er ihm den Link zum Beispiel per E-Mail zuschicken. Mit etwas Social Engineering ist es meist kein Problem, den Benutzer zum Anklicken des Links zu bringen.

Nach dem Klick auf den Link wird ein Request an die Webanwendung geschickt, der alle zugehörigen Parameter und ihrer Werte und damit unter anderem den XSS-Code enthält. Die Webanwendung fügt den Wert des Parameters user in die erzeugte Webseite ein und sendet das Ergebnis an den Benutzer.

Der eingeschleuste Code wird im Webbrowser des Benutzers im Kontext der betroffenen Webseite ausgeführt. Und genau darin besteht die Gefahr: Als Schutz vor den Auswirkungen schädlichen JavaScript-Codes verwenden die Webbrowser bekanntlich die Same-Origin Policy, die aufgrund der Herkunft des JavaScript-Codes über dessen Ausführung und Rechte entscheidet. JavaScript-Code darf nur auf die Teile der Webseite zugreifen, die von der gleichen Domain (= Origin) geladen wurden wie er selbst. Außerdem darf er mit wenigen Ausnahmen nur mit der Domain kommunizieren, von der er geladen wurde. Diese Schutzfunktionen werden durch den XSS-Angriff umgangen. Da der eingeschleuste JavaScript-Code anscheinend von der Webseite mailprovider.example stammt, wird er in deren Kontext ausgeführt und darf auf die davon geladenen Seitenbestandteile zugreifen.

Den Ablauf des Angriffs zeigt folgendes Bild:

Abb. 1: Reflektiertes XSS

Auf dieses Beispiel gehe ich später noch genauer ein. In der nächsten Folge geht es um das auch als JavaScript-Injection bezeichnete Persistente XSS.

Carsten Eilers

Übersicht über alle Artikel zum Thema

Cross-Site Scripting im Überblick, Teil 1: Reflektiertes XSS

Cross-Site Scripting im Überblick, Teil 2: Persistentes XSS

Cross-Site Scripting im Überblick, Teil 3: Der MySpace-Wurm Samy

Angriffe über Cross-Site Scripting: Der Sourcecode des MySpace-Wurms Samy

Cross-Site Scripting im Überblick, Teil 4: DOM-basiertes XSS

Cross-Site Scripting im Überblick, Teil 5: Resident XSS

XSS-Angriffe, Teil 1: Informationen einschleusen

XSS-Angriffe, Teil 2: Cookies und Tastendrücke ausspähen

XSS-Angriffe, Teil 3: Zugangsdaten ausspähen

XSS-Angriffe, Teil 4: Ein Blick in die History, und dann auf ins LAN!

XSS-Angriffe, Teil 5: Ein Portscan (nicht nur) im LAN

XSS-Angriffe, Teil 6: Ein verbesserter Portscanner

XSS-Angriffe, Teil 7: Hindernisse beim JavaScript-Portscan beseitigen

XSS-Angriffe, Teil 8: Ein Portscan mit WebSockets oder Cross-Origin Requests

XSS-Angriffe, Teil 9: Der Router im Visier

XSS-Angriffe, Teil 10: Weitere Angriffe auf den Router

XSS-Angriffe, Teil 11: Unerwünschtes Firmware-Update für den Router

XSS-Angriffe, Teil 12: Browser-basierte Botnets

XSS-Angriffe, Teil 13: Fortgeschrittene Angriffe

XSS-Angriffe, Teil 14: Das Browser Exploitation Framework BeEF