Channel Security

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.

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.

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.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Sichere Webanwendungen – Cross-Site Scripting"

• About Security #14: Cross-Site Scripting
• About Security #15: Cross-Site Scripting verhindern
• About Security #129: Cross-Site Scripting, reloaded
• About Security #130: DOM-basiertes XSS abwehren
• About Security #131: XSS-Angriffe (1)
• About Security #132: XSS-Angriffe (2)
• About Security #133: XSS-Angriffe (3): JavaScript Ping & Co.
• About Security #134: XSS-Angriffe (4): JavaScript Portscan
• About Security #135: XSS-Angriffe (5): JavaScript Portscan vorbereiten
• About Security #136: XSS-Angriffe (6): DSL-Router ausspähen
• About Security #137: XSS-Angriffe (7): Weitere Ziele