← Zurück zum Glossar
websicherheit

Clickjacking

Angriffstechnik, bei der Nutzer durch transparente iFrames dazu gebracht werden, unsichtbare Buttons oder Links zu klicken und damit ungewollte Aktionen auszulösen.

Aktualisiert: 23. Februar 2026

Was ist Clickjacking?

Clickjacking (auch UI Redressing oder UI Redress Attack) ist eine Angriffstechnik, bei der eine legitime Webseite unsichtbar in einen transparenten <iframe> geladen und über einer täuschenden Oberfläche platziert wird. Der Nutzer glaubt, auf eine sichtbare Schaltfläche der Angreifer-Seite zu klicken — tatsächlich klickt er auf den unsichtbaren Button der darunter liegenden Originalseite. Sein Klick wird gekapert ("hijacked").

Der Angriff ist besonders heimtückisch, weil er ohne jegliche Malware auskommt und die Zielsession des Nutzers ausnutzt: Der Browser ist bereits bei der Zielseite eingeloggt. Ein einziger Klick kann genügen, um eine Überweisung zu bestätigen, eine Freundschaftsanfrage zu senden, Datenschutzeinstellungen zu ändern oder ein Administrator-Konto zu löschen.

Kurzprofil Clickjacking

Kurzprofil Clickjacking

  • Typ: Angriff (UI-Manipulation)
  • Bedrohungsklasse: OWASP A05:2021 – Security Misconfiguration
  • Betroffene Systeme: Alle Webseiten mit Aktionen, die einen einzigen Klick erfordern
  • Schweregrad: Mittel bis Hoch (abhängig von der ausgelösten Aktion)
  • Besonders gefährdet: Banking, Social Media, CMS-Adminbereiche

Wie funktioniert Clickjacking?

Der technische Aufbau ist erschreckend simpel. Ein Angreifer erstellt eine Webseite mit folgendem Grundaufbau:

<!-- Angreifer-Seite -->
<style>
  .victim-frame {
    position: absolute;
    top: 0; left: 0;
    width: 100%; height: 100%;
    opacity: 0.0;  /* vollständig transparent! */
    z-index: 2;
  }
  .decoy-button {
    position: absolute;
    top: 350px; left: 200px;  /* exakt über dem Ziel-Button positioniert */
    z-index: 1;
  }
</style>

<button class="decoy-button">Klicke hier für deinen Preis!</button>

<iframe class="victim-frame"
  src="https://bank.example.com/transfer?to=attacker&amount=1000"
></iframe>

Der <iframe> lädt die Zielseite — mit der aktiven Session des Nutzers. Da der Nutzer bei seiner Bank eingeloggt ist, ist die Überweisungsseite für den iframe gültig. Der Angreifer positioniert den Decoy-Button pixelgenau über dem unsichtbaren "Bestätigen"-Button der Bank.

Varianten:

  • Cursorjacking: Zusätzlich zur Button-Verschiebung wird auch der Cursor-Position visuell manipuliert
  • Likejacking: Facebook-Like-Buttons werden unsichtbar eingebettet, um Likes für beliebige Inhalte zu erzwingen
  • Filejacking: Datei-Upload-Dialoge werden über täuschende Elemente gelegt
  • Multi-Step-Clickjacking: Mehrere aufeinander folgende Klicks werden gekapert, z.B. für komplexe Workflows

Clickjacking in der WordPress-Praxis

Für WordPress-Seiten ist vor allem der Adminbereich ein Ziel: Ein Angreifer, der weiß, dass ein Admin gerade eingeloggt ist (z.B. durch Social Engineering oder Tracking), kann ihn auf eine präparierte Seite locken und einen einzigen Klick nutzen, um einen neuen Admin-Account zu erstellen, ein Plugin zu installieren oder Sicherheitseinstellungen zu deaktivieren.

Die Schutzmaßnahmen sind gut etabliert und einfach umzusetzen:

1. X-Frame-Options Header: Der ältere, aber weitgehend unterstützte Schutz:

