Zustandsforschung

Cross-Site-Scripting ist immer mal wieder ein aktuelles Thema. Kürzlich erst wurde ein Sicherheitsloch in den Auftritten der Volks- und Raiffeisenbanken entdeckt. Das scheint mir Grund genug dafür zu sein, in diesem Tutorial kurz zusammenzufassen, was Cross-Site-Scripting ist, wie Cross-Site-Scripting funktioniert, wie man es selber macht und wie man es verhindern kann.

Was ist Cross-Site-Scripting?
Cross-Site-Scripting oder kurz XSS bezeichnet das Ausnutzen von gewissen Sicherheitslücken auf einer Website, um über eine manipulierte URL eigenen JavaScript-Code dort einschleusen zu können.

Warum tut man das?
Der Vorteil für den Angreifer ist, dass er sobald er eigenen JavaScript-Code auf einer Seite ausführen kann, die totale Kontrolle über die Seite hat, es aber für den Benutzer weiterhin so aussieht, als käme der Inhalt von der Ursprungsseite.

Was nützt einem das?
Wenn man jetzt einen Benutzer dazu bringen kann, den manipulierten Link zu klicken, sieht er das, was der Angreifer will. Richtig nützlich ist das eben wie im oben angesprochenen Fall bei einer Bank, um auf deren Seite das eigene Formular einblenden zu können. Da steht dann beispielsweise drin, dass man 4 TANs eingeben soll, die dann beim Absenden nicht bei der Bank sondern bei irgendwelchen kriminellen landen. Aber die Möglichkeiten sind vielfältig. Der Angreifer könnte auch beispielsweise Session-Informationen des Benutzers auslesen und kann sich dann als dieser Benutzer identifizieren. Damit das funktioniert, muss der Benutzer allerdings immer noch dazu gebracht werden, auf den manipulierten Link zu klicken. Das wird üblicherweise über E-Mails gemacht (sogenanntes Mail-Spoofing), aber es sind auch andere Wege möglich.

Wie funktioniert das genau?
Nehmen wir mal an, es gibt eine Seite einer fiktiven Bank, die unter der URL www.zustandsbank.test zu erreichen ist. Nehmen wir weiter an, dass es auf dieser Seite eine einfache Suchfunktion gibt, die den GET-Parameter “suche” verwendet. Sucht man nun zum Beispiel nach “TAN”, dann hat die resultierende Suchergebnisseite die URL

http://www.zustandsbank.test/index.html?suche=TAN

Zusätzlich – und hier wird es interessant – gehen wir davon aus, dass die Seite den Suchbegriff nochmal ausgibt, und zwar mit folgendem HTML-Code:

<h1>Sie haben nach <b>TAN</b> gesucht</h1>

Jetzt können wir hier angreifen: Wir suchen anstatt nach “TAN” nach

<script>alert('Cross Site Scripting');</script>

Damit ergibt die Ausgabe auf der Seite der Zustandsbank:

<h1>Sie haben nach <b><script>alert('Cross Site Scripting');</script></b> gesucht</h1>

Damit haben wir nun unser Ziel erreicht, JavaScript-Code in die Seite einzuschleusen: Als Ergebnis poppt ein kleines JavaScript-Fensterchen hoch:

Natürlich könnten wir jetzt noch mehr tun als nur eine Meldung anzeigen – wir können die Seite nach unserem Gutdünken umgestalten, denn wir haben jetzt via JavaScript Zugriff auf den ganzen DOM-Baum.

Ist das immer so einfach?
Nein. Manchmal muss man andere Umwege gehen. So kann es zum Beispiel sein, dass der eingegeben Begriff in einer URL wieder auftaucht:

<a href="http://www.zustandsbank.de/index.html?suche=TAN">

In diesem Fall würde sich etwa ein Suchbegriff wie der folgende anbieten, der den a-Tag schließt und einen eigenen script-Tag aufmacht:

"><script>alert('Cross Site Scripting');</script><

Oder der URL-Parameter wird direkt in einem JavaScript verwendet:

   var suche = "TAN";

Dann baut man folgendermaßen seinen eigenen Code ein, der den JavaScript-Befehl abschließt und dann seinen eigenen schreibt:

   ";alert('Cross Site Scripting');var i ="

Was im Endergebnis dann folgendes ergibt:

   var suche = "";alert('Cross Site Scripting');var i ="";

Zusätzlich gibt es noch tausende andere Möglichkeiten eigenen Code einzuschleusen, von denen einige im XSS (Cross Site Scripting) Cheat Sheet aufgeführt sind.

Wie kann ich mich davor schützen?
Eigentlich ist es ganz einfach: Man sollte niemals Benutzereingaben vertrauen beziehungsweise diese direkt auf die Webseite rausschreiben. Am besten ist es, wenn man sowieso nur eine gewisse Menge “erlaubte” Zeichen zulässt oder Sonderzeichen in ihre HTML-Entities umwandelt. Was daran manchmal ein bisschen schwierig ist, ist zu erkennen, wann überhaupt eine Benutzereingabe möglich ist. Bei Formularen auf der Seite ist das noch relativ einfach zu erkennen. Komplizierter wird es dann, wenn URL-Parameter verwendet werden, die nicht direkt auf Eingaben durch den Benutzer basieren. Diese könnten trotzdem manipuliert worden sein.

Ist das alles?
Nein. Das Thema “Cross-Site-Scripting” ist sehr komplex. Wichtig ist grundsätzlich aber zu wissen, dass man Benutzereingaben auf keinen Fall vertrauen darf. Wer noch mehr wissen will, kann sich unter folgenden Links weiter informieren:

• XSS Workshop – XSS zum Mitmachen
• XSS (Cross Site Scripting) Cheat Sheet – Verschiedene Möglichkeiten, eigenen Code in eine Seite einzuschleusen
• Cross-site scripting – Der englische Wikipedia-Artikel zum Thema mit haufenweise weiterführenden Links