Definición y protección frente al clickjacking

MundoWin » General » Definición y protección frente al clickjacking

El clickjacking es uno de esos ataques que pasan totalmente desapercibidos para el usuario, pero que pueden terminar en robos de datos, fraudes bancarios o control remoto del dispositivo. No hace falta que la víctima descargue nada raro ni que haga mil pasos: basta con un clic inocente en el sitio equivocado. Por eso, entender bien cómo funciona y cómo pararlo es clave tanto para usuarios como para administradores de sistemas y desarrolladores web.

Aunque a primera vista puede parecer un truco sencillo, detrás hay una combinación de fallos de diseño en la web, abuso de iframes, capas CSS, cabeceras de seguridad mal configuradas y, sobre todo, mucha ingeniería social. Vamos a ver en profundidad qué es el clickjacking, por qué es tan peligroso, qué variantes existen (incluido el doble clickjacking) y qué medidas técnicas y de buenas prácticas permiten minimizar el riesgo.

¿Qué es exactamente el clickjacking?

Cuando hablamos de clickjacking (también llamado secuestro de clics o UI redress attack), nos referimos a una técnica en la que un atacante manipula la interfaz de una página para que el usuario pulse donde no quiere. El usuario cree que está haciendo clic en un botón o enlace legítimo, pero en realidad está activando una acción oculta superpuesta en otra capa.

La clave está en el uso de capas transparentes o semitransparentes que se colocan por encima de elementos reales de una web de confianza. El ataque suele aprovechar iframes e instrucciones CSS (como opacity, position, z-index, width, height, etc.) para encajar milimétricamente un botón invisible sobre el área donde el usuario va a hacer clic.

El término clickjacking fue acuñado en 2008 por Jeremiah Grossman y Robert Hansen. Ellos demostraron que no se trataba simplemente de un phishing con páginas falsas, sino de algo más sofisticado: el usuario ve la página legítima real, pero sin darse cuenta está interactuando con una capa manipulada por el atacante.

Este tipo de ataque se considera un problema de diseño de la propia web y del modelo de iframes en HTML. En origen, cualquier sitio puede ser embebido dentro de otro mediante un iframe, y si no se ponen límites desde el servidor o el navegador, esa característica se convierte en el punto de apoyo perfecto para robar clics.

Cómo funciona un ataque de clickjacking paso a paso

En un escenario típico, el atacante parte de dos piezas: una web maliciosa controlada por él y una web de confianza que será la víctima (banco, red social, panel de administración, etc.). El truco consiste en incrustar la página de confianza dentro de un iframe y manipular ese iframe hasta hacerlo invisible, alineando un botón sensible justo debajo de donde el usuario cree que está pulsando.

El proceso, simplificado, suele seguir esta secuencia de pasos lógicos:

• El atacante crea una página atractiva (por ejemplo, un sorteo, un vídeo llamativo o una falsa noticia) que invite al usuario a interactuar con un gran botón o enlace.
• En esa misma página se incluye un iframe que carga la web legítima (por ejemplo, «Mi cuenta» de un banco o la página de configuración de un servicio).
• Mediante CSS se configura ese iframe con opacity:0 (o prácticamente 0), se ajustan las propiedades position, top, left, width, height y z-index para que el botón real (por ejemplo, «Confirmar transferencia» o «Eliminar cuenta») quede situado exactamente debajo del texto visible que el usuario ve.
• Cuando la víctima pulsa el botón aparentemente inocente, en realidad está haciendo clic sobre el botón sensible de la página embebida, que se ejecuta como si hubiera sido pulsado directamente en la web legítima.

Una diferencia importante con otros ataques como CSRF es que, en el clickjacking, el atacante consigue que el usuario interactúe con la web víctima con su sesión activa. Si el usuario ya estaba autenticado, la acción se realiza con su token o cookie válidos, por lo que el sistema la considera totalmente legítima.

