Kurz erklärt
Bei Clickjacking lädt der Angreifer die Zielwebsite in einem unsichtbaren iFrame und legt eine Köder-Oberfläche darüber. Der Nutzer glaubt, im Cookie-Banner auf „Alle ablehnen” zu klicken – tatsächlich erteilt er App-Berechtigungen oder bestätigt eine Zahlung.
Wie funktioniert der Angriff?
Der Angreifer erstellt eine täuschend echte Website mit einem typischen Cookie-Consent-Banner. Über dem „Alle ablehnen”-Button wird die echte Zielwebsite (z.B. Banking-Portal, Social-Media-Konto) in einem transparenten iFrame positioniert – exakt so, dass ein kritischer Button („Überweisung bestätigen”, „App autorisieren”, „Konto löschen”) genau unter dem Cookie-Button liegt.
Der Nutzer ist bereits in seinem Banking- oder Social-Media-Konto eingeloggt. Er möchte nur schnell die Cookies ablehnen – ein alltäglicher, routinierter Klick. Tatsächlich klickt er aber auf den unsichtbaren Button der darunterliegenden echten Website.
Das Perfide: Cookie-Banner sind so allgegenwärtig, dass Nutzer reflexartig klicken, ohne nachzudenken. Genau diese Routine nutzen Angreifer aus.
Bekannte Fälle
- Adobe Flash: Angreifer erhielten Zugriff auf Webcams und Mikrofone durch unsichtbare Berechtigungs-Dialoge
- Facebook Likejacking: Massenhaft erzwungene „Gefällt mir”-Klicks über gefälschte Video-Play-Buttons
- Banking-Sektor: 66% der Top-20-Banken waren für Clickjacking anfällig (Okta-Studie)
- Twitter: Nutzer twitterten ungewollt Spam-Links durch manipulierte “Schließen”-Buttons
Schutzmaßnahmen
CSP frame-ancestors (empfohlen): Moderne Methode über Content Security Policy
Content-Security-Policy: frame-ancestors 'self'
frame-ancestors 'self' – Einbetten nur von eigener Domain erlaubtframe-ancestors 'none' – Absoluter Schutz, kein Einbetten möglichframe-ancestors example.com partner.com – Whitelist bestimmter Domains
X-Frame-Options (Legacy): Ältere Methode, wird von CSP abgelöst
X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
DENY – Seite kann nirgendwo eingebettet werdenSAMEORIGIN – Nur von eigener Domain einbettbar
Frame-Busting JavaScript: Nicht empfohlen, kann umgangen werden
Best Practices
- Beide Header setzen für maximale Kompatibilität:
frame-ancestors + X-Frame-Options
- Für öffentliche Websites ohne Embed-Anforderung:
frame-ancestors 'none'
- Für Websites mit Partner-Embeds: explizite Whitelist verwenden
- Niemals nur auf JavaScript-Frame-Busting verlassen
Nächste Schritte
- CSP
frame-ancestors Direktive in Security Headers einfügen
- Zusätzlich
X-Frame-Options für ältere Browser setzen
- Header-Konfiguration in Webserver (Apache, nginx) oder Edge-Service (Cloudflare)
- Mit Browser DevTools testen: Website in iFrame laden sollte fehlschlagen