© saicle/Shutterstock.com
UI-Redressing aka Clickjacking

Angriffsziel UI


Clickjacking ist inzwischen sechs Jahre alt – und es gibt immer wieder neue Varianten und Angriffsmöglichkeiten. Inzwischen sogar ohne den Einsatz unsichtbarer iframes.

Clickjacking wurde 2008 von Jeremiah Grossman und Robert „RSnake“ Hansen erstmals beschrieben. Die Veröffentlichung war etwas turbulent [1]: Erst wurde die Veröffentlichung für eine Konferenz angekündigt, dann der Vortrag zurückgezogen, weil ein betroffener Hersteller noch Zeit brauchte, um den Angriff abzuwehren. Woraufhin nach kurzer Zeit ein Dritter aufgrund bekannter Informationsfetzen einen PoC veröffentlichte und der Hersteller plötzlich sofort eine Gegenmaßnahme bereit hatte.

Was ist Clickjacking?

Beim Clickjacking lockt der Angreifer einen Benutzer auf eine Webseite unter seiner Kontrolle und lässt ihn einen oder mehrere Klicks machen. Bei einem einzelnen Klick kann das einfach eine Aufforderung sein, einen Link oder Button anzuklicken. Mehrere Klicks können zum Beispiel erreicht werden, indem der Benutzer dazu gebracht wird, ein Spiel zu spielen.

Außer den sichtbaren Inhalten gibt es auf dieser Seite noch einen unsichtbaren iframe, in dem der Angreifer eine Seite einer anderen Website geladen hat. Das kann, muss aber nicht zwingend (s. u.) eine Website sein, bei der das Opfer angemeldet ist. Dieser iframe hängt am Mauszeiger, und ein oder mehrere Klicks werden auf die unsichtbare Seite im iframe umgeleitet, indem der iframe vor die dargestellte Seite gelegt wird. Im iframe lösen die Klicks dann eine Aktion im Namen des Benutzers aus.

Likejacking

Ein bekanntes Beispiel für Clickjacking-Angriffe „in the wild“ sind Angriffe auf Facebooks Like-Button, für die sogar ein eigener Name geschaffen wurde: Like­jack­ing [2]. Ein Facebook-Benutzer wird auf eine Seite gelockt, auf der er irgendetwas anklickt. Der Klick wird auf einen unsichtbaren Like-Button geleitet, sodass er diese Seite „liked“. Sehen die Freunde des Opfers nach, was dem denn da gefallen hat, landen sie ebenfalls auf der Seite des Angreifers, „liken“ unbewusst und führen den Angreifern weitere Opfer zu. Während die ersten Likejacking-Angriffe sich damit zufriedengaben, sich selbst zu verbreiten, kam es später auch zu weiteren Angriffen, wie zum Beispiel Klickbetrug oder der Installation von Schadsoftware.

So verhindern Sie Clickjacking

Die Abwehr von Clickjacking-Angriffen ist recht einfach: Wenn eine Seite nicht in einem Frame dargestellt werden kann, ist kein Click­jacking möglich. Der erste Schutz bestand daher in JavaScript-basierten Framebustern nach dem Muster

<script type="text/javascript"> if (top!=self) top.location.href=self.location.href; </script>

Die haben nur zwei Nachteile: Sie funktionieren nicht, wenn JavaScript ausgeschaltet ist (was in Zeiten des Web 2.0 und von HTML5 aber meist auch dazu führt, dass „das Web“ nicht mehr richtig funktioniert), und ließen sich schon 2010 alle auf die eine oder andere Weise in einem oder mehreren Browsern umgehen.

Mit dem in HTML5 eingeführten sandbox-Attribut für iframes wurde diese Situation noch verschärft. Darüber lässt sich der Zugriff auf die Top-Level-Navigation verbieten, während JavaScript-Code ansonsten weiterhin ausgeführt werden kann. Dadurch versagt der Framebuster und die in den iframe mit sandbox-Attribut geladene Seite kann über Clickjacking angegriffen werden.

Ein HTTP-Header ist zuverlässiger als JavaScript-Code

Als weiterer Schutz wurde der X-Frame-Options HTTP-Header entwickelt, der inzwischen in RFC 7034 [3] dokumentiert wird. Der Header kann einen von drei Werten annehmen:

  • DENY – Der Browser stellt die Seite grundsätzlich nicht dar, wenn sie in einem Frame geladen wird.

  • SAMEORIGIN – Die Seite wird nur dann in Frames dargestellt, wenn der Top-Level-Kontext von der gleichen Origin wie die Seite stammt.

  • ALLOW-FROM origin – Die Seite wird nur dann in Frames dargestellt, wenn der Top-Level-Kontext von der Origin origin stammt. Dieser Wert wird zurzeit noch nicht von allen Browsern unterstützt.

Der X-Frame-Options-Header verhindert Clickjacking-Angriffe auch dann, wenn die angegriffene Webseite in einem iframe mit sandbox-Attribut geladen wird.

Es gibt jedoch eine unschöne Einschränkung des Schutzes bei der Verwendung von SAMEORIGIN: Je nach Implementierung der Prüfung der Origin und Aufbau der zu schützenden Seite kann der Schutz unter Umständen umgangen werden [4]. Wird nur die Top-Level-Origin geprüft, kann jede Website angegriffen werden, die das Einbinden fremder Inhalte in iframes erlaubt (Abb. 1). Der Angreifer kann dann seine bösartige Seite (in Abbildung 1 blau dargestellt) in einen iframe in der anzugreifenden Seite einbinden und diese dann darin für den Angriff erneut laden (rot dargestellt).

Der Browser vergleicht die Origin der zu ladenden Seite (rot) mit der Origin der äußersten Seite (schwarz), stellt fest, dass SAMEORIGIN erfüllt ist, und erlaubt das Einbinden in die Seite des Angreifers (blau) und damit den Angriff.

Wenn Ihre zu schützende Website fremde Inhalte in iframes einbindet, können Sie sie also nicht über „X-Frame-Options: SAMEORIGIN“ vor Clickjacking-Angriffen schützen.

In Zukunft schützt auch die Content Security Policy (CSP)

Die vom W3C standardisierte Content Security Policy (CSP [5], [6]) diente in erster Linie dazu, die Verwendung von Skripten im Quelltext der Seite (Inline-Skripten) zu verbieten. Die „User Interface Security Directives for Content Security Policy“ [7] nutzen die CSP zur Abwehr von Clickjacking-Angriffen. Über die darin definierte Anweisung frame-options kann der Server festlegen, ob die ausgelieferten Daten in einem iframe, Frame oder Ähnlichem dargestellt werden dürfen oder nicht.

Außerdem gibt es weitere Anweisungen zur Abwehr von Angriffen auf/über das Benutzerinterface. Da sich die Spezifikation noch in der Entwicklung befindet, wird sie bisher kaum genutzt. In Firefox kann stattdessen die nicht standardisierte Anweisung frame-ancestors verwendet werden [8], die dann natürlich von anderen Browsern nicht beachtet wird.

eilers_ui_1.tif_fmt1.jpgAbb. 1: Website mit geschachtelten iframes

Das klassische Beispiel aus 2008 ...

Jeremiah Grossman und Robert Hansen haben als Beispiel für einen Clickjacking-Angriff die Sicherheitseinstellungen für den Flash Player in Adobes Einstellungsdialog „Global Settings Manager“ manipuliert [9]. Der Benutzer muss für dessen Nutzung nicht authentifiziert sein und der URL ist immer gleich, was den Angriff und damit das Beispiel erleich...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang