Skip to content

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

Nachdem es in der vorherigen Folge um die Universal XSS Schwachstelle im IE ging möchte ich ab dieser Folge ein paar mögliche Angriffe über Cross-Site Scripting vorstellen. Bevor es zu den eigentlichen Angriffen kommt sollen aber erst einmal die verschiedenen Arten von XSS-Angriffen vorgestellt werden. Denn je nachdem, wie der Schadcode eingeschleust wird, sind unterschiedliche Angriffe möglich.

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:

Reflektiertes XSS
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

Trackbacks

Dipl.-Inform. Carsten Eilers am : Drucksache: windows.developer Magazin 6.2015 - Angriffsziel TFS

Vorschau anzeigen
Im windows.developer 6.15 ist ein Artikel über die Sicherheit des Team Foundation Servers erschienen. Der Team Foundation Server ist als Plattform für die kollaborative Softwareentwicklung theoretisch aus mehreren Richtungen gef&auml

Dipl.-Inform. Carsten Eilers am : Drucksache: Windows Developer 9.15 - Achtung, AngularJS

Vorschau anzeigen
Im windows.developer 9.15 ist ein Artikel zur Sicherheit von AngularJS erschienen. AngularJS? Das ist doch nur JavaScript, völlig harmlos! Was kann da schon groß passieren? Viel, wenn man nicht aufpasst. Und die Cyberkr

entwickler.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #1: Unsichere Weboberflächen, Teil 5

Vorschau anzeigen
Die Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT geht weiter. In der Liste der Top IoT Vulnerabilities von OWASP sind wir immer noch bei Platz 1, dem "Insecure Web Interface". Aber wenigstens sind wir beim zweiten