Cross Site Scripting

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg

Dieser Artikel erfüllt die GlossarWiki-Qualitätsanforderungen nur teilweise:

Korrektheit: 2
(teilweise überprüft) 		Umfang: 4
(unwichtige Fakten fehlen) 		Quellenangaben: 5
(vollständig vorhanden) 		Quellenarten: 5
(ausgezeichnet) 		Konformität: 4
(sehr gut)

Definition

Cross-Site Scripting (XSS) nutzt eine Sicherheitslücke in der angegriffenen Anwendung aus und kann dazu verwendet werden, Daten einer Originalseite zu verändern und zählt damit zu den aktiven Angriffen.
Beim XSS werden Informationen durch einen Angreifer in eine vermeintlich sichere Seite eingebettet.

Bemerkungen

XSS ist eine der am häufigsten verbreiteten Methoden, Angriffe auf ungeschützte Webseiten auszuführen und wird in der Verwendung nur noch vom Bufferoverflow, bei dem Teile des Speichers überschrieben werden um den Programmablauf zu verändern, übertroffen.

Es ist zum Teil für den Angreifer möglich, sensitive Daten von Benutzern der veränderten Webseite zu stehlen, wie z.B. Bankdaten, Zugangsdaten oder persönliche und finanzielle Informationen.

Durch XSS können auch Fehlinformationen verbreitet und Nutzer überwacht werden.

XSS kann auch als Grundlage für weiterführende Angriffe dieneen, z. B. indem ein Angreifer in eine Webseite, die für mehrere Tausend Besucher täglich ausgelegt ist, Code injiziert. Dieser Code könnte einen Download großer Dateien vom Server eines Opfers veranlassen. Da das bei mehreren Tausend Benutzern passiert wird damit also eine Denial of Service (DoS) Attacke) auslöst, was genügen sollte, um den angegriffenen Server unerreichbar zu machen.

Reflektiertes XSS

Das reflektierte – oder auch serverseitige – XSS ist der häufigste Vertreter von XSS-Angriffen und wird im Phishingmarkt angewendet. Hierbei muss ein Opfer eine präparierte URL anklicken. In Variablen und Parametern dieser URL wird Code eingefügt, den die Anwendung auf dem Server übernimmt und in die Webseite einbettet. Das kann ein Suchausdruck, ein Username oder auch eine E-Mail Adresse sein.

Der Angriff läuft folgendermaßen ab: die vom Angreifer veränderte URL wird durch ein Opfer angeklickt und somit an den betroffenen Server als Anfrage verschickt. Hier ist die Web-Applikation fehlerhaft und ermöglicht es dem Angreifer, den dynamisch generierten HTML-Code zu verändern. Der Benutzer sieht nun die manipulierte Seite in seinem Browser.

Persistentes (beständiges) XSS

Auch das persistente XSS ist serverseiteig, d.h. die Veränderungen werden auf dem Server vorgenommen und der Schadcode wird über die URL an den Browser zurück geschickt, hier wird allerdings der Inhalt der Datenbank ebenfalls verändert. Deswegen kann dieser Schadcode auch Benutzer erreichen die die manipulierte URL nicht angeklickt haben. Um die Attacke zu starten, reicht es hier völlig, wenn der Angreifer selbst den manipulierten Link anklickt.

Dieser Angriff wird zwar ähnlich dem reflektierenden XSS ausgelöst, verläuft aber etwas anders. Wie schon beschrieben, ruft der Angreifer eine manipulierte URL auf und sendet somit eine Anfrage an den Server. Die fehlerhafte Web-Applikation verarbeitet die Anfrage und speichert den injizierten Code in der Datenbank. Von nun an wird jeder Besucher dieser Seite den veränderten HTML-Code vorfinden.

Lokales (DOM-basiertes) XSS

Wie der Name schon vermuten lässt, ist das lokale XSS clientseitig, d.h. der komplette Angriff findet auf dem Rechner des Opfers statt. Dieser Angriff findet häufig bei Web 2.0 Anwendungen statt, da hier der Java oder Java-Script Code im Browser des Benutzers ausgeführt wird.

Da der Angriff im Browser des Benutzers stattfindet, wird auch der schädliche Code in der Sprache des Browsers gehalten und wird als Parameter an die Webseite übergeben. Falls dieser Code in der Webseite wieder enthalten ist, kann es passieren, dass der Browser des Benutzers diesen Code ausführt und evtl. Daten in ein Formular der generierten Seite einträgt, die anschließend an den Angreifer weitergeleitet werden.

Besonders gefährlich wird dieser Angriff, wenn die manipulierte Seite besondere Rechte im Browser besitzt. Je nach verwendeter Skriptsprache könnte die manipulierte Anwendung Cookies mit Anmeldeinformationen stehlen oder mit den Rechten des lokalen Benutzers Daten auf dem Rechner verändern. Dies könnte sich besonders bei Windows-Systemen als fatal erweisen, da der lokale Benutzer oft gleichzeitig der Administrator ist.

Ein Angriff würde wie folgt ablaufen: der Benutzer klickt wieder eine manipulierte URL an und schickt damit eine Anfrage an die Web-Applikation. Diese antwortet, indem der Skriptcode (der fehlerhaft, jedoch nicht manipuliert ist) an den Browser übergeben wird, um dort die Ausführung des Skripts zu starten. Die manpulierten Parameter aus der URL werden nun im Browser des Benutzers als Teil des Skripts interpretiert und ausgeführt. Über DOM-Zugriffe wird die im Browser dargestellte Webseite verändert, der Benutzer sieht nun die manipulierte Seite.

