Cross-Site Scripting

Wechseln zu: Navigation, Suche

Cross-Site Scripting (XSS) beschreibt das Einschleusen von Schadcode auf Internetseiten. Meist geschieht dies über HTML-Formulare oder GET-/POST-Requests an den Webserver.


Es wird zwischen persistentem und nicht-persistentem Cross-Site Scripting unterschieden. Bei der persistenten Variante verbleibt der Schadcode auf der Webseite. Auf einer Seite mit Suchbegriffseingabemaske kann beispielsweise nicht-persistentes XSS zum Einsatz kommen, da der Suchbegriff nicht (öffentlich) gespeichert wird. Der Schadcode muss immer übergeben werden (via GET-/POST-Parametern). In Gästebüchern, Kommentaren, Wikis usw. kann die persistente Variante zum Einsatz kommen, da die eingegebenen Inhalte gespeichert und allen folgenden Besuchern angezeigt werden.

Von dieser harmlos anmutenden Angriffstechnik geht in Wirklichkeit aber eine ernstzunehmende Gefahr aus, die im Folgenden kurz beschrieben werden soll.

Da alle modernen Webbrowser JavaScript-fähig und per default aktiviert sind, ist für Angreifer JavaScript-Code interessant, der bei Besuch der Seite (normalerweise) unbemerkt ausgeführt wird:

http://www.example.com/search.php?search=<script>alert('hallo')</script>

Nicht-persistentes Cross-Site Scripting

Um dubios anmutende Links mit JavaScipt Inhalten zu vermeiden, können sich Angreifer verschiedener Techniken bedienen.

Short-Links

Short-Link-Services generieren für beliebige URLs kurze Weiterleitungs-URLs, denen man nicht mehr ansehen kann, ob sie Schadcode beinhalten. Diese Links werden u.a. per E-Mail, Kurznachrichtendiensten und Kommentaren gestreut.

Einbetten in eigene Homepage

Prinzipiell kann jede beliebige Seite im Internet Fremd-Inhalte, die mit Schadcode verseucht sind, unbemerkt nachladen. Dies kann durch versteckte Iframes oder sogar durch das scheinbare Einbetten von "Bildern" bewerkstelligt werden (siehe Slide #55 "How I Met Your Girlfriend").

Beispiel: <img src="http://www.example.com/search.php?search=<script>alert('hallo')</script>">


Die Same Origin Policy verbietet sinnvollerweise den Zugriff auf externe Inhalte durch JavaScript. Leider kann diese Policy sehr schnell außer Kraft gesetzt werden, wenn man sich nur einmal die submit-Funktion von JavaScript anschaut. Kombiniert mit einem Formular mit Input-Tags, dessen type="hidden" gesetzt ist, können problemlos Daten aller Art unbemerkt an beliebige Seiten gesendet werden.

Konkrete Angriffsszenarien

Auf Seiten, die ihre Benutzereingaben nicht korrekt überprüfen, bevor sie sie wieder ausgeben, sind folgende Szenarien denkbar:

Ausspähen des E-Mail-Kontos

  1. Das Opfer ist bei seinem E-Mail-Provider via Cookie angemeldet.
  2. Das Opfer wird vom Angreifer entweder direkt (evtl. via Short-Links) auf die anzugreifende Seite gelotst (Schadcode in GET-Parameter) oder auf seine eigene Seite verwiesen, auf der eben dieser Link einbettet ist.
  3. Vom Opfer unbemerkt wird entsprechender JavaScript-Code ausgeführt, der den Cookie ausliest.
  4. Der Code erzeugt weiterhin ein verstecktes Formular mit den Cookie-Daten.
  5. Letztendlich wird das Formular an den Angreifer versandt, der nun die Cookie-Daten erhält und somit Zugriff auf das E-Mail-Konto des Opfers hat und evtl. sogar dessen Passwort ändern kann.

Ausspähen der Internetzugangs- und WLAN-Daten

  1. Das Opfer betreibt einen im lokalen Netzwerk einen nicht weiter gesicherten Router, dessen Webinterface allerdings nicht ins Internet geforwardet ist.
  2. Das Opfer wird vom Angreifer auf seine eigene Seite verwiesen, auf der ein Iframe eine PHP-Seite lädt, die auf 192.168.0.1 weiterleitet und den nötigen Schadcode übermittelt. (Iframes können lokale Ressourcen nicht direkt einbetten)
  3. Nun wird wie oben ein HTML-Formular durch den Code erstellt und persönliche Daten wie Internetzugangskennung, MAC-Adresse (womit sich u.U. die GeoLocation des Opfers feststellen ließe), WLAN-Name und Kennwort an den Angreifer versandt.

Weitere Angriffsszenarien sind quasi in unbegrenzter Zahl denkbar (beispielsweise auch Keylogger).

Schutz vor Cross-Site Scripting

Als Webmaster

Seitenbereiber stehen in der Pflicht, Benutzereingaben in jedem Fall zu überprüfen, sei es auf öffentlichen oder privaten Seiten, die durch Kennwörter gesichert sind. Obige Angriffsszenarien zeigen das Ausmaß des Schadens, der auf verhältnismäßig leichte Weise verursacht werden kann. Selbst viele namhafte Firmen betreiben wenig Aufwand, um solche Sicherheitslücken z.B. in aktuellen Versionen von Router-Webinterfaces zu stopfen, weil sie vermeintlich im lokalen Netzwerk geschützt sind und kein großes Ziel darstellen. Das Angriffsszenario oben zeigt allerdings, dass diese Auffassung eine folgenschwere Fehleinschätzung ist.

PHP bietet als Beispiel die Funktionen htmlentities() und addslashes() (insbesondere gegen SQL-Injections), um Benutzereingaben zu überprüfen, bevor diese wieder auf der Seite auftauchen. thumb|[http://noscript.net/ NoScript] erkennt und blockiert Cross-Site Scripting selbst wenn das Script vorher zugelassen wurde.

Als Benutzer

Benutzer sind Cross-Site Scripting leider häufig schutzlos ausgeliefert, einige Gegenstrategien gibt es allerdings doch:

  • Das NoScript Firefox-Addon verbietet Scripting Sprachen von vornherein und erkennt auch XSS-Angriffe. Vertrauenswürdige Scripte lassen sich manuell aktivieren.
  • Im Prinzip ist es auch nicht verkehrt, nicht jeden beliebigen Link ohne vorherige Prüfung zu klicken, allerdings ist dies bei der schieren Masse an Links und insbesondere in Zeiten von Short-Links immer weniger praktikabel [1].

Weiterführende Links