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.
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 : Drucksache: PHP Magazin 6.2014 - Wie die Grafikfunktionen von HTML5 Ihre Sicherheit und Privatsphäre gefährden
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Neues eBook: "JavaScript Security - Sicherheit im Webbrowser"
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Die Universal Cross-Site Scripting (UXSS) Schwachstelle im Internet Explorer 10 und 11
Vorschau anzeigen