Skip to content

Clickjacking-Angriffe verhindern - der aktuelle Stand der Dinge

Ab dieser Folge geht es um neue Entwicklungen rund ums Clickjacking. Los geht es mit dem aktuellen Stand der Gegenmaßnahmen. Die ursprünglich beschriebenen Gegenmaßnahmen haben inzwischen einige Nachteile.

Der Klassiker: Framebuster

Die erste vorgeschlagene Gegenmaßnahme waren Framebuster, zum Beispiel nach dem Muster

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

So ein Framebuster setzt zuerst einmal voraus, dass JavaScript im Browser der Benutzer eingeschaltet ist, was heutzutage meist der Fall ist. Es gibt aber verschiedene Möglichkeiten, den Framebuster zu umgehen. 2010 haben Gustav Rydstedt, Elie Bursztein und Dan Boneh von der Stanford University und Collin Jackson von der Carnegie Mellon University die Framebuster der Alexa Top-500 Websites auf ihre Wirksamkeit getestet. Das Ergebnis: Alle Framebuster lassen sich auf die eine oder andere Art und in mehr oder weniger vielen Browsern umgehen ("Busting Frame Busting - a Study of Clickjacking Vulnerabilities on Popular Sites" als PDF).

An diesem grundsätzlichen Problem hat sich seitdem nichts geändert, ganz im Gegenteil ist eine weitere Möglichkeit hinzu gekommen, die Framebuster zu umgehen: Mit dem in HTML5 eingeführten sandbox-Attribut für iframes 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.

Trotzdem sollten Sie weiterhin einen Framebuster einsetzen, er schadet ja nicht. Er bietet nur keinen wirklich zuverlässigen Schutz mehr. Daher muss ein zusätzlicher Schutz her, und den bietet ein HTTP-Header:

Aktuell: Der X-FRAME-OPTIONS-HTTP-Header

Der X-FRAME-OPTIONS-HTTP-Header wurde erstmals von Michal Zalewski auf der whatwg-Mailingliste als "X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes"-Header vorgeschlagen. Im Internet Explorer 8 wurde dann ein Clickjacking-Schutz implementiert, der über den "X-FRAME-OPTIONS"-Header in der HTTP-Response gesteuert wird. Wie der Header funktioniert, wurde im IEInternals-Blog genauer beschrieben. Der Header wird inzwischen von allen Browsern unterstützt, und seit Oktober 2013 gibt es auch einen RFC für den Header, RFC 7034.

Für den Header wurden drei mögliche Werte definiert:

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 zur Zeit noch nicht von allen Browsern unterstützt.

Der X-FRAME-OPTIONS-HTTP-Header verhindert Clickjacking-Angriffe auch dann, wenn die angegriffene Webseite in einem iframe mit sandbox-Attribut geladen wird. Sofern er den Webbrowser erreicht und nicht vorher zum Beispiel von einem Proxy ausgefiltert wird (was allerdings nur noch selten, wenn überhaupt, vorkommen sollte).

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. Wird nur die Top-Level-Origin geprüft, kann jede Website angegriffen werden, die das Einbinden fremder Inhalte in iframes erlaubt. Der Angreifer kann dann seine bösartige Seite (unten blau dargestellt) in einen iframe in der anzugreifende Seite einbinden und diese dann darin für den Angriff erneut laden (rot dargestellt):

¦------------------------------------------¦
¦ Opfer-Seite                              ¦
¦                                          ¦
¦  ¦------------------------------¦        ¦
¦  ¦ iframe mit Angreifer-Seite   ¦        ¦
¦  ¦                              ¦        ¦
¦  ¦ ¦------------------------¦   ¦        ¦ 
¦  ¦ ¦iframe mit Opfer-Seite  ¦   ¦        ¦
¦  ¦ ¦                        ¦   ¦        ¦
¦  ¦ ¦------------------------¦   ¦        ¦ 
¦  ¦                              ¦        ¦
¦  ¦------------------------------¦        ¦
¦                                          ¦
¦------------------------------------------¦

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.

Als weiteren Schutz vor Clickjacking-Angriffen kann in Zukunft die Content Security Policy verwendet werden.

Zukunftsmusik: Die Content Security Policy

