CSS / XSS – Angriff (Cross Site Scripting) – eine Analyse

Den vollständigen 1. Teil des Dokumentes unter Creative Common-Lizenz als PDF-Datei herunterladen:

• Analyse und Maßnahmen gegen Sicherheitsschwachstellen bei der Implementierung von Webanwendungen in PHP/MySQL (Teil 1)

Cross Site Scripting beschreibt das Ausführen von Skriptbefehlen über unterschiedliche Webseiten hinweg. Praktisch bedeutet es, dass innerhalb einer Webseite ein Scriptcode ausgeführt wird, der von dem Nutzer willentlich oder unwillentlich eingefügt wurde. Dieser Angriff macht sich die Mächtigkeit, die Verbreitung und die Plattformunabhängigkeit von Skriptsprachen zu Nutze, die in den meisten Webbrowser implementiert sind. Hier soll besonders „JavaScript“ betrachtet werden, da diese Programmiersprache unter den clientseitigen Skriptsprachen die größte Verbreitung hat.

JavaScript ermöglicht unter Anderem:

• das Ändern der gesamten Seitenstruktur,
• das Einbinden zusätzlichen JavaScript-Codes,
• das Erzeugen beliebiger HTML-Elemente,
• das Umleiten von Formularen und Links,
• das Auslesen von Authentifizierungs-Daten,
• das Senden und Empfangen von Daten und
• das Auslesen der Tastenanschläge.

1.1.1 Gefahreneinschätzung

XSS-Angriffe werden meist als Pseudo-Angriff verstanden, da erläuternde Beispiele die Angriffsszenarien nicht in ihrer Vollständigkeit ausführen, sondern bereits bei dem Aufruf der kompromittierten Seite aufhören. Meist wird zur Demonstration eine Meldung wie „Sie sind verwundbar!“ ausgegeben. Hier vermuten viele Entwickler einen „Defacement“¹ -Angriff, noch dazu einen ziemlich plumpen [Sch07a]. Die nicht ernst genommene Bedrohung gewinnt an Potential, besonders dann, wenn nicht einmal professionelle und gefährdete Webseiten dagegen aufrüsten [Sch07b]. XSS-Angriffe lassen sich auf unterschiedliche Art durchführen, was ein aufwändiges Absichern erfordert. Ist der Angriff vorbereitet, so erkennt der Nutzer nicht einmal, dass ein zusätzlicher JavaScript-Schadcode im Hintergrund läuft.

XSS-Angriffe basieren konzeptuell auf „Social Engineered“-Angriffe. Diese beschreiben die Rolle des Menschen als Schwachstelle in einem Sicherheitskonzept. Dabei wird auf seine sozialen Kompetenzen (Vertrauen, Zuneigung, Zusammengehörigkeit, usw.) gezielt, die von einem Angreifer ausgenutzt werden.

1.1.2 Angriffsszenarien / Angriffsvektoren

Der eingeschleuste Code erzeugt hauptsächlich zwei Angriffsszenarien:

• das Defacement (Umgestaltung) der Seite oder
• den Diebstahl des Authentifizierungs-Cookies.²

Damit jedoch ein fremder Script-Code ausgeführt wird, muss dieser in die Seite gelangen. Daher muss er in die Logik der Webanwendung eingefügt werden, um dann von der Anwendung selbst wieder an den Nutzer ausgegeben zu werden. Um eine solche Lücke zu finden, braucht der Angreifer lediglich systematisch alle Ausgaben der Anwendung mit JavaScript-Code zu belegen, beispielsweise indem er in die dazugehörigen Eingaben seinen Testcode einfügt. Solche Schwachstellen finden sich unter anderen bei Formulareingaben auf Webseiten. Nach dem Ausfüllen der Eingabefelder durch den Nutzer, werden die Inhalte an den Server gesendet. Stellt die serverseitige Anwendung einen Eingabefehler fest (beispielsweise: Pflichtfeld nicht ausgefüllt) oder soll eine Überprüfung der Eingaben stattfinden, so wird in manchen Fällen das Formular erneut im Webbrowser des Nutzers angezeigt. Dabei werden für die Nutzerfreundlichkeit alle Felder mit den bereits eingegebene Daten wieder befüllt. In beiden Fällen kann Schadcode auf einfacher Weise eingefügt werden, wenn nicht zusätzliche Maßnahmen getroffen wurden.

Möglichkeiten des Einfügens von Schadcode finden sich in:

• Formulareingaben,
• URL-Parametern und
• Cookie-Werten.

Um den Schadcode in die Seite einzuschleusen, braucht der Angreifer – je nach Angriffsart – mindestens ein Mal die Mithilfe eines Nutzers. Dabei muss er diesen täuschen, damit dieser eine präparierte Webseite oder einen präparierten Link nutzt. Wie der Angriff anschließend ausgeführt wird, hängt vom Ziel des Angriffs sowie von den Sicherheitsmaßnahmen der Zielseite ab.