Esta técnica no se limita a clics sencillos. En escenarios avanzados, el usuario puede llegar a introducir nombres de usuario, contraseñas, números de tarjeta de crédito o códigos de verificación en formularios que cree legítimos, cuando en realidad está alimentando formularios invisibles o pantallas superpuestas que envían los datos directamente al servidor del atacante.

Capas, iframes y CSS: el corazón técnico del clickjacking

Para explotar el clickjacking, el atacante se apoya en el modelo en capas del HTML. Cada elemento de una página se puede situar por encima o por debajo de otros usando la propiedad z-index y se puede posicionar exactamente donde se quiera con las propiedades position, top, left, width y height.

El iframe juega un papel fundamental: permite cargar otra página web completa dentro de la página del atacante. Aunque el iframe es una técnica considerada algo antigua, sigue soportada por todos los navegadores y es ampliamente utilizada, lo que la convierte en un objetivo perfecto.

Un ejemplo típico de configuración CSS usada en ataques de clickjacking podría ser algo como:

opacity:0 (para que el iframe sea totalmente transparente), position:absolute (para colocarlo encima del contenido visible), top:0px; left:0px; width:99%; height:95% (para cubrir casi toda la pantalla) y un z-index alto (para situarlo sobre cualquier otro elemento visible).

Mientras el usuario ve un mensaje persuasivo del tipo «Haz clic aquí para ganar un premio» o «Pulsa para reproducir el vídeo», sus clics en realidad se están enviando a los botones de la página legítima que está dentro del iframe invisible. Con un buen ajuste de coordenadas, el engaño es casi perfecto.

Ejemplos reales y variantes de clickjacking

El clickjacking se ha utilizado en contextos muy diversos, desde redes sociales y banca online hasta publicidad engañosa o apps móviles. Algunos casos ilustrativos ayudan a entender el alcance real del problema.

Uno de los ejemplos clásicos es el llamado likejacking, donde el objetivo es conseguir que los usuarios den «Me gusta» en publicaciones o páginas de Facebook sin saberlo. El atacante deja un iframe con el botón real de «Me gusta» oculto bajo una imagen llamativa, de forma que, al hacer clic, el usuario está interactuando con su propia cuenta.

En el ámbito financiero, se han documentado ataques en los que se cargan iframes invisibles de páginas de banca online. Mientras el usuario cree estar navegando por un sitio cualquiera, realmente está pulsando en botones de autorización de transferencias, modificación de datos o desactivación de medidas de seguridad.

Otro escenario preocupante es el de la activación de hardware del dispositivo. Ya en 2008 se mostró cómo una víctima podía habilitar su cámara web sin darse cuenta, simplemente pulsando en supuestos botones inofensivos en una página de Adobe que, en realidad, estaban superpuestos sobre los controles de permisos de la cámara.

En el mundo móvil, el clickjacking se combina con capas de interfaz (overlays) para controlar lo que el usuario ve en la pantalla táctil. Un malware como Svpeng, especializado en Android, llegó a popularizar el uso de superposiciones invisibles sobre la pantalla de inicio de sesión de aplicaciones bancarias.

Clickjacking en dispositivos móviles y el caso del malware Svpeng

Las aplicaciones bancarias para móviles suelen ser consideradas muy seguras, pero el clickjacking ha demostrado que la interfaz táctil también puede ser manipulada. Malware como Svpeng aprovechó esta idea para robar credenciales bancarias de usuarios de Android a gran escala.

El truco consistía en insertar una capa de interfaz de usuario invisible entre el dedo del usuario y la pantalla del dispositivo. Así, cuando el usuario introducía su ID y su contraseña en lo que creía que era la pantalla oficial del banco, en realidad estaba interactuando con una réplica superpuesta que enviaba todos esos datos a los servidores de los atacantes.

Una vez que Svpeng obtenía privilegios de administrador en el dispositivo, el problema se volvía mucho más grave. El malware podía elegir qué pantallas de superposición mostrar, leer y enviar SMS, realizar llamadas, acceder a la agenda de contactos, obtener listados de aplicaciones instaladas y capturar prácticamente cualquier actividad sensible del usuario.

