Montag, 17. September 2012


Topthema

Donnerstag, 29. November 2007 | Topthema

About Security #133: XSS-Angriffe (3): JavaScript Ping & Co.

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

Was kann ein Angreifer mit einem �ber XSS eingeschleusten iFrame erreichen und woran k�nnen ihn die Schutzfunktionen der Browser hindern? Au�er um die Antworten auf diese Fragen geht es in dieser Folge um zwei weitere Angriffe: Das Aussp�hen der Browser-History und Portscans �ber JavaScript.

Die Same Origin Policy verhindert, dass im eingeschleusten iFrame enthaltener JavaScript-Code auf das DOM der eigentlichen Seite zugreift. Er kann also weder Informationen daraus auslesen noch eigene Daten einf�gen. Die Same Origin Policy verhindert aber z.B. keine Cross-Site-Request-Forgery-Angriffe (About Security #127/ #128), da daf�r kein Zugriff auf die Seite notwendig ist. Auch Phishing ist trotz Same Origin Policy, also ohne Zugriff auf die eigentliche Seite, m�glich. Es reicht, wenn eine vertrauensw�rdige Seite, z.B. einer Bank, eine XSS-Schwachstelle enth�lt. Der Angreifer �berdeckt dann einfach die gesamte vertrauensw�rdige Seite oder Teile davon mit einem iFrame, in den er dann seine eigene, gef�lschte Seite l�dt. Die sieht nat�rlich genauso aus wie die normale, vertrauensw�rdige Seite und fragt z.B. Zugangs- oder Kreditkartendaten ab.

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

Der Benutzer sieht den vertrauensw�rdigen URL und darunter eine vertraute Seite. Dass die von einem anderen Server geladen wurde und die eingegebenen Daten an diesen Server sendet, ist f�r ihn nicht zu erkennen. Nach erfolgreichem Abphishen der Daten kann der Angreifer den Benutzer zur eigentlichen Seite weiterleiten, sodass f�r den Benutzer alles in Ordnung zu sein scheint. Man erh�lt also den altbekannten Enten-Effekt: Sieht aus wie eine Ente, quakt wie eine Ente, watschelt wie eine Ente � also muss es eine Ente sein.

Statt Teile der urspr�nglichen Seite zu �berdecken, kann der Angreifer auch seinen iFrame verstecken, wenn es ihm nur um die Ausf�hrung eingeschleusten JavaScript-Codes geht. Dazu muss er nur die Werte f�r width, height und border auf 0px setzen. Dadurch wird der iFrame nicht angezeigt, enthaltener JavaScript-Code aber ausgef�hrt. Einfach den Wert von display auf none zu setzen f�hrt nicht bei allen Browsern zum Ziel: Zwar wird der iFrame dann ebenfalls nicht angezeigt, aber manche Browser ignorieren ihn dann komplett, sodass der enthaltene Code nicht ausgef�hrt wird.

Auch wenn die meisten hier vorgestellten Angriffe in irgendeiner Form mit dem Aussp�hen von Informationen oder dem Vort�uschen von Benutzeraktionen zu tun haben, sollte das simple Einschleusen falscher Informationen nicht untersch�tzt werden. Zu m�glichen Auswirkungen solcher Falschmeldungen siehe den "Standpunkt Sicherheit" vom 4. September 2006 und 23. Juli 2007, hier interessiert nur der technische Hintergrund.

About Security: Die komplette Serie
Aussp�hen der Browser-History

Nun zum vorerst letzten Beispiel eines auf den lokalen Rechner beschr�nkten Angriffs, dem Aussp�hen der Browser-History. Die Kurzfassung dieses Angriffs kann mit "Guck nach, wie der Link aussieht" umschrieben werden: �ber CSS kann festgelegt werden, wie besuchte und nicht besuchte Links dargestellt werden sollen. �ber JavaScript kann der Style jedes DOM-Elements einer Seite abgefragt werden. Dies zusammen kann ausgenutzt werden, um die Browser-History auszusp�hen. Das funktioniert nach folgendem Muster:

  • �ber JavaScript wird ein Link zu einem den Angreifer interessierenden URL erzeugt.
  • Der Link wird mit unterschiedlichen Style-Attributen f�r :link und :visited versehen
  • Der Browser w�hlt den passenden Style automatisch aus
  • �ber JavaScript wird der Style des erzeugten Links gepr�ft: Bereits besuchte Links k�nnen dadurch von noch nicht besuchten unterschieden werden.

Der Angreifer kann also nicht die gesamte Browser-History nach Belieben durchgehen, aber stattdessen gezielt nach bestimmten Links fragen. Der Browser antwortet auf jede dieser Fragen mit "kenne ich nicht" bzw. "da war ich schon". Dieser gezielten Suche sind allerdings Grenzen gesetzt: Enth�lt der URL einer Seite Informationen wie z.B. eine Session-ID, die bei jedem Besuch unterschiedlich sind, muss der Angreifer exakt die Version erzeugen, die der Benutzer zuvor besucht hat, um zum richtigen Ergebnis zu kommen.

Portscan �ber JavaScript

Wer die Kontrolle �ber den Browser hat, befindet sich im lokalen Netz � und damit hinter der Firewall. Da w�re es doch sch�n, wenn dort nach brauchbaren Zielen gesucht werden k�nnte. Auch das ist m�glich. Zuerst ein Blick auf das, was JavaScript kann: Es k�nnen HTTP-Verbindungen zu beliebigen Hosts aufgebaut werden. Zwar ist meist kein Zugriff auf das Ergebnis m�glich, aber der Erfolg oder Misserfolg des Verbindungsversuchs kann erkannt werden. Au�erdem k�nnen Timer verwendet und ausgel�ste Events erkannt werden. Aus diesen Bausteinen kann nun ein ping-Befehl konstruiert werden:

Es wird ein Image-Objekt mit onLoad()- und onError()-Events und einem Timer erzeugt. Beim Setzen des src-Attributs wird ein HTTP-GET-Request zum angegebenen Host ausgel�st, gleichzeitig wird der Timer gestartet. Jetzt gibt es 3 M�glichkeiten:

  1. Der Host existiert, der angesprochene Port ist aber geschlossen bzw. es ist keine HTTP-Verbindung m�glich: Der onError()-Event wird ausgel�st.
  2. Der Host existiert und ein Webserver ist erreichbar: Der onLoad()-Event wird ausgel�st.
  3. Der Host existiert nicht: Der Timer-Event wird ausgel�st.

Wie man von diesem Ping zu einem regelrechten Portscan gelangt, wird in der n�chsten Folge beschrieben.

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 � Cross-Site Scripting"

Kommentare

Folgende Links könnten Sie auch interessieren