El clickjacking es un ataque de UI redressing (redecoración de interfaz) en el que un atacante superpone una página legítima sobre una fachada engañosa para que la víctima crea que pulsa un elemento inofensivo cuando en realidad activa una acción sensible en otra aplicación donde mantiene sesión. La técnica no explota un fallo de memoria ni roba la cookie: manipula lo que el usuario ve frente a lo que el navegador ejecuta. El clic es real, pero su destino ha sido secuestrado mediante capas invisibles, normalmente un iframe transparente sobre un botón trampa.
Lo esencial. El clickjacking abusa de la confianza visual del usuario, no de un bug del servidor. El atacante enmarca la aplicación víctima en un iframe con opacidad cero y lo alinea sobre un cebo. Las defensas modernas se apoyan en tres capas: la cabecera
X-Frame-Options, la directivaContent-Security-Policy: frame-ancestorsy cookiesSameSite=LaxoStrictque rompen la sesión cross site. El fallo se cataloga como CWE-1021 (Improper Restriction of Rendered UI Layers or Frames).
Qué es clickjacking: mecanismo de UI redressing
El término lo acuñaron Jeremiah Grossman y Robert Hansen en 2008 para designar toda una familia de ataques de redecoración de interfaz. El patrón base necesita tres piezas simultáneas: una víctima con sesión activa en la aplicación objetivo, una aplicación que permite ser embebida en un iframe de terceros, y una página atacante que carga ese iframe de forma invisible sobre un señuelo visible.
El primer paso es enmarcar el objetivo. El atacante inserta la aplicación víctima dentro de un <iframe> en su propia web. Si el objetivo no restringe el framing, el navegador lo renderiza con normalidad, incluida la cookie de sesión de la víctima, porque el iframe carga el dominio real con las credenciales que el navegador ya tiene almacenadas.
El segundo paso es ocultar la capa real. Mediante CSS (opacity: 0, z-index elevado y posicionamiento absoluto) el iframe se vuelve transparente pero permanece por encima del contenido visible. El usuario ve una página aparentemente normal (un botón que promete un premio, un captcha falso) mientras el elemento sensible del objetivo queda alineado bajo el cursor.
El tercer paso es cosechar el clic. Cuando la víctima pulsa el señuelo, el clic atraviesa la capa transparente y llega al botón real enmarcado: aceptar un permiso, confirmar un pago o autorizar una aplicación OAuth. El servidor recibe una acción legítima, con sesión válida y gesto humano real, sin forma trivial de saber que el usuario fue engañado sobre qué pulsaba.
Ejemplo técnico: iframe invisible
El esqueleto de una prueba de concepto de clickjacking cabe en pocas líneas. Se muestra con fines didácticos y de auditoría defensiva.
<style>
iframe {
position: absolute;
top: -8px; left: -8px;
width: 500px; height: 400px;
opacity: 0.0; /* la capa real es invisible */
z-index: 2;
}
#cebo {
position: absolute;
top: 300px; left: 120px;
z-index: 1; /* queda debajo del iframe */
}
</style>
<button id="cebo">Reproducir vídeo</button>
<iframe src="https://app-victima.tld/cuenta/eliminar"></iframe>
Ajustando las coordenadas, el botón real de la aplicación víctima (por ejemplo, confirmar el borrado de la cuenta) se sitúa exactamente sobre el cebo "Reproducir vídeo". La víctima cree iniciar un vídeo y en realidad confirma una acción destructiva. Reproducirlo en un laboratorio controlado (un iframe apuntando a DVWA o a un entorno propio) confirma en segundos si el objetivo permite el framing.
Variantes de clickjacking
Likejacking
Es la variante que popularizó el ataque a gran escala. El botón "Me gusta" o de compartir de una red social se enmarca de forma invisible sobre un contenido atractivo. Cada clic del usuario propaga un enlace en su muro sin que lo perciba, y esa difusión viral arrastra a nuevas víctimas hacia la misma trampa.
Cursorjacking
En lugar de mover el destino del clic, se manipula la percepción del cursor. El atacante oculta el puntero real con CSS y dibuja un cursor falso desplazado unos píxeles. El usuario cree apuntar a un sitio de la pantalla, pero el clic efectivo cae en otra posición, alineada con el elemento sensible enmarcado.
Drag-and-drop y filejacking
Algunas variantes no dependen del clic sino del arrastre. Mediante gestos de drag-and-drop se fuerza a la víctima a extraer texto de un widget enmarcado (por ejemplo, un token visible) y soltarlo en un campo del atacante, o a interactuar con selectores de archivos para exfiltrar rutas locales.
Tapjacking en móvil
En Android, el equivalente se conoce como tapjacking: una app maliciosa dibuja una superposición (SYSTEM_ALERT_WINDOW o toasts abusivos) sobre otra aplicación, de modo que el toque del usuario llega a la app subyacente. Concede permisos, acepta diálogos o pulsa botones de banca sin que la persona sea consciente de la capa oculta.
Double clickjacking (bypass moderno)
La técnica de double clickjacking, divulgada por Paulos Yibelo a finales de 2024, evita las defensas clásicas porque no utiliza un iframe. El atacante abre una ventana emergente que pide un doble clic (habitualmente disfrazada de captcha). Entre el primer y el segundo clic, en el evento mousedown, el script redirige la ventana padre hacia la página sensible real (por ejemplo, una pantalla de autorización OAuth), de forma que el segundo clic aterriza sobre el botón legítimo de "Autorizar". Como no hay framing, ni X-Frame-Options ni frame-ancestors intervienen, y SameSite=Lax tampoco protege porque la navegación ocurre en primer plano. La mitigación pasa por deshabilitar los botones críticos hasta detectar un gesto verificado del usuario.
Impacto real y clasificación
El clickjacking rara vez es un fin en sí mismo: suele ser el detonante de acciones más graves. En aplicaciones reales se ha empleado para forzar concesiones de permisos, activar micrófono o cámara, aprobar flujos OAuth que entregan cuentas completas, confirmar transferencias o cambiar direcciones de correo (antesala de un reset de contraseña). Combinado con un CSRF de fondo, aporta el gesto humano que algunas defensas exigen.
En el catálogo de debilidades, se identifica como CWE-1021, y la cabecera histórica de mitigación, X-Frame-Options, está estandarizada en la RFC 7034. Una búsqueda en el NVD por "clickjacking" devuelve entradas recurrentes en paneles de administración, plugins de CMS y consolas empresariales sin la cabecera de framing configurada. El patrón siempre es el mismo: una acción sensible ejecutable con un clic y una página que se deja enmarcar por terceros.
Defensas frente a clickjacking
X-Frame-Options
La cabecera de respuesta X-Frame-Options: DENY prohíbe que la página sea enmarcada por cualquier origen, y SAMEORIGIN la permite solo desde el mismo dominio. Es la defensa más antigua y con mayor cobertura en navegadores heredados. El valor ALLOW-FROM quedó obsoleto y no debe usarse porque su soporte fue siempre irregular.
CSP frame-ancestors
La directiva moderna es Content-Security-Policy: frame-ancestors. frame-ancestors 'none' equivale a DENY, frame-ancestors 'self' a SAMEORIGIN, y admite una lista blanca de orígenes concretos (frame-ancestors 'self' https://socio-confiable.tld). Introducida en CSP nivel 2, supera a X-Frame-Options porque permite varios orígenes autorizados y no está limitada a un único valor. La recomendación profesional es enviar ambas cabeceras para cubrir navegadores antiguos y modernos, dejando que frame-ancestors prevalezca donde esté soportada.
Cookies SameSite
SameSite=Lax (valor por defecto en navegadores actuales) o SameSite=Strict impiden que la cookie de sesión viaje en contextos cross site, y el contenido enmarcado por un atacante es, por definición, cross site. Esto no evita que la página se enmarque, pero degrada el impacto: si la sesión no acompaña al iframe, la acción sensible no se autentica. Es una defensa complementaria valiosa, la misma familia de mitigaciones que se aplica frente a CSRF.
Frame busting (legacy)
El frame busting mediante JavaScript (if (top !== self) top.location = self.location) fue la defensa artesanal de la era anterior a las cabeceras. Hoy se considera insuficiente por sí solo: los atributos sandbox del iframe y el manejo de onbeforeunload permiten neutralizarlo. Sirve como capa adicional, nunca como control principal.
Defensas de experiencia de usuario
Las acciones irreversibles deberían exigir confirmación explícita, reautenticación o un segundo factor. Deshabilitar botones críticos hasta detectar un gesto legítimo del usuario es, además, la mitigación específica frente al double clickjacking descrito antes.
Cómo testear clickjacking en una auditoría
El diagnóstico inicial es directo: revisar las cabeceras de respuesta con curl -I https://objetivo.tld y comprobar la presencia de X-Frame-Options y Content-Security-Policy: frame-ancestors. Servicios como securityheaders.com ofrecen una lectura rápida, aunque nunca sustituyen la verificación manual sobre las rutas sensibles reales.
La confirmación de explotabilidad se hace con una prueba de concepto real. Burp Suite incluye Clickbandit, que genera automáticamente una página de ataque enmarcando el objetivo y permite validar si un flujo concreto es secuestrable. El proceso: identificar los endpoints de acción sensible (permisos, pagos, cambios de cuenta, autorizaciones OAuth), construir un iframe transparente sobre cada uno, verificar si el navegador lo renderiza con la sesión activa y probar variantes como cursorjacking o double clickjacking sobre los flujos críticos. Estas comprobaciones forman parte del alcance habitual de un pentesting de aplicaciones web alineado con la OWASP Web Security Testing Guide.
Preguntas frecuentes
¿El clickjacking necesita ejecutar JavaScript en el sitio víctima?
No. A diferencia del XSS, el clickjacking no inyecta código en la aplicación objetivo. Solo la enmarca desde fuera. Por eso una web sin ningún fallo de inyección puede seguir siendo vulnerable a clickjacking si permite el framing de terceros.
¿Basta con X-Frame-Options o necesito CSP frame-ancestors?
Lo robusto es enviar ambas. X-Frame-Options cubre navegadores antiguos, y frame-ancestors es la directiva moderna con soporte para listas de orígenes y control más granular. Donde ambas estén presentes, los navegadores modernos priorizan frame-ancestors.
¿SameSite en las cookies detiene el clickjacking?
No lo impide, pero reduce su impacto. SameSite=Lax o Strict evita que la cookie de sesión acompañe al contenido enmarcado cross site, de modo que la acción secuestrada no llega a autenticarse. Es una capa complementaria a las cabeceras de framing, no un sustituto.
¿Qué es el double clickjacking y por qué evita las defensas clásicas?
Es una técnica que explota el intervalo entre los dos clics de un doble clic para cambiar la ventana padre hacia la página sensible justo antes del segundo clic. Al no usar iframe, ni X-Frame-Options ni frame-ancestors intervienen. Se mitiga deshabilitando los botones críticos hasta detectar un gesto real del usuario.
Recursos relacionados
- Qué es CSRF: cross-site request forgery, ejemplos y defensa
- Qué es XSS: cross-site scripting
- Qué es CORS y por qué importa en seguridad web
- OWASP Top 10 2025: vulnerabilidades para empresas
- Auditoría de seguridad web y móvil
Auditar clickjacking y UI redressing con Secra
Secra realiza auditorías de aplicaciones web alineadas con OWASP Top 10 y la OWASP Web Security Testing Guide. Cubrimos la revisión de cabeceras X-Frame-Options y Content-Security-Policy: frame-ancestors, la validación de la configuración SameSite de las cookies de sesión, y pruebas de concepto reales de clickjacking, likejacking, cursorjacking y double clickjacking sobre vuestros flujos sensibles (permisos, pagos, autorizaciones OAuth y cambios de cuenta).
Entregamos hallazgos priorizados y recomendaciones de hardening específicas para vuestra arquitectura, incluidas suites de regresión que verifican en CI que las cabeceras de framing no se desactivan al desplegar nuevas rutas. Si necesitáis una revisión profesional de clickjacking y del resto del catálogo OWASP, escribidnos desde /es/contacto.
Sobre el autor
Equipo de Secra Solutions
Ethical hackers certificados OSCP, OSEP, OSWE, CRTO, CRTL y CARTE, con más de 7 años de experiencia en ciberseguridad ofensiva. Autores de los CVE-2025-40652 y CVE-2023-3512.