Cross Site Scripting


Unter Cross Site Scripting (kurz auch XSS) versteht man den Vorgang einen Rechner mittels aktiver Elemente eines Servers anzugreifen.

Da aktive Elemente zunehmend beliebter werden und die meisten Server den User quasi dazu zwingen aktive Elemente im Browser auszuführen nimmt die Beliebtheit des XSS bei Crackern derzeit zu. Aber was passiert nun eigentlich beim XSS??

An und für sich ist es einfach:

Man nimmt einen x-beliebigen Server, legt darauf ein aktives Element ab und wartet, dass das Opfer dieses beim normalen Surfen anklickt. Tut das Opfer dies, so wird das aktive Element bei dem User ausgeführt und schon hat der Angreifer sein Ziel erreicht. Oftmals geht dieser Angriff mit einem Umformatieren der im Browser angezeigten URL einher (Siehe hierzu: URLs mal anders). Dies dient einzig dazu den Angriff optisch vor dem zumeist unbedarften Opfer zu verschleiern. Außerdem ist damit zu Rechnen, dass ein Angreifer bestrebt ist, die Funktion des Webservers von dem aus er seinen Angriff auf das eigentliche Ziel startet so zu belassen, wie das Opfer es erwartet.

So einfach sich das auf den ersten Moment anhört, so einfach ist es in der Regel leider auch in der Praxis. Da heutzutage kaum noch Websites ohne aktive Elemente die auf dem Server laufen auskommen, bieten sich für einen Cracker immer wieder Fehler im Design oder der Umsetzung des aktiven Elementes, die er ausnutzen kann um sein Ziel zu erreichen.

Hierfür ein einfaches Beispiel: Ein Webserver bietet ein Messageboard an. Um dies Interessanter zu gestalten, können die User auch Grafiken oder kleine Tondaten ablegen. Was hindert einen Cracker daran statt des Bildes nun ein Script abzulegen, welches ein Bild anzeigt und noch ein bisschen mehr auf dem Rechner des Opfers macht?? Da die meisten Internetsurfer keine HighTech-Freaks mit jahrhundertelanger Computererfahrung sind, werden sie auf diesen Trick hereinfallen.

Aber was könnte die Motivation für einen solchen XSS Angriff sein?

Da wäre z.B. das Cookiestehlen:

Viele Sites nutzen Cookies um den User zu Authentifizieren. Wenn man also andrer Leute Cookies stiehlt, kann man fremde Mailaccounts oder Fremderleuts Messageboard Accounts klauen. (Auch im Bereich eCommerce wären solche Angriffe möglich.)

Man kann den fremden Rechner Hijacken:

Dies ist das eigentlich gefährlichere Übel. Man kann mit XSS z.B. Trojaner oder Viren auf fremden Rechner installieren. Auf diese Art werden diese Systeme zu Waffen des Crackers.

Man könnte auch verschlüsselte (und somit meist vertrauliche) Daten abhören:

Da man sich auf dem Rechner des Opfers befindet kann man den Datenverkehr abfangen bevor er verschlüsselt wird. Hierdurch sind Onlinebanking oder vertraulicher Emailverkehr aber auch VPN Lösungen in Gefahr.

Bleibt die Frage zu klären wie ein Cracker nun einen Webserver mit aktiven Elementen infiziert.

Auch dies ist einfacher als es aussieht. Mal abgesehen von dem im Beispiel genannten Messageboards bieten eine Vielzahl von Servern andere z.T. von den Betreibern des Servers selber programmierte aktive Elemente, wo der User nach Daten gefragt wird die dann auf dem Server gespeichert werden. Beispielsweise Onlineformulare zwecks Onlinebestellung. Sind diese nicht fehlerfrei programmiert, so wäre auch hier eine Injektionsgefahr zu sehen.

Abschließend eine Überlegung wie man das XSS in den Griff bekommen kann. Da XSS immer wieder den Server als Ausgangspunkt hat sollte hier auch der Versuch das Problem zu beseitigen sein. Ein fehlerfrei konfigurierter Server mit fehlerfreien Applikationen und fehlerfreiem Design ist unanfällig für diesen Angriff. Demzufolge sollte jede Applikation vor der Installation auf evtl. Fehler getestet werden. Gerade die Fehlerroutinen sollten doppelt gecheckt werden (auch auf URL-Obscuring). Im Anschluss daran sollte jeder auftauchende Fehler schnellstens gefixt werden.



Kontaktadresse







Valid HTML 4.01!