X-Frame-Options: DENY          # Seite darf nirgendwo eingebettet werden
X-Frame-Options: SAMEORIGIN    # Nur von derselben Domain einbettbar

2. CSP frame-ancestors Direktive: Der modernere und flexiblere Schutz über Content-Security-Policy:

Content-Security-Policy: frame-ancestors 'none';

frame-ancestors 'none' ist äquivalent zu X-Frame-Options: DENY. Die CSP-Direktive hat Vorrang vor X-Frame-Options in modernen Browsern und erlaubt feingranularere Regeln (z.B. Einbettung nur von bestimmten vertrauenswürdigen Domains erlauben).

3. JavaScript-Framebusting (als Ergänzung):

if (window.top !== window.self) {
  window.top.location = window.self.location;
}

Dieser Code funktioniert als Fallback, ist aber durch sandbox-Attribute auf <iframe>-Elementen umgehbar und kein vollständiger Schutz.

Schutzmaßnahmen gegen Clickjacking

Schutz gegen Clickjacking

  • X-Frame-Options: DENY oder SAMEORIGIN als HTTP-Header setzen
  • Content-Security-Policy: frame-ancestors 'none' (moderner, bevorzugter Ansatz)
  • Beide Header gleichzeitig setzen für maximale Browser-Kompatibilität
  • Sensible Aktionen (Löschvorgänge, Zahlungen) durch CAPTCHA oder zusätzliche Bestätigung absichern
  • Bei WordPress: Plugin wie "Security Headers" oder Konfiguration in .htaccess / Nginx

In Nginx lässt sich der Schutz mit einer Zeile aktivieren:

add_header X-Frame-Options "DENY";
add_header Content-Security-Policy "frame-ancestors 'none';";

Was passiert bei einem erfolgreichen Clickjacking-Angriff?

Die Konsequenzen hängen vollständig davon ab, welche Aktion durch den gekaperten Klick ausgelöst wird. Im schlimmsten Fall:

  • Kontoübernahme: Bestätigung einer E-Mail-Adressenänderung → Angreifer übernimmt Passwort-Reset
  • Finanzieller Schaden: Bestätigung einer Banküberweisung oder Bestellung
  • Reputationsschaden: Massenhafte ungewollte Likes, Shares oder Kommentare in sozialen Netzwerken
  • Datenverlust: Löschung von Inhalten, Deaktivierung von Sicherheitseinstellungen

Ein real bekannt gewordener Fall: Adobe Flash Player hatte jahrelang eine Clickjacking-Anfälligkeit, die es Angreifern erlaubte, Nutzer dazu zu bringen, unbewusst die Webcam und das Mikrofon zu aktivieren.

Häufige Fragen

Was ist der Unterschied zwischen Clickjacking und CSRF? Bei CSRF (Cross-Site Request Forgery) sendet ein Angreifer eine gefälschte Anfrage im Namen des Nutzers, ohne dass dieser klicken muss — z.B. durch ein Bild mit einer URL als src. Clickjacking erfordert einen echten Klick des Nutzers, nutzt diesen aber für eine andere Aktion als der Nutzer glaubt. Beide Angriffe nutzen die aktive Session des Nutzers aus.

Schützt HTTPS gegen Clickjacking? Nein. HTTPS schützt den Übertragungsweg (Verschlüsselung und Integrität), aber nicht vor der Manipulation der Benutzeroberfläche. Ein HTTPS-geschützter <iframe> kann genauso in eine Clickjacking-Seite eingebettet werden wie ein HTTP-<iframe>. Der Schutz kommt ausschließlich von X-Frame-Options und Content-Security-Policy.

Betrifft Clickjacking auch mobile Browser? Ja, grundsätzlich schon — allerdings sind Touch-Interfaces etwas schwieriger pixelgenau zu überlagern als Desktop-Cursor. Die Gegenmaßnahmen (HTTP-Header) greifen auf mobilen Browsern genauso wie auf Desktop-Browsern.

start call_