Die Content Security Policy (CSP) wird vom W3C standardisiert (Version 1.0, Version 1.1) und diente in erster Linie dazu, die Verwendung von Skripten im Quelltext der Seite (d.h. Inline-Skripten) zu verbieten. Die User Interface Security Directives for Content Security Policy 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. Die dann natürlich von anderen Browsern nicht beachtet wird.

Fazit

Zur Zeit bietet die Kombination aus Framebuster und X-FRAME-OPTIONS-HTTP-Header (mit den jeweils genannten Einschränkungen) den besten Schutz vor Clickjacking-Angriffen. Eigentlich sogar den einzigen Schutz, sofern Sie nicht jede einzelne Funktion ihrer Website über eine Nachfrage und ein CAPTCHA schützen wollen, was zur Zeit die einzige mögliche Alternative ist. Für kritische Aktionen sollten Sie so einen zusätzlichen Schutz aber sicherheitshalber implementieren.

In größerer Anzahl sind solche "Wollen Sie das wirklich? Dann lösen Sie bitte folgendes CAPTCHA:"-Nachfragen aber gut dazu geeignet, die Benutzer zu vergraulen. Was die Sicherheit der Website natürlich ebenfalls extrem erhöhen würde, denn eine Website ohne Benutzer ist für die Cyberkriminellen natürlich uninteressant. Letztere ist zwar wunderbar, die Voraussetzung will man aber normalerweise ganz und gar nicht.

Sobald die CSP 1.1 mit frame-options-Anweisung standardisiert und implementiert wurde, steht damit ein weiterer Schutz zur Verfügung, den Sie dann natürlich ebenfalls verwenden sollten. Selbst wenn diese Anweisung vielleicht anfangs nur in einem einzigen oder wenigen Browsern implementiert wird, lohnt sich ihr Einsatz, denn er reduziert auf jeden Fall die Anzahl möglicher Opfer eines Angriffs.

In der nächsten Folge werden weitere neue Entwicklungen rund ums Clickjacking beschrieben.

Carsten Eilers

Update 13.5.2015
Aus Anlass des 5jährigen Blog-Jubiläums habe ich alle Clickjacking-Artikel zusammengefasst, überarbeitet, ergänzt und auf den aktuellen Stand gebracht. Das Ergebnis ist ein (natürlich kostenloses) eBook im ePub- und PDF-Format: 5 Jahre Blog - Als Special: "Clickjacking"-eBook
Ende des Updates vom 13.5.2015


Übersicht über alle Artikel zum Thema

Clickjacking - Angriffe auf Seiten ohne Schwachstellen
Clickjacking - Auch komplizierte Aktionen sind möglich
Clickjacking - Framebuster oder HTTP-Header verhindern Angriffe
Der Angriff der Clickjacking-Würmer, "Likejacking" und "Buttonjacking"
Clickjacking - "Likejacking" unter die Haube geguckt
Clickjacking - The next Generation
Clickjacking - Drag&Drop-Angriffe und weitere Neuigkeiten
Cookiejacking - Keksdiebe im Internet Explorer
Likejacking - Facebook im Visier der Cyberkriminellen
Clickjacking - Gute und Schlechte Nachrichten
Standpunkt: Clickjacking gegen Flash, urchin.js und Duqu - nichts als Wiederholungen!
Neue Angriffe auf Webanwendungen über Clickjacking und Cookies
Clickjacking-Angriffe verhindern - der aktuelle Stand der Dinge
Clickjacking: Cross Origin Resource Jacking und ein Clickjacking-BeEF-PlugIn
Clickjacking: "Zaubertricks" ermöglichen Likejacking und mehr
Dieses und Jenes zum Clickjacking
5 Jahre Blog - Als Special: "Clickjacking"-eBook

Trackbacks

Dipl.-Inform. Carsten Eilers am : Neues eBook: "JavaScript Security - Sicherheit im Webbrowser"

Vorschau anzeigen
Bei entwickler.press ist mein eBook über die Sicherheit von JavaScript erschienen: &quot;JavaScript Security - Sicherheit im Webbrowser&quot; Wie der Name schon sagt geht es um die Sicherheit von JavaScript (und HTML5, dass ja viele neue JavaSc

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Formular-Optionen

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!