Qué es el clickjacking y cómo protegerse
El clickjacking (también llamado UI redressing) es un ataque web
en el que un atacante superpone una página legítima (invisible para la víctima) sobre su
propio sitio malicioso, de modo que el usuario hace clic en elementos ocultos creyendo que
interactúa con la interfaz visible. En el fondo es un engaño de capas.
Por qué existe el clickjacking: la raíz del problema
Los navegadores permiten que cualquier página cargue otra URL dentro de un elemento
<iframe>. Cuando la página víctima no restringe este comportamiento,
el atacante puede incrustarla en su propio sitio y hacer que el iframe sea
completamente transparente (opacity: 0) pero siga siendo interactivo.
La sesión de la víctima, incluidas las cookies de autenticación, viaja con la petición al
servidor real, así que el usuario ya está autenticado dentro de ese iframe invisible.
El problema técnico de fondo es que los navegadores no impusieron por defecto restricciones
sobre qué sitios pueden incrustar a otros mediante iframes. Durante años, la decisión quedó
en manos del servidor incrustado, y muchos no la configuraban.
La vulnerabilidad está catalogada por MITRE como
CWE-1021: Improper Restriction of Rendered UI Layers or Frames
.
Cómo funciona: anatomía del ataque
El flujo básico es este: el atacante construye una página maliciosa que incrusta
el sitio víctima en un iframe invisible. Sobre ese iframe coloca botones,
imágenes o formularios propios que la víctima ve y con los que pretende interactuar.
Al hacer clic sobre ellos, el evento de clic llega al iframe oculto en las coordenadas
exactas donde está, por ejemplo, el botón «Confirmar transferencia» o «Me gusta».
Ejemplo de iframe transparente superpuesto
El siguiente fragmento muestra la estructura HTML que usa un atacante. La página víctima
se carga en el iframe con opacidad cero; encima se coloca un botón señuelo con
posicionamiento absoluto para alinearlo con el botón real de la página oculta.
<!-- Página del atacante: ataque-demo.html -->
<!DOCTYPE html>
<html lang="es">
<head>
<style>
/* Contenedor de posicionamiento */
#wrapper {
position: relative;
width: 900px;
height: 600px;
}
/* Iframe transparente que carga la página víctima */
#victima {
position: absolute;
top: 0;
left: 0;
width: 100%;
height: 100%;
opacity: 0; /* invisible pero interactivo */
z-index: 2; /* encima del botón señuelo */
}
/* Botón señuelo visible para la víctima */
#senluelo {
position: absolute;
top: 340px; /* alineado con el botón real del iframe */
left: 420px;
z-index: 1;
padding: 12px 24px;
background: #28a745;
color: #fff;
font-size: 16px;
cursor: pointer;
border: none;
border-radius: 4px;
}
</style>
</head>
<body>
<div id="wrapper">
<!-- La página real, invisible -->
<iframe id="victima"
src="https://banco-victima.example.com/transferir?importe=500&destino=atacante"
scrolling="no">
</iframe>
<!-- Lo que la víctima cree que pulsa -->
<button id="senluelo">¡Haz clic para ganar un premio!</button>
</div>
</body>
</html>
Cuando el usuario pulsa «¡Haz clic para ganar un premio!», el clic atraviesa el
z-index y llega al iframe oculto, ejecutando la transferencia si el usuario
tiene sesión abierta en ese banco.
«Clickjacking is an interface-based attack in which a user is tricked into clicking on
actionable content on a hidden website by clicking on some other content in a decoy website.»
Variantes del clickjacking
Likejacking
Variante dirigida a redes sociales. El atacante superpone el botón de «Me gusta» de
Facebook (o equivalente) sobre un contenido atractivo. La víctima cree que hace clic en
un botón de la página señuelo y, en realidad, da like a una página que el atacante quiere
viralizar. Fue frecuente sobre todo entre 2010 y 2014.
Cursorjacking
Aquí el engaño no está solo en el destino del clic, está en la posición visual del cursor.
Con CSS o Flash (ya obsoleto), el atacante mostraba un cursor falso desplazado varios
píxeles del cursor real del sistema. El usuario creía estar haciendo clic donde apuntaba
el cursor visible, pero el clic real caía en otro elemento.
Filejacking
Abusa de diálogos de apertura de archivos del sistema operativo incrustados en el
navegador para hacer que el usuario seleccione y suba un fichero que el atacante eligió,
sin que la víctima lo sepa.
Clickjacking + XSS (combinado)
PortSwigger documenta laboratorios donde el clickjacking se encadena con XSS basado en
DOM: la víctima hace clic en el elemento oculto, lo que activa un XSS en el sitio legítimo.
Esta combinación puede escalar privilegios o robar tokens.
Ejemplo práctico en laboratorio (PortSwigger Academy)
Importante: practica estas técnicas únicamente en entornos de
laboratorio autorizados. El laboratorio oficial gratuito de
PortSwigger — Basic clickjacking with CSRF token protection
es el entorno que recomiendo: te da una cuenta, una tienda vulnerable y el objetivo
de hacer que el usuario cambie su dirección de email sin saberlo.
El flujo del laboratorio es este:
-
Accedes con las credenciales que te facilita el lab (
wiener:peter). -
Abres el Burp Suite Exploit Server integrado en el lab y pegas el
HTML del iframe superpuesto apuntando al formulario «Update email» de la tienda. -
Ajustas
topyleftdel botón señuelo hasta que coincida
con el botón «Update email» real (puedes usaropacity: 0.5durante el
ajuste y poneropacity: 0para la entrega final). -
Pulsas «Deliver exploit to victim»: el bot del lab hace clic en tu señuelo y el email
queda cambiado. El lab se marca como resuelto.
Para profundizar, consulta nuestra guía completa:
Qué es Burp Suite y cómo usarlo.
Cómo prevenir el clickjacking
La defensa se aplica en el servidor: hay que indicarle al navegador que
la página no puede ser incrustada por terceros. Existen tres mecanismos complementarios.
1. Content-Security-Policy: frame-ancestors (recomendado)
Es la defensa moderna definida en CSP nivel 2. Reemplaza a X-Frame-Options
con más flexibilidad y mejor soporte en CSP reporting.
# No permitir ningún iframe externo
Content-Security-Policy: frame-ancestors 'none';
# Solo permitir que el propio origen incruste la página (equivale a SAMEORIGIN)
Content-Security-Policy: frame-ancestors 'self';
# Permitir solo un dominio específico de confianza
Content-Security-Policy: frame-ancestors https://dashboard.tuempresa.com;
2. X-Frame-Options (legacy pero con cobertura universal)
Cabecera más antigua, soportada desde IE8. No admite wildcards ni múltiples orígenes,
pero cubre navegadores muy antiguos donde CSP no está disponible.
# Nunca en un iframe
X-Frame-Options: DENY
# Solo en iframes del mismo origen
X-Frame-Options: SAMEORIGIN
Según
OWASP — Clickjacking Defense Cheat Sheet
,
conviene usar ambas cabeceras en paralelo para máxima compatibilidad.
3. Frame-busting JavaScript (respaldo, no fiable por sí solo)
Antes de que existiera X-Frame-Options, se usaba JavaScript para detectar
si la página estaba dentro de un iframe y sacarla:
// Frame-busting clásico — usar solo como capa adicional, NUNCA como única defensa
if (window.top !== window.self) {
window.top.location = window.self.location;
}
El problema es que el atacante puede neutralizarlo usando el atributo
sandbox del iframe sin el valor allow-top-navigation,
lo que bloquea la redirección. Por esto el frame-busting solo debe ser un respaldo,
nunca la defensa principal.
4. Cookies con atributo SameSite
Configurar las cookies de sesión con SameSite=Strict o
SameSite=Lax impide que se envíen en peticiones cross-site. Con esto,
aunque el iframe se cargue, el usuario no estará autenticado dentro de él, lo
que limita mucho el daño posible.
Set-Cookie: session=abc123; SameSite=Strict; Secure; HttpOnly
Tabla comparativa de defensas
| Mecanismo | Cómo bloquea el ataque | Soporte en navegadores | Limitaciones |
|---|---|---|---|
CSP: frame-ancestors |
El navegador rechaza mostrar la página en iframes no autorizados | Chrome 40+, Firefox 33+, Safari 10+, Edge 15+ | No soportado en IE11 |
X-Frame-Options: DENY |
El navegador bloquea cualquier incrustación en iframe | Universal (IE8+, todos los modernos) | No admite múltiples orígenes; obsoleto pero útil como fallback |
| Frame-busting JS | Intenta redirigir al top si detecta estar en un iframe |
Todos (depende de JS activo) | Evadible con sandbox sin allow-top-navigation |
Cookies SameSite=Strict |
Sin sesión activa en el iframe, el atacante no puede actuar como usuario autenticado | Chrome 51+, Firefox 63+, Safari 13+ | No evita la carga del iframe; solo protege acciones autenticadas |
Errores comunes al implementar la defensa
-
Usar solo X-Frame-Options ALLOWFROM: este valor se eliminó de la
especificación y nunca tuvo soporte consistente entre navegadores. Si
necesitas permitir un origen concreto, usaCSP: frame-ancestors. -
Confiar solo en el frame-busting JavaScript: como ya se ha
explicado, el atributosandboxdel iframe puede neutralizarlo por completo. -
Aplicar la cabecera solo a la página de login: el atacante puede
apuntar a cualquier acción autenticada (cambiar email, confirmar compra, borrar cuenta).
La cabecera tiene que estar en todas las respuestas del servidor, no solo en la
portada. -
Olvidar SameSite en las cookies: muchos equipos añaden las cabeceras
anti-clickjacking pero dejan las cookies configurables sinSameSite,
y eso expone igual las acciones autenticadas si el iframe consigue cargarse. -
No probar la configuración: herramientas como
Burp Suite
o la extensión Clickjacking Tester permiten verificar en segundos si una URL
puede ser incrustada. Úsalas antes de dar una implementación por válida.
Aprende más sobre hacking web
El clickjacking es solo una de las vulnerabilidades del catálogo de amenazas
web. Para una visión más amplia, consulta:
-
OWASP Top 10: las 10 vulnerabilidades web más críticas
(el clickjacking figura en la categoría A05, Security Misconfiguration, y está relacionado con A01). -
Hacking web: guía completa para principiantes,
con XSS, SQLi, CSRF, IDOR y más. -
Curso de Hacking Web,
formación práctica con laboratorios reales.
Vídeo recomendado
Explicación en vídeo del ataque con demostraciones visuales paso a paso:
Clickjacking | ¿Qué es? | Curso gratis Web Hacking
— canal SEGURIDAD CERO (YouTube, ID: uF5liqpJ0s4).
Preguntas frecuentes
¿El clickjacking es lo mismo que el phishing?
No exactamente. El phishing engaña al usuario para que entregue datos (contraseñas,
tarjetas) en un sitio falso. El clickjacking hace que el usuario ejecute acciones en
un sitio real y legítimo sin saberlo, usando su sesión ya autenticada.
Son vectores distintos aunque ambos explotan el factor humano.
¿Afecta a todos los navegadores modernos?
Los navegadores modernos (Chrome, Firefox, Safari, Edge) respetan las cabeceras
X-Frame-Options y CSP: frame-ancestors y bloquean el iframe
cuando el servidor las envía correctamente. El problema es que muchos sitios todavía no
las configuran, dejando la vulnerabilidad abierta desde el lado del servidor.
¿Puede afectar a aplicaciones móviles?
Las apps nativas en iOS y Android no usan iframes, así que no son vulnerables en
el sentido tradicional. Las webviews integradas en apps móviles, en cambio,
pueden serlo si el servidor no envía las cabeceras protectoras.
¿Es el clickjacking difícil de explotar?
Técnicamente es sencillo: requiere solo HTML y CSS básicos. La dificultad está en
alinear con precisión el elemento oculto y en que la víctima no detecte el engaño
visual. Por eso los atacantes suelen combinarlo con ingeniería social para hacer la
página señuelo convincente.
¿Cómo puedo comprobar si mi sitio es vulnerable?
La forma más rápida es abrir las DevTools del navegador, ir a la consola e intentar
incrustar tu propio sitio en un iframe en una página local. Si el navegador lo carga
sin error, el sitio es potencialmente vulnerable. También puedes usar el escáner
pasivo de Burp Suite,
que detecta automáticamente la ausencia de cabeceras anti-clickjacking en cada respuesta
HTTP durante el proxy.