Este tipo de malware aprovecha el hecho de que muchos bancos utilizan SMS como segundo factor de autenticación. Si el malware tiene acceso a los mensajes, también puede interceptar los códigos de verificación y completar transacciones sin que el usuario lo note hasta que sea demasiado tarde.

Svpeng llegó a expandirse rápidamente, alcanzando en cuestión de días decenas de países. Este caso demuestra que el clickjacking no es un problema limitado a ordenadores de sobremesa, sino que puede afectar a cualquier dispositivo con acceso a Internet: móviles, tablets, portátiles u ordenadores de escritorio.

Clickjacking en anuncios, redes sociales y plataformas web

Más allá del ámbito bancario, el clickjacking ha sido aprovechado de forma masiva en campañas de publicidad engañosa y fraude de clics. En torno a 2016, Google tuvo que eliminar anuncios con capas transparentes que redirigían a millones de usuarios a sitios no deseados con malware, adware o spyware.

En muchos casos, los clics de los usuarios no solo abrían webs no solicitadas, sino que además provocaban descargas automáticas de software malicioso, a veces sin que el usuario tuviera una percepción clara de lo que estaba pasando. Bastaba rozar un banner «demasiado bueno para ser cierto».

En redes sociales se recurrió al likejacking para crear «Me gusta» falsos, seguidores automáticos, aperturas de ventanas de spam e incluso para lanzar campañas de malware que obligaban a hacer clic en anuncios invisibles y generaban ingresos fraudulentos a través de sistemas de publicidad.

En algunos esquemas poco éticos, webs vulneradas por clickjacking se utilizaban para realizar pedidos automatizados en tiendas online con la opción de compras con un solo clic. Alrededor del mundo de la afiliación y el marketing online también se vieron casos donde los clics robados se traducían en comisiones ilegítimas.

Por si fuera poco, muchas de estas campañas se difundían a través de correos electrónicos dirigidos, aprovechando bases de datos gigantes de direcciones robadas. Mensajes que apelan a la urgencia («tu cuenta será bloqueada», «descarga la nueva app del banco», etc.) redirigen a webs manipuladas que despliegan capas falsas para robar credenciales o instalar aplicaciones fraudulentas.

Double Clickjacking: una versión más sofisticada

El llamado Double Clickjacking es una evolución del ataque clásico que obliga al usuario a realizar dos clics consecutivos. Aunque parezca un detalle menor, este cambio le permite al atacante evadir controles de seguridad muy básicos y hacer que todo parezca más natural a ojos de la víctima.

En este esquema, el usuario piensa que está confirmando una acción legítima, como enviar un formulario o completar un pago. Sin embargo, esos dos clics encadenados están siendo redirigidos a acciones ocultas de mayor impacto: desde conceder permisos a aplicaciones, hasta redirigir datos sensibles a un servidor controlado por el atacante.

Este tipo de ataque se vuelve especialmente preocupante en plataformas críticas de e‑commerce, banca online o servicios empresariales, donde la confianza del usuario y la integridad de las transacciones son fundamentales. Cualquier comportamiento extraño (dobles confirmaciones, redirecciones inesperadas) puede disparar las alarmas de los usuarios y dañar la reputación de la marca.

Para empresas con alto volumen transaccional, un incidente de double clickjacking puede traducirse en pérdida de clientes, disminución de conversiones, exposición de datos personales y riesgo regulatorio si la brecha viola leyes de protección de datos como la normativa de habeas data o legislaciones locales de privacidad.

Laboratorios y ejemplos prácticos de explotación con iframes

En entornos de formación y pentesting, el clickjacking suele demostrarse con laboratorios donde se explota un botón sensible, por ejemplo «Delete account» o «Eliminar cuenta» en la sección de «Mi cuenta» de una aplicación vulnerable.

La dinámica habitual consiste en que el atacante (o el alumno del laboratorio) inicie sesión en la aplicación, localice el botón crítico y, a continuación, prepare una página maliciosa en un servidor de exploits que contenga un iframe apuntando a la URL de «Mi cuenta».

