Tabnabbing und Clickjacking: Die UI-Angriffe, die du nie bemerkst

Was Tabnabbing wirklich macht

Ein Tab kann sich auch im Hintergrund neu laden. Das ist keine Sicherheitslücke, sondern eine bewusst eingebaute Funktion. Wer eine Seite offen hat und auf eine neue E-Mail wartet, soll benachrichtigt werden, auch wenn der Tab gerade nicht sichtbar ist. Genau das macht sich Tabnabbing zunutze.

Der Angriff läuft so ab. Du öffnest eine harmlos wirkende Seite, lässt sie offen und wechselst zu einem anderen Tab. Das Skript der ersten Seite merkt über die Page Visibility API oder einen Focus-Handler, dass du weg bist, und wartet ein paar Minuten. Danach tauscht es Titel, Favicon und HTML der Seite aus. Was eben noch ein Artikel war, sieht jetzt aus wie ein Google-, Microsoft- oder GitHub-Login.

Kommst du zurück, blickst du auf einen scheinbar vertrauten Login in einem Tab, den du selbst aufgemacht hast. In der Adressleiste steht zwar weiter die URL der ursprünglichen Seite, aber kaum jemand schaut da hin. Das Formular schickt deine Eingaben an den Angreifer und leitet dich anschliessend auf das echte Google weiter. Beim zweiten Login denkst du dann, der erste Versuch sei einfach danebengegangen.

Clickjacking: Ein Button, zwei Identitäten

Clickjacking ist ein anderer UI-Trick. Der Angreifer packt eine echte Seite (etwa eine Passwort-ändern-Seite oder ein „Geld senden"-Formular) in einen unsichtbaren Iframe und legt darüber einen verlockenden Köder wie „Klicken und Preis gewinnen". Der Nutzer glaubt, auf den Köder zu klicken, aber der Klick landet in Wirklichkeit auf dem echten Button darunter. Für den Browser ist der Klick autorisiert, weil er es technisch ist.

Der Klassiker ist ein Facebook-Like-Button in einem Iframe, der von einem Spielelement verdeckt wird. Die Opfer liken unbemerkt eine Seite, die sie nie gesehen haben. Richtig brenzlig wird es, wenn der Button darunter das „Confirm" einer OAuth-Zustimmung oder das „Send transaction" einer dezentralen App ist. Beide Varianten sind in freier Wildbahn schon mehrfach ausgenutzt worden.

Verteidigen müssen sich an dieser Stelle die Seitenbetreiber. Der X-Frame-Options-Header und frame-ancestors in der Content-Security-Policy untersagen anderen Seiten, eine vertrauenswürdige Seite in einen Iframe einzubetten. Die grossen Plattformen haben das gut im Griff. Seiten, die den Header weglassen, bleiben angreifbar, und gerade bei neueren Web3-Anwendungen klaffen hier seit jeher Lücken.

Reverse Tabnabbing über window.opener

Eine verwandte Technik nennt sich Reverse Tabnabbing. Sie macht sich zunutze, dass ein frisch geöffneter Tab über window.opener Zugriff auf die Seite hat, die ihn aufgerufen hat. Schmuggelt ein Angreifer seinen Link auf deine Seite, kann er aus dem neuen Tab heraus die Ursprungsseite umleiten. Du wechselst irgendwann zurück und landest auf einer Phishing-Kopie der Seite, auf der du eigentlich warst.

Der Schutz heisst rel="noopener" an jedem externen Link, und moderne Browser setzen das inzwischen automatisch bei Links, die in einem neuen Tab aufgehen. Damit ist der klassische Vektor zu. Foren und Seiten mit User-Generated Content bleiben aber anfällig, sobald sie Nutzerinhalte unsauber rendern.

Warum diese Angriffe überleben

UI-Angriffe haben drei Eigenschaften, die sie langlebig machen. Erstens sind sie meist nur subtile Verstösse gegen Konventionen, nicht gegen technische Regeln. Einen Tab neu zu zeichnen ist eine reguläre Browserfunktion, einen Iframe einzubetten ebenso. Zweitens setzen sie auf visuelle und situative Gewohnheiten, die Nutzer gar nicht aktiv überwachen, weil ihnen nicht einmal bewusst ist, dass sie diesen Konventionen folgen.

Drittens sind sie billig. Ein Tabnabber ist eine HTML-Datei mit ein paar Dutzend Zeilen JavaScript. Angreifer fahren parallel Dutzende Varianten aus, kombinieren sie mit Malvertising oder SEO-Missbrauch und verlieren nichts, wenn eine davon auffliegt.

Was du heute dagegen tun kannst

Den Grossteil der Arbeit übernehmen Browser und Seitenbetreiber. Für dich bleiben ein paar Verhaltensregeln, die spürbar helfen.

1. 1

   Misstraue Logins in unerwarteten Tabs

   Verlangt ein Tab plötzlich einen Login, mit dem du nicht gerechnet hast, schliesse ihn. Öffne den Dienst lieber über ein Bookmark neu.
2. 2

   Prüfe die URL bei jedem Login-Formular

   Die Adressleiste überlebt Tabnabbing. Eine angebliche Gmail-Seite auf einer fremden Domain ist sofort als Fake erkennbar.
3. 3

   Halte Sitzungen kurz

   Je länger ein Tab offen bleibt, desto mehr Gelegenheit hat er, seinen Inhalt heimlich auszutauschen. Für sensible Dienste sind lange Hintergrund-Tabs keine gute Idee.
4. 4

   Kritische Aktionen in einer eigenen isolierten Session

   Wenn du eine OAuth-Zustimmung erteilst, eine Transaktion signierst oder Accounts verknüpfst, mach das in einer Session, in der sonst nichts läuft. Damit fallen alle bekannten UI-Tricks weg, weil daneben kein zweiter Tab manipuliert werden kann.