Beispielhaft soll ein typischer XSS-Schadcode analysiert werden, der zum Entwenden von Cookies vom Browser des Nutzers dient. Cookies werden oft als Zugangsschlüssel für geschützte Bereiche einer Webseite verwendet und sind dadurch besonders interessant. Bei einem Angriff werden die Inhalte des Cookies ausgelesen und meist an einen vorbereiteten Server über das Internet geschickt, der diese speichert.

Abbildung 1: Schadcode zum Stehlen von Cookies

Der präparierte Code wird innerhalb einer verwundbaren Stelle in der Zielseite injiziert, indem er beispielsweise innerhalb eines Links den Platz eines regulären Parameters einnimmt oder aber hinzugefügt wird. Beispielhaft wird eine Seite betrachtet, die als Parameter eines Links den Namen des Nutzers trägt und diesen dann anzeigt:

Abbildung 2: Link-Parameter wird in die Seite eingefügt

Die Seite bindet den übergebenen Wert ein:

Der Angreifer findet zuvor diese Lücke und versucht, Internetnutzer über seinen präparierten Link, auf die anfällige Seite zu locken.

Abbildung 3: Präparierter Aufruf zum Entwenden des Cookie

Verwendet ein Nutzer diesen Link, so wird der beinhaltete Code in die Seite an Stelle des Namens eingefügt und sofort ausgeführt. Der Angreifer erzeugt in diesem Beispiel ein neues Element in der Webseite. Es ist ein IMG-Tag, welcher eigentlich für die Darstellung von Bildern innerhalb eines HTML-Dokumentes verwendet wird. Diesmal wird jedoch kein Bild geladen, sondern ein Skript (cookie.php) auf einem fremden Server (SERVER.de) aufgerufen. Dabei sendet der Browser eine Anforderung an das fremde Skript und zwar mit den Cookie-Daten des Nutzers als Parameter (document.cookie).

Um den auffälligen Anhang in der URL zu maskieren, kann sich der Angreifer einiger Techniken bedienen:

• Weiterleitungs-Dienste. (tinyurl.com) [Tin],
• Hexadezimal- oder Unicode-Kodierung.

Weiterleitungs-Dienste sind zahlreich und kostenlos verfügbar und ursprünglich dazu gedacht, lange Webseiten-Links in Kurzform zu speichern und somit leichter verwendbar zu machen. Der hier genannte Dienst „tinyurl.com“ erzeugt ein Kürzel als Kennung für lange Links und leitet automatisch den Webbrowser dorthin um. Dabei ist dem Nutzer des Links nicht ersichtlich³, welche Webseite das Ziel der Umleitung ist und welche Parameter dorthin transportiert werden.

Abbildung 4: Unsichtbarer Schadcode über Weiterleitung mit tinyurl.com

Durch eine hexadezimale Kodierung des Angriffcodes wird dieser für Menschen unverständlich und bleibt so unerkannt. Im Webbrowser erfolgt eine Dekodierung, sodass er wieder ausführbar wird.

Abbildung 5: Schadcode hexadezimal codiert

1.1.3 Angriffsformen

Es können drei XSS-Angriffstypen unterschieden werden. Der „semi-persistente“-Angriff wurde nach Kenntnis des Autors erstmalig im Rahmen dieser Arbeit kategorisiert:

• nicht persistent,
• persistent und
• semi-persistent.

Nicht-Persistent

Nicht persistente Angriffe wirken sich nur auf den Nutzer aus, der sie durch das Verwenden eines präparierten Aufrufs zur Ausführung bringt. Dazu muss der jeweilige Nutzer durch Täuschung an die präparierte XSS-Lücke geführt werden. Diese Art des Angriffs wird daher oft bei Nutzern probiert, die erweiterte Rechte besitzen (Administratoren).

Abbildung 6: Nicht-Persistenter XSS-Angriff. Quelle: eigene Darstellung

1. Der Nutzer kommt in Kontakt mit einem präparierten Link, Formular oder einer präparierten Umleitung.
2. Die Webanwendung der Bank wird über den präparierten Aufruf angefordert.
3. Der XSS-Code wird über eine XSS-Lücke der Bankanwendung, in die Seite eingefügt.
4. Die mit XSS-Code infizierte Seite wird dem Nutzer gesendet.
5. Der XSS-Code ist im Kontext der Seite beim Nutzer angekommen und umgeht so die „Same-Origin“-Sicherheitseinstellung⁴ des Webbrowsers.
6. XSS-Code sendet gestohlene Daten an den Server des Angreifers.

Persistent

