Tabnabbing und Clickjacking: Täuschung auf dem Bildschirm

Wie ein Tab sein Aussehen ändern kann

Eine Seite kann nach dem Laden ihren eigenen Inhalt, Titel und ihr Symbol ändern. Über die Page Visibility API kann sie zudem erkennen, ob ihr Tab sichtbar ist. Diese Funktionen ermöglichen normale Anwendungen, doch eine bösartige Seite kann damit einen vertrauten Dienst nachahmen.

Ein möglicher Ablauf: Du öffnest eine vom Angreifer betriebene oder kompromittierte Seite und wechselst zu einem anderen Tab. Ein Skript erkennt, dass die Seite im Hintergrund ist, und zeigt später eine gefälschte Anmeldeaufforderung. Es kann HTML und Seitensymbol ändern, aber nicht die tatsächliche Herkunft in der Adressleiste. Wann und wie die Täuschung erscheint, bestimmt der Angriffscode. Eine feste Wartezeit gibt es nicht.

Gibst du dort ein Passwort oder einen Einmalcode ein, kann die Seite die Daten an den Angreifer schicken. Sie kann dich danach zum echten Dienst weiterleiten, damit der Vorgang weniger auffällt. Prüfe die Adressleiste, bevor du Zugangsdaten eingibst, besonders wenn ein Tab unerwartet eine Anmeldung verlangt. Ein an die echte Webadresse gebundener Passkey kann dieser Art von Zugangsdatenklau widerstehen.

Clickjacking mit einer eingebetteten Seite

Bei einem Clickjacking-Versuch bettet ein Angreifer eine rechtmässige Website in einen Iframe ein und platziert einen Köder so, dass ein Klick auf einem Bedienelement der eingebetteten Seite landet. Die Zielseite muss diese Einbettung zulassen, und das Bedienelement muss im aktuellen Zustand des Nutzers eine Aktion ermöglichen. MDN zeigt, wie das funktioniert. Der Angreifer erhält dadurch keinen beliebigen Zugriff auf jedes Konto oder jede Transaktion.

Ein klassisches Beispiel ist ein Social-Media-Button, der unter einem Spielelement verborgen ist. Wer das Spielelement anklickt, betätigt ungewollt den Button. Die Folgen hängen davon ab, was die eingebettete Seite erlaubt. Sensible Aktionen können eine neue Bestätigung verlangen; Regeln für seitenübergreifende Cookies können verhindern, dass der Iframe angemeldet ist. Geh nicht davon aus, dass eine Freigabe- oder Zahlungsseite eingebettet werden kann, nur weil sie einen Button hat.

Die wichtigste Abwehr liegt bei den Seitenbetreibern. Die CSP-Anweisung frame-ancestors begrenzt, welche Websites eine Seite einbetten dürfen. X-Frame-Options bietet eine einfachere Einschränkung für ältere Browser. Websites, die Einbettung benötigen, können vertrauenswürdige übergeordnete Seiten zulassen und folgenreiche Aktionen zusätzlich bestätigen lassen. Fehlende Einschränkungen können eine Angriffsmöglichkeit schaffen. Ob sie ausnutzbar ist, hängt von der Seite und ihren weiteren Schutzfunktionen ab.

Wann window.opener relevant ist

Reverse Tabnabbing setzt eine Verbindung zum ursprünglichen Fenster voraus. Öffnet eine Seite ein weiteres Fenster und bleibt window.opener verfügbar, kann die neue Seite das erste Fenster möglicherweise auf eine Phishing-Seite umleiten. Regeln für unterschiedliche Webadressen verhindern zwar, dass sie den Inhalt des ersten Fensters liest; eine Navigation kann dennoch möglich sein, wie MDN erklärt.

Moderne Links mit target="_blank" verhalten sich standardmässig so, als hätten sie rel="noopener". window.opener bleibt dadurch leer, ausser ein Opener wird ausdrücklich angefordert. MDN dokumentiert diesen Standard. Skripte mit window.open() sollten bei Bedarf weiterhin noopener anfordern. Ein Link zu einer fremden Website ist nicht automatisch ein Reverse-Tabnabbing-Risiko.

Welche Bedingungen diese Angriffe brauchen

Diese Angriffe missbrauchen gewöhnliche Webfunktionen zur Täuschung. Eine Seite kann ihr Aussehen ändern, und manche Websites erlauben Einbettungen bewusst. Das Risiko hängt von der tatsächlichen Herkunft der Seite, ihren Einbettungsregeln, dem verfügbaren Kontozustand und deiner nächsten Handlung ab. Ein vertrautes Aussehen beweist nicht, dass die Seite zum nachgeahmten Dienst gehört.

Browserstandards haben einige frühere Lücken geschlossen, insbesondere bei Links, die einen neuen Tab öffnen. Websites müssen dennoch passende Einbettungsregeln festlegen, und Nutzer sollten vor Anmeldungen oder Freigaben die Webadresse prüfen. Der OWASP-Leitfaden zu Clickjacking nennt SameSite-Cookies und Bestätigungsschritte als weitere Schutzschichten. Weder eine einzelne Verhaltensregel noch ein einzelner Antwort-Header verhindert jede Täuschung der Oberfläche.

Schutz für Nutzer und Websites

Nutze die Schutzfunktionen des Browsers und der Website, und prüfe die Seite vor einer wichtigen Handlung.

1. 1

   Unerwartete Anmeldeseiten prüfen

   Wenn ein Tab plötzlich eine Anmeldung verlangt, schau auf seine Webadresse. Im Zweifel öffnest du den Dienst separat über ein vertrautes Lesezeichen oder eine selbst eingegebene Adresse.
2. 2

   Die Herkunft prüfen, nicht nur das Aussehen

   Die Adressleiste zeigt, wo sich der Tab wirklich befindet. Eine ähnlich aussehende Domain ist nicht der beabsichtigte Dienst. Wo verfügbar, können an die richtige Webadresse gebundene Passkeys den Diebstahl von Zugangsdaten über gefälschte Anmeldeseiten erschweren.
3. 3

   Folgenreiche Aktionen im Kontext prüfen

   Bevor du einen Zugriff oder eine Zahlung freigibst, prüfe, welche Website darum bittet und welche Handlung sie beschreibt. Seitenbetreiber sollten die Einbettung sensibler Seiten begrenzen und geeignete Bestätigungen verlangen.
4. 4

   Isolation für ihren tatsächlichen Schutz nutzen

   Eine Browser.lol-Session kann Webinhalte von deinem lokalen Browser trennen. Sie bestätigt nicht, dass eine Seite echt aussieht, und hindert eine bösartige Seite im entfernten Browser weder daran, ihr Aussehen zu ändern, noch daran, einen erlaubten Iframe zu nutzen. Prüfe auch dort die Webadresse und die angeforderte Handlung.