Clickjacking-Problem in Browsern bleibt bestehen

Eine neue Demo zeigt, dass Browser-Hersteller immer noch keinen wirksamen Schutz vor sogenannten Clickjacking-Angriffen gefunden haben. Beim Clickjacking schiebt eine manipulierte Webseite beispielsweise einen durchsichtigen iFrame unter den Mauszeiger. Im Glauben, etwas auf der angezeigten Seite anzuklicken, klickt der Anwender jedoch auf Elemente in einem durchsichtigen iFrame einer anderen Seite, beispielsweise Buttons in Weboberflächen.

Die nun veröffentlichte Demo des Israelis Narkolayev Shlomi führt das Problem eindrucksvoll für Facebook vor: In der Annahme auf einer Webseite einen harmlosen Link zu klicken, fügt der Klick stattdessen eine App zum Facebook-Konto hinzu. Dazu muss das Opfer zwar bereits an Facebook angemeldet sein, das ist aber kein seltenes Szenario.

Ähnliche Angriffe gab es im letzten Jahr beispielsweise auch auf Twitter. Derartige Clickjacking-Attacken ähneln zwar von der Auswirkung Cross-Site-Request-Forgery-Attacken (XSRF). Es handelt sie aber um grundsätzlich verschiedene Methoden (siehe dazu Details über XSRF). Clickjacking lässt sich nicht so ohne Weiteres unterbinden. Bei XSRF genügt es, dass der Server ein nicht erratbares, nutzerbezogenes Token in die URL einbettet, um Angriffe generell unwirksam zu machen. Bei Clickjacking-Attacken funktioniert dies durch Servereinstellungen nicht.

US-Medienberichten zufolge will Facebook gegen derartige Angriff mit Blacklists vorgehen, um die Verbreitung von Links zu präparierten Webseiten im eigenen System zu verhindern. Das löst das eigentliche Problem jedoch nicht. Grundsätzlich sind viele andere Webseiten und Anwender von dem seit nunmehr über einem Jahr bekannten Clickjacking-Problem betroffen.

Unter Firefox erkennt das NoScript -Plug-in Clickjacking-Angriffe und verhindert sie mit seinem ClearClick-Schutz. Grundsätzlich ist auch der Internet Explorer für Clickjacking anfällig. Microsoft hat jedoch in Version 8 des Internet Explorer eine Anti-Clickjacking-Funktion eingeführt, die allerdings nur passiv arbeitet. Der Webserver der vertrauenswürdigen Seite muss den Header-Zusatz: "X-FRAME-OPTIONS: DENY" an den Browser senden, um zu verhindern, dass die Seite in einem Frame dargestellt wird. Damit lässt sich dann auch nicht mehr (unsichtbar/durchsichtig) unter die präparierte Webseiten "schieben".

Solange eine Seite dies nicht signalisiert, arbeitet der Schutz jedoch nicht. Wieviele Betreiber von Webservern oder Entwickler von Weboberflächen bereits den proprietären Header mitsenden, ist unbekannt.

Siehe dazu auch:

• Twitter-Wurm "Don't Click" verbreitet sich im Twitter-Space
• Populäre Browser weiterhin für Clickjacking-Angriffe anfällig

(dab)