XSS – Eine kleine „Anleitung“

Zunächst müssen potentielle Opfer gefunden werden, d. h., es muss nach Anzeichen für die Angreifbarkeit einer Seite gesucht werden. Das ist bei Anwendungen der Fall, die die vom Benutzer vorgenommenen Eingaben wieder ausgeben – ob es ein Suchstring ist oder ein Foreneintrag ist, spielt dabei keine Rolle. Auch das Einbetten des vom Benutzer vorgenommenen Textes in Fehlermeldungen kann ein Anzeichen für die Anfälligkeit auf XSS sein.

Dafür werden die Bereiche auf Seiten gesucht, die Eingaben durch Benutzer zulassen, wie z.B. Login-Fenster, Suchfelder und Ähnliches. Foreneinträge und Message Boards sind dafür prädestiniert, da die Eingabe durch Nutzer auf jeden Fall wieder angezeigt wird. jedoch gilt hier immer noch zu prüfen, ob eine Anfälligkeit auf XSS vorhanden ist.

Sobald ein potentiell betroffenes Feld gefunden wurde, trägt man einen beliebigen String in dieses Feld ein, z. B. test. Nach einer Bestätigung, wird die Übertragung zum Server gestartet und in der Antwort des Servers wird der vorher eingegebene String gesucht. Der gesuchte String könnte z. B. in Form einer Fehlermeldung wie „Invalid login ’test’“ wieder auftauchen. Falls der Teststring ausgegeben wurde, kann getestet werden, ob die Seite gegen XSS geschützt ist.

Dazu wird in dasselbe Feld JavaScript Code eingetragen, wie z.B. <script>alert(’hello’)</script> und an den Server übermittelt. Falls nun ein Pop-up-Fenster aufgeht, in dem „hello“ zu sehen ist, ist die untersuchte Seite eindeutig von XSS betroffen.

Auch wenn kein Fenster aufgeht, kann es sein, dass der neu generierte HTML-Code den eingetragenen String enthält und dieser nur nicht vom verwendeten Browser ausgeführt wurde, da beispielsweise JavaScript deaktiviert ist. Um also sicher ausschließen zu können, dass die Seite diesem kleinen „Anschlag“ widerstanden hat, sollte der generierte HTML-Code untersucht und geprüft werden, ob der eingetragene String (<script>alert(’hello’)</script>) im HTML-Code der Seite auftaucht oder nicht.

Gegenmaßnahmen

Viele Programmiersprachen bringen von Haus aus Sicherheitsoptionen mit sich, die auch eingesetzt werden sollten, wie z. B. die Möglichkeiten, die PHP mitbringt, um Zugriffe von außen zu vermeiden. Da PHP eine der Skriptsprachen ist, die häufig verwendet wird, um Internetauftritte zu gestalten, werden einige der relevanten Sicherheitsoptionen nachfolgend kurz vorgestellt:

  • allow_url_fopen = off

Diese Option erlaubt es, PHP-Skripten nur noch lokale Dateien des Servers einzubinden. Damit können keine Skripte von externen Servern mehr ausgeführt werden.

  • open_basedir = /pfad/zum/www-ordner

Diese Option schränkt den Arbeitsbereich der Anwendung auf ein Verzeichnis ein. Die Applikation ist nicht mehr in der Lage Dateien außerhalb dieses Verzeichnisses zu öffnen. Die Unterordner dieses Verzeichnisses können weiterhin benutzt werden.

  • save-mode = on

Diese Option schränkt die Zugriffsrechte der PHP-Anwendung ein auf Dateien die dem Nutzer gehören. Darüber hinaus werden auch einige gefährliche Funktionen wie shell-exec() gesperrt. Eine weitere Steuerung ist durch weitere Optionen dennoch möglich.

  • display_errors = off

Da manche Angriffe gezielt Fehlermeldungen provozieren um z.B. Systempfade zur Applikation auszulesen, bietet diese Option die Möglichkeit, das Ausgeben von Fehlermeldungen zu unterbinden.

Neben dem sauberen Programmieren sollte grundsätzlich allen Daten, die in irgendeiner Form von außen manipuliert worden sein könnten, misstraut werden. Diese Daten sollten als unsicher angesehen und auf Gültigkeit hin geprüft werden. Das gilt auch für die Variablen in den URLs!

Es sollten keine ungefilterten Strings zur Weiterverarbeitung durchgereicht werden, also z.B. Steuerzeichen durch ihre Escapesequenzen ersetzen.

Zwar würde dadurch kein unerwünschter Befehl mehrausgeführt werden, allerdings hat das Ersetzen der Sonderzeichen mit ihren Escape-Sequenzen den Nachteil, dass auch Tags geblockt würden. Und in manchen Foren ist es erwünscht, dass der Benutzer weiterhin die Möglichkeit hat, seinen Text zu formatieren, wodurch das beschriebene Verfahren unbrauchbar werden würde.

Deswegen gibt es listenbasierte Filter, bei denen nicht alle, sondern nur die potentiell schädlichen Tags verändert werden. Es wird dabei das Whitelisting und das Blacklisting unterschieden.

Quellen

Siehe auch

Abgerufen von „https://glossar.hs-augsburg.de/w/index.php?title=Cross_Site_Scripting&oldid=47422“