Um einen persistenten Schadcode einzufügen, braucht der Angreifer meist nicht die Hilfe eines Nutzers. Er kann vielmehr selbst den präparierten Code innerhalb der Anwendung speichern, sodass dieser beliebige Zeit später von einem Nutzer aktiviert wird. Der Schadcode wird dazu beispielsweise als Eintrag in ein Gästebuch auf dem Server abgelegt. Dazu reicht es in ungeschützten Anwendungen aus, wenn der injizierte Code anstatt des Gästebuchtextes eingegeben wird. Ein persistenter Angriff verbleibt in der kompromittierten Anwendung und ist für jeden Nutzer potentiell gefährlich. Es gibt bei dieser Art des Angriffs kaum Schutz auf der Nutzerseite, da der Schadcode sofort beim Betrachten der Seite ausgeführt wird.

Abbildung 7: Persistenter XSS-Angriff. Quelle: eigene Darstellung

1. Die Webanwendung der Bank wird mit dem XSS-Code aufgerufen.
2. Der Schadcode gelangt über eine XSS-Lücke in die Anwendung hinein und wird dort gespeichert.
3. Ein Nutzer ruft die Webanwendung der Bank auf.
4. Der Schadcode wird aus dem Speicher in die Webseite eingebaut.
5. Die infizierte Webseite wird dem Nutzer geschickt.
6. Der XSS-Code ist im Kontext der Seite beim Nutzer angekommen und umgeht so die „Same-Origin“-Sicherheitseinstellung des Webbrowsers.
7. Der XSS-Code sendet gestohlene Daten an den Server des Angreifers.

Semi-Persistent

Der Angreifer schleust hierbei den Code in die Werte des von der Webseite gesetzten Cookies ein. Dieser wird von der Seite bei jedem Besuch des infizierten Browsers gelesen und ohne Prüfung in den Anwendungscode einbezogen. Der Angriff betrifft also den Nutzer des infizierten Browsers, nur solange die Lebenszeit des Cookies währt. Ein Semi-Persistenter Angriff kann zu einem persistenten werden , wenn die Cookiewerte in die Datenbank abgelegt werden und andere Nutzer Zugang zu diesen haben.

Abbildung 8: Semi-Persistenter XSS-Angriff. Quelle: eigene Darstellung

1. Der Nutzer kommt in Kontakt mit einem präparierten Link, Formular oder einer präparierten Umleitung.
2. Die Webanwendung der Bank wird über den präparierten Aufruf angefordert.
3. Der XSS-Code wird über eine XSS-Lücke der Bankanwendung, in das Cookie eingefügt.
4. Das Cookie mit dem Schadcode wird dem Nutzer gesendet und bei ihm gespeichert.
5. Bei einem späteren Besuch enthält der Browser des Nutzers den infizierten Cookie.
6. Der Nutzer ruft die Webanwendung der Bank auf.
7. Der Schadcode wird aus dem Cookie in die Webseite eingebaut.
8. Die infizierte Webseite wird dem Nutzer geschickt.
9. Der XSS-Code ist im Kontext der Seite beim Nutzer angekommen und umgeht so die „Same-Origin“-Sicherheitseinstellung des Webbrowsers.
10. Der XSS-Code sendet gestohlene Daten an den Server des Angreifers.

1. Defacement: (engl. für „Entstellung oder Verunstaltung“) bezeichnet in der EDV das unberechtigte Verändern einer Website. [Wikg]
2. Ein Cookie ist eine reine Textdatei, in der der Webbrowser Zeichenketten zwischenspeichern kann. Diese Zeichenketten stellt die Webanwendung zur Verfügung und fragt sie später wieder ab. Ein Authentifizierungs-Cookie enthält meist einen Schlüsselcode, der dem Nutzer zugeordnet wurde und ihn bei einem späten Besuch wiedererkennbar macht. [Wikh]
3. „tinyurl.com“ bietet die Option einer Vorschau des sonst verborgenen Links an. Diese muss aber entweder explizit beim Anlegen des Kürzels angegeben werden (was ein Angreifer sicher nicht tun wird) oder für jeden Nutzer einzeln eingeschaltet werden.
4. „Same-Origin“-Policy erlaubt aus Sicherheitsgründen keinen Datenaustausch zwischen Webseiten unterschiedlicher Domains. [Sun]

Literaturverzeichnis

Diese Arbeit wird im Rahmen der „Creative Commons“-Lizenz zur Verfügung gestellt.
Sie dürfen:

• das Werk vervielfältigen, verbreiten und öffentlich zugänglich machen
• Bearbeitungen des Werkes anfertigen

Zu den folgenden Bedingungen:

• Namensnennung. Sie müssen den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen (wodurch aber nicht der Eindruck entstehen darf, Sie oder die Nutzung des Werkes durch Sie würden entlohnt).
• Keine kommerzielle Nutzung. Dieses Werk darf nicht für kommerzielle Zwecke verwendet werden.

Vollständiger Lizenztext: http://creativecommons.org/licenses/by-nc/3.0/deed.de