Sobre ese iframe se coloca un texto llamativo como «Click me» en un div posicionado en las mismas coordenadas que el botón de eliminar cuenta. Se ajustan las propiedades CSS del iframe (width, height, top, left, opacity) hasta que, al pasar el ratón sobre el texto visible, el cursor cambie a mano justo cuando está encima del botón real que interesa al atacante.

Una vez alineado todo, se reduce la opacidad del iframe a un valor prácticamente invisible (por ejemplo, 0.0001) y se envía el enlace de la página maliciosa a la víctima. Con un solo clic sobre el «Click me», la cuenta de la víctima puede quedar borrada sin que esta se entere de lo que ha pasado en segundo plano.

Estos laboratorios muestran lo sencillo que resulta montar un clickjacking eficaz si el sitio objetivo no aplica protecciones como X-Frame-Options o Content-Security-Policy (CSP) con frame-ancestors. Solo hace falta un poco de maña con CSS e iframes para engañar completamente la percepción del usuario.

Medidas de protección del lado del servidor

Para que un sitio web no pueda ser utilizado como víctima en un clickjacking, la medida más directa es impedir que se cargue dentro de un iframe ajeno. Si el navegador no permite que la página se embeba, el atacante pierde la base técnica para colocar capas invisibles por encima.

Históricamente se han usado trucos en JavaScript para comprobar si la página está en el marco principal del navegador y, en caso contrario, forzar que se abra en la ventana superior. Sin embargo, esas defensas no siempre son fiables y pueden ser burladas, por lo que se han ido imponiendo cabeceras de seguridad específicas a nivel HTTP.

La cabecera más conocida es X-Frame-Options, que indica al navegador cómo debe comportarse cuando una página intenta mostrarse dentro de un frame o iframe. Sus valores típicos son:

• DENY: el navegador prohíbe siempre que la página se muestre en un frame, venga de donde venga.
• SAMEORIGIN: solo se permite que la página se muestre en un frame si el origen (dominio) del frame es el mismo que el de la página.
• ALLOW-FROM uri: se autoriza la visualización en un frame únicamente cuando el origen superior coincide con la URI especificada (aunque este modo tiene soporte limitado en algunos navegadores).

Actualmente, se recomienda complementar o sustituir X-Frame-Options con una , especialmente usando la directiva frame-ancestors para definir exactamente qué orígenes pueden embeber nuestra web.

En paneles de administración concretos, como Plesk, se dispone además de parámetros de configuración como sameOriginOnly en archivos de ajuste (por ejemplo, panel.ini). Activar este parámetro impide que las páginas de Plesk se abran en iframes de otros sitios, lo que frena el clickjacking, aunque también bloquea usos legítimos en iframes de sitios seguros, por lo que hay que valorar caso a caso.

Otras defensas técnicas: HTTPS, HSTS, XSS y CSP

El clickjacking no siempre va solo. Muchas veces viene acompañado de inyecciones de código en el lado del cliente, ataques man in the middle o explotación de bugs de XSS. Por eso, las defensas deben ir más allá de los iframes y abarcar toda la superficie de ataque de una aplicación web.

En primer lugar, es fundamental reforzar la conexión entre servidor y cliente mediante HTTPS correctamente configurado, combinado con HSTS (HTTP Strict Transport Security) para obligar al navegador a usar siempre conexiones seguras y evitar ataques como SSL stripping o esquemas mixtos HTTP/HTTPS.

También resulta clave minimizar las posibilidades de inyección de código (XSS, HTML Injection). Los navegadores incluyen filtros Anti‑XSS, pero son complejos y no infalibles; periódicamente se descubren formas de saltárselos. Desde el servidor se pueden reforzar con cabeceras como X-XSS-Protection para forzar que el navegador active estos filtros aunque el usuario los hubiera deshabilitado.

La configuración cuidadosa de una Content-Security-Policy permite además controlar qué scripts pueden ejecutarse, de qué orígenes, y en qué partes de la aplicación. Restringiendo la ejecución de JavaScript en zonas sensibles, se dificulta muchísimo que un código inyectado pueda llevar a cabo un ataque de clickjacking complejo o combinarse con otras técnicas.

Por último, herramientas como un Web Application Firewall (WAF) moderno (por ejemplo, integrado con soluciones como Cloudflare) pueden inspeccionar el tráfico en tiempo real, detectar patrones característicos de clickjacking y bloquear solicitudes maliciosas antes de que lleguen a la aplicación, además de ofrecer reglas personalizadas y visibilidad avanzada de intentos de ataque.

Protecciones adicionales desde el lado del navegador y del usuario

Aunque la mayor parte del peso debería recaer en los servidores y desarrolladores, el usuario también puede poner de su parte para reducir la superficie de exposición al clickjacking. Algunas herramientas y hábitos ayudan a detectar comportamientos sospechosos.

En el caso de Firefox, por ejemplo, extensiones como NoScript incorporan funcionalidades específicas como ClearClick, que trata de detectar cuándo se está intentando engañar al usuario con capas invisibles y puede mostrar alertas cuando identifica este tipo de trampas.

Otros complementos como uBlock Origin o bloqueadores de scripts permiten limitar la ejecución de JavaScript y el uso de iframes de terceros, lo cual reduce muchos vectores de ataque basados en contenido embebido. Eso sí, estos enfoques requieren usuarios algo más avanzados, dispuestos a sacrificar comodidad por seguridad.

Algunos antivirus y suites de seguridad también incluyen firmas para detectar comportamientos de clickjacking en páginas web. Por ejemplo, ciertas soluciones identifican patrones típicos en el HTML y lo marcan con nombres genéricos como HTML/Infected.WebPage.Gen2.

Desde el punto de vista del comportamiento, conviene mantener una actitud escéptica ante correos y anuncios demasiado llamativos, evitar pulsar en enlaces que prometan milagros o que lleguen en mensajes de urgencia, y descargar aplicaciones únicamente desde tiendas oficiales. Si una web se ve rara, desalineada, poco profesional o pide datos sensibles de forma inusual, lo prudente es salir de ahí.

En el ámbito corporativo, formar a los empleados sobre señales de interfaces falsas, redirecciones extrañas y capas superpuestas en aplicaciones internas puede evitar que un descuido termine en una brecha de seguridad importante.

Clickjacking, reputación y negocio digital

Más allá del impacto técnico, el clickjacking y sus variantes (como el double clickjacking) tienen implicaciones directas en la confianza digital y la reputación de las empresas. Un simple incidente en una plataforma de comercio electrónico, un banco o un servicio online puede espantar a clientes y usuarios durante años.

Cuando un usuario experimenta redirecciones sospechosas, formularios que actúan de forma extraña o acciones que no ha autorizado, su percepción de la seguridad del sitio se desploma. Muchos no se lo piensan dos veces antes de abandonar la plataforma y buscar alternativas en la competencia.

En mercados donde el comercio electrónico crece año tras año y mueve cantidades enormes de dinero, la seguridad deja de ser un tema puramente técnico para convertirse en un factor estratégico de negocio. No se trata solo de evitar pérdidas directas por fraude, sino de proteger la credibilidad de la marca y cumplir con marcos legales cada vez más exigentes en materia de protección de datos.

Contar con medidas como WAF, cabeceras de seguridad bien configuradas, auditorías periódicas de la interfaz y pruebas específicas de clickjacking es, a estas alturas, parte del mínimo exigible a cualquier plataforma que gestione datos personales o transacciones críticas.

En última instancia, el clickjacking nos recuerda que en la web no basta con que el código sea correcto; también hay que pensar en cómo se presenta y cómo puede ser manipulado visualmente. Tener presente esta dimensión, aplicar las protecciones técnicas adecuadas y navegar con un punto de desconfianza sana son las mejores armas para evitar que un simple clic mal colocado termine en un buen disgusto.