1. Einführung
Cross Site Scripting (kurz XSS) ist die ungeschlagene Nummer 1 der Angriffe im Internet. Höchstens der sogenannte Bufferoverflow könnte dieser Technik an Popularität den Rang ablaufen. Spätestens dann, wenn du eine Anwendung im Web betreibst, solltest du über diesen Angriffsvektor Bescheid wissen. Durch ihn können nämlich die Daten der angegriffenen Webseite verändert werden, weshalb man Cross Site Scripting zur Klasse der aktiven Angriffe zählt.
Das Internet, welches sich dir tagtäglich in seiner vollen Schönheit präsentiert, ist u. a. in HTML (Hypertext Markup Lanugage) geschrieben. Diese Sprache verwendet Tags, mit denen die Struktur für bspw. Texte und Bilder festgelegt werden. Kurzum: Sie versorgen den Browser mit Informationen darüber, wie die aufgerufene Webseite aufgebaut ist. Ein HTML-Dokument öffnet man mit einem <html>-Tag und schließt es mit einem </html>-Tag. Dazwischen können weitere Instruktionen stehen:
<html>
...
</html>
Text, der innerhalb des Bold-Tags <b> gekapselt ist, wird im Browser als fett markierter Text gerendert:
<html>
<b>Hallo Welt!</b>
</html>
Die Ausgabe im Browser lautet dann:
Hallo Welt
Alleine das Wissen darum, dass mit den spitzen Klammern Instruktionen eingeleitet werden, reicht bereits aus, um den Kern des Cross Site Scripting Angriffs zu verstehen.
2. Wie funktioniert der Angriff?
Im Normalfall werden statt der spitzen Klammern sogenannte Escape-Symbole verwendet, um etwa bei Benutzereingaben zu verhindern, dass diese spitzen Klammern auf der Webseite gespeichert werden. Statt des Kleiner-Als-Zeichens < wird der Seite der Escape-Code < übermittelt. So weiß der Browser zwar, dass er in Textpassagen ein < rendern soll, doch die Seite interpretiert das nicht als Einleitung für einen Tag. Das ist sehr wichtig!
Doch warum egentlich? Im schlimmsten Fall könnte doch lediglich durch Missbrauch dieser Tags das Design der Webseite kaputtgemacht werden, oder? Nun, das würde stimmen, wenn das Web ein reines Darstellungsmedium wäre und keine Interaktivität (z. B. durch die bereits erwähnten Benutzereingaben oder Datenbankaufrufe) bieten würde. Doch die Realität sieht anders aus! Insbesondere JavaScript, das im Webumfeld beim Client (also auf deinem Rechner, wenn du eine Seite aufrufst) ausgeführt wird, ist ein Risikofaktor. Es handelt sich bei JavaScript um eine eigene Programmiersprache, mit der sogar ganze Spiele entwickelt werden können. Ohne sie wäre Interaktivität im Web-Umfeld quasi nicht möglich. JavaScript-Code wird innerhalb des <script>-Tags platziert und vom Browser ausgeführt. Die Anweisung
<html>
<script>
window.alert("Hacked!");
</script>
</html>
innerhalb eines HTML-Dokuments öffnet z. B. eine Alert-Box mit der Nachricht „Hacked!“, die du dann wegklicken musst um weiter mit der Seite interagieren zu können. Das klingt natürlich erstmal nach einer harmlosen Schelmerei, doch JavaScript bietet viele potentielle Angriffsmöglichkeiten, die auch das Ausspähen von sensiblen Daten ermöglichen. Wenn du dich z. B. bei der Bank deines Vertrauens über ein Online-Formular anmelden willst, könnte ein Angreifer statt der sicheren Übermittlung deines Benutzernamens und Passworts diese Informationen zusätzlich woanders (z. B. zu sich selbst) hinzuschicken und hätte dabei unbemerkt die Zugangsdaten zu deinem Bankaccount gestohlen.
Nicht umsonst ist es sinnvoll sich Browser-Erweiterungen wie NoScript zu installieren, um das Ausführen von JavaScript zu unterbinden. Auf der anderen Seite wäre ein Großteil des Webs nicht mehr nutzbar, wenn man JavaScript ständig deaktiviert hätte, weshalb die meisten den simplen Weg gehen und JavaScript einfach überall erlauben.
3. Wie kannst du dich vor XSS schützen?
Escape die spitzen Klammern! D. h. übersetze < zu < und > zu >. Besonders perfide an dem Cross Site Scripting Angriff ist, dass du als Entwickler nur ein einziges Mal in deiner Webanwendung vergessen musst die spitzen Klammern zu escapen und dann deine gesamte Webseite in großer Gefahr schwebt. Es reicht bereits ein einziges Feld, in das man etwas Banales wie sein Alter eintragen muss, um (bei vergessenem Escaping) Tür und Tor für Schadcode zu öffnen.
4. Wie häufig kommt XSS heute noch vor?
Wir leben in einer Gesellschaft, die bei solchen Themen eigentlich aufgeklärt ist. Jeder Informatiker hört früher oder später im Laufe seines Studiums von diesem Angriffsvektor und trotzdem hatten (und haben) selbst Riesen wie Google oder Facebook mit solchen Problemen zu kämpfen. Warum? Weil es so einfach zu vergessen ist! Es kommt also selbst in den besten Familien vor. Nicht umsonst schreiben Unternehmen Preise für Personen aus, die solche Schwachstellen auf ihrem Webauftritt finden und diese nicht mit der Welt, sondern erstmal mit ihnen teilen. Zwar gibt es Frameworks, die dich als Entwickler explizit danach fragen, ob du deinen Code für z. B. ein Formularfeld „wirklich, wirklich, wirklich so stehen lassen willst“, doch selbst dann kann man immer noch (bewusst oder unbewusst) Fehler begehen – dem freien Willen sei Dank!
5. Ein schneller Test auf XSS
Mit der folgenden Codezeile, die du in ein Eingabefeld deiner Webanwendung kopieren kannst, ist ein erster einfacher Test auf XSS-Anfälligkeit möglich:
<script>window.alert("Hier funktioniert XSS!");</script>
Dieser Test ist z. B. im Pentester Academy Lab erfolgreich. Achte aber darauf, in welchem Browser du diesen Test durchführst. Während Firefox dich die Seite ohne Probleme brechen lässt, weist dich Google Chrome darauf hin, dass „ungewöhnlicher Code“ erfasst wurde und die Seite daher blockiert wird, um personenbezogene Daten zu schützen, auch wenn das bei Google fast schon etwas ironisch klingt:
Autor: Florian André Dalwigk
