Was ist Clickjacking?

Clickjacking, auch UI Redressing genannt, überlagert eine sichtbare Benutzeroberfläche mit einer transparenten oder getarnten fremden Seite. Der Nutzer glaubt, auf ein harmloses Element zu klicken, betätigt tatsächlich aber eine Schaltfläche der eingebetteten Anwendung.

Wie funktioniert Clickjacking?

Der Angreifer lädt die Zielseite in einem iframe, positioniert sie mit CSS exakt über Lockelementen und setzt ihre Transparenz nahezu auf null. Maus- oder Touch-Eingaben treffen dadurch den Frame. Ist das Opfer in der Zielanwendung angemeldet, kann der Klick eine authentifizierte Aktion auslösen. Anders als bei CSRF ist eine echte Benutzerinteraktion erforderlich; dafür kann Clickjacking auch Aktionen mit nicht vorhersagbaren Formularwerten beeinflussen.

Welche Varianten gibt es?

Welche Auswirkungen sind realistisch?

Mögliche Folgen sind das Ändern von Einstellungen, Erteilen von Berechtigungen, Aktivieren einer Kamera, Auslösen einer Zahlung oder Verbinden eines Kontos. Das Risiko hängt davon ab, welche Funktion mit wenigen vorhersehbaren Interaktionen erreichbar ist und ob zusätzliche Bestätigung verlangt wird. Eine beliebige einbettbare Informationsseite ist daher nicht automatisch ein relevanter Sicherheitsbefund.

Wie verhindert man Clickjacking?

• Content-Security-Policy: frame-ancestors 'none' verhindert jede Einbettung.
• frame-ancestors 'self' oder eine enge Ursprungsliste erlaubt bewusst benötigte Frames.
• X-Frame-Options: DENY oder SAMEORIGIN unterstützt ältere Browser.
• Kritische Aktionen verlangen verständliche, kontextgebundene Bestätigung oder erneute Authentifizierung.
• Cookie-Attribute und CSRF-Schutz begrenzen kombinierte Angriffspfade.

CSP frame-ancestors ist die flexible moderne Kontrolle. Sie muss als HTTP-Response-Header ausgeliefert werden; ein Meta-Tag ist dafür nicht ausreichend. Werden Partnerportale bewusst erlaubt, sollten nur exakte vertrauenswürdige Ursprünge eingetragen werden.

Konfigurationsbeispiel: Einbettung per Response-Header sperren

Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENY

Soll eine Seite bewusst in einem Partnerportal erscheinen, wird bei frame-ancestors statt einer Wildcard nur dessen exakter vertrauenswürdiger Ursprung eingetragen. Die Header müssen auch auf Fehler-, Login- und sensiblen Unterseiten gesetzt sein.

Warum reicht Frame-Busting nicht?

Ältere Seiten nutzen JavaScript wie if (top !== self), um Frames aufzubrechen. Solche Skripte können durch Sandbox-Attribute, deaktiviertes JavaScript, verschachtelte Frames oder fehlerhafte Browserlogik umgangen werden. Browserseitig erzwungene Header greifen früher und verlässlicher. JavaScript kann höchstens eine zusätzliche Schicht sein.

Wie wird Clickjacking getestet?

Tester prüfen Header auf allen relevanten Antworten, nicht nur auf der Startseite. Anschließend versuchen sie, sensible Funktionen in einer fremden Testseite einzubetten und die Bedienelemente präzise zu überlagern. Mehrstufige Dialoge, mobile Ansichten, unterschiedliche Subdomains und absichtlich erlaubte Partnerframes werden separat betrachtet. Der Nachweis sollte eine ungefährliche Testaktion verwenden.