2 Cross-Site Scripting
Eines der Hauptprobleme in heutigen Webapplikationen ist und bleibt Cross-Site Scripting. Der Name ist dabei etwas verwirrend, denn die darunter verstandenen Angriffsszenarien müssen gar nicht durch eine zweite Seite stattfinden oder von dort Daten laden. Die Angriffe finden häufig auf einer einzelnen Seite statt, indem dort HTML-, CSS- oder JavaScript-Code eingefügt wird und im Idealfall persistent vorhanden ist, indem der Angriff in der Datenbank, Session oder in Cookies gespeichert wird.
Technisch gesehen gehört eine XSS-Attacke sogar zum großen Teil der Injections (Kapitel 3.1), da die Problematik aber so groß und weit verbreitet ist, wurde ihr hier ein eigenes Kapitel gewidmet.
2.1 Die Gefahr
Das klingt jetzt alles spannend, aber was kann denn wirklich passieren?
2.1.1 Defacing
Das wohl noch kleinere Übel ist das Defacing einer Website. Häufig rühmt sich der Angreifer dann damit, eine Website gehackt zu haben, und hinterlässt seine „Tags“. Farben oder Texte werden manipuliert, die Änderungen sind aber zumeist sofort erkennbar, da der Hack Aufmerksamkeit erregen soll.
Möglich ist es aber auch, das Ganze etwas subtiler zu machen, so kursieren aktuell mehrere Fälle im TYPO3-Umfeld, bei denen sich der Content dynamisch ändert, je nachdem, über welche Suchbegriffe man auf die Website gekommen ist. Dies wird dazu genutzt, um damit dann z. B. über Ihre Website quasi unbemerkt Viagra oder andere zwielichtige Güter zu bewerben und verkaufen. Dies wird häufig erst erkannt, wenn man selbst über entsprechende Suchergebnisse auf die Website trifft oder die Logs genauer untersucht, um herauszufinden, mit welchen Suchbegriffen auf die Seite gelangt wurde.
2.1.2 Datenmanipulation
Etwas weiter gehen die Attacken dann, wenn bösartiger JavaScript-Code eingefügt wird, der z. B. Requests ausführt, die via AJAX ausgelöst werden, und dadurch die Daten manipuliert.
Ruft dann ein User die Seite auf, können dadurch z. B. seine E-Mail-Adresse oder Informationen in seinem Profil geändert werden, ohne dass er davon etwas mitbekommt. Letzteres wird in Kapitel 3.3.3 mit einer XSS-/CSRF-Kombination auf die Spitze getrieben.
Hat der User Administrationsrechte, wäre es sogar möglich, automatisiert z. B. einen neuen Account anzulegen oder einem bestehenden Account mehr Rechte zu geben, wenn der Angreifer genügend Informationen über die benötigten Requests hat.
Prinzipiell ist aber auch die Manipulation von Seiten denkbar, wenn man auf einen Redakteur trifft, oder die Änderung des Rankings in einem Suchalgorithmus, oder eventuell das Setzen von Links auf die Seite der Konkurrenz.
2.1.3 Datenspionage
Doch kann das Ausspionieren von Daten weitaus schlimmere Folgen haben als die Manipulation. Während Letztere doch sicherlich entdeckt werden kann, bleiben Spione oft jahrelang unentdeckt, geben sensitive Firmeninformationen preis oder tracken einfach jegliche Aktion des kompromittierten Clients.
So sind nicht nur die Daten auf der angegriffenen Website in Gefahr, und zwar sämtliche, egal welche Userrechte benötigt werden, sondern auch viele Informationen über den Client: Wie benutzt er die Website, wann besucht er sie und welche sonstigen Systeme sind über ihn im Netzwerk erreichbar? Details zum Scannen eines internen Netzwerks mithilfe einer XSS-Lücke finden Sie in Kapitel 2.1.5.
2.1.4 XSS-Proxy
Das Ganze wird durch XSS-Proxies zur Perfektion getrieben. So gibt es inzwischen voll ausgebaute Applikationen, um über XSS-Lücken ganze Bot-Netze durch die kompromittierten Browser aufzubauen und nicht nur die gehackte Website zu schädigen, sondern darüber z. B. auch sehr gut nachempfundene Log-ins für weitere Dienste wie Facebook einzublenden, die dann natürlich nach Hause telefonieren, oder auch mal nahezu unbemerkt die Webcam des Users zu aktivieren.
Sehr clever ist dabei, dass diese XSS-Proxies sich persistent auf der Website einnisten. Sobald sie einmal geladen sind, tauschen sie alle Link-Tags durch AJAX-Requests aus. Normalerweise wäre ein XSS-Hack nutzlos, sobald die betroffene Seite verlassen wird, da der JavaScript-Code komplett geleert und das Script angehalten wird. Durch den Austausch der Links werden die Inhalte beim Klick auf einen der Links zwar geladen und dem Client angezeigt, sodass der User zunächst nichts bemerkt. Da der Content aber im Hintergrund geladen wird und kein komplettes Neuladen der Seite erfolgt, bleiben der JavaScript-Code und somit auch der XSS-Proxy weiterhin geladen und können somit auch später noch Informationen ausspionieren, obwohl diese Seiten eigentlich gar keine XSS-Lücke enthalten. Am Beispiel des BeEF-Projekts zeigen wir in Kapitel 7.4 wie solch ein XSS-Proxy aussehen kann.
2.1.5 Angriff auf Drittsysteme
Allerdings ist nicht nur die ursprünglich gehackte Website in Gefahr, denn von ihr können u. a. auch Requests an ein internes Netz (eine interne Jira-Instanz, Forum oder Router) abgesetzt werden. Die Same Origin Policy verhindert dabei zwar, dass die Response ausgelesen werden kann, der Request wird aber trotzdem abgesetzt, so wird eine Abfrage gesendet und es werden Funktionen ausgeführt. In Kombination mit einer Time-based SQL Injection (Kapitel 3.1.1) ist es dann weiterhin möglich, auch Daten aus einem internen System auszulesen.
Jetzt aber genug zur Theorie, denn Sie wollen sicherlich praktische Beispiele und Quellcode sehen?
2.2 XSS-Typen
XSS-Lücken werden in drei verschiedene Typen unterteilt, die im Folgenden im Detail beschrieben werden.
2.2.1 Type 0/DOM-based XSS
Unter dem Type 0 oder auch DOM-based oder lokaler XSS versteht man einen Angriff auf das DOM-Objekt im Browser. Der Angriff wird dadurch ausgeführt, dass die DOM-Umgebung des Opfers manipuliert wurde und der ursprüngliche Code ein unerwartetes Verhalten zeigt. Der Quellcode der Seite ändert sich also nicht, allerdings wurden die Daten manipuliert, auf die zugegriffen wird.
Am einfachsten lässt sich dies an einem kleinen Beispiel zeigen, wenn man folgenden Quellcode annimmt:
<label for="language">Sprache:</label>
<select id="language">
<script type="text/javascript">
document.write('<option value="1">' +
document.location.href.substring(
document.location.href.indexOf(
'def=' +
4
)
) + '</option>');
document.write('<option value="2">' +
'Englisch' +
'</option>'
);
</script>
</select>
Normalerweise wird die Seite also mit etwa folgendem URL aufgerufen:
http://www.example.com/index.php?def=Deutsch
Eine Attacke könnte nun aber passieren, wenn der URL z. B. folgendermaßen abgeändert wird:
http://www.example.com/index.php?def=
<script>alert(document.cookie);</script>
Die Response enthält dann an der Stelle, an der normalerweise die Sprache innerhalb des <option>-Tags stehen sollte, JavaScript-Code, der den Inhalt der Cookies ausgibt.
2.2.2 Type 1/nicht persistente Schwachstelle
Eine nichtpersistente oder auch reflektierte Schwachstelle ist wohl die weit verbreitetste Art von XSS.
Ein typisches Beispiel ist eine Suchmaschine, die den Such-String noch einmal in der Headline oder auch als vordefinierten value ausgibt. Das soll an einem Beispiel demonstriert werden:
<form method="GET" action=".">
<label for="sword">Suche:</label>
<input name="sword" id="sword" />
<input type="submit" />
</form>
<h1>
Ihre Suche nach
<?php echo $_GET['sword']; ?>
ergab folgende Treffer:
</h1>
Normalerweise sollte dieses Formular einen URL erzeugen, der etwa folgenermaßen aussieht:
http://www.example.com/index.php?sword=foobar
Nun wird statt des Suchworts wiederum JavaScript-Code übergeben:
http://www.example.com/index.php?sword=
<script>alert(document.cookie);</script>
So wird statt der Ausgabe des eigentlichen Suchbegriffs wiederum die Informationen der Cookies ausgegeben.
Der entsprechende URL kann dabei auch z. B. einem unwissenden Opfer untergejubelt werden, indem von einer modifizierten Seite mit dem manipulierten Suchbegriff verlinkt oder der Link per Forum oder E-Mail verteilt wird.
Besonders häufig tritt diese Art von Schwachstelle auch bei konfigurierbaren Produkten auf, die z. B. die Übergabe einer Farbe oder eines Namens erlauben, der nicht weiter validiert und so direkt an den Browser ausgegeben wird.
2.2.3 Type 2/persistente Schwachstelle
Persistente oder auch Second-Order-Schwachstellen werden als Type 2 kategorisiert und sind gleichzeitig die wohl gefährlichsten aller möglichen XSS-Attacken.
Von Type 1 unterscheidet sich dieser Angriff dadurch, dass die übermittelten Daten in irgendeiner Art und Weise auf dem Server gespeichert werden. Sehr häufig sind hier z. B. Datenbanksysteme oder Cache-Server.
Auf E-Commerce-Seiten sind besonders Kommentar- und Bewertungssysteme betroffen, die es den Nutzern erlauben, HTML-formatierten Text zu speichern und anderen...
