Tabnabbing y clickjacking: cuando la interfaz te engaña

Cómo puede cambiar el aspecto de una pestaña

Una página puede cambiar su contenido, título e icono después de cargar. También puede saber si su pestaña está visible mediante la API de visibilidad de páginas. Estas capacidades permiten funciones normales de la web, pero una página maliciosa puede usarlas para imitar un servicio en el que confías.

Una posible secuencia es esta: abres una página controlada por un atacante o que ha sido comprometida y cambias de pestaña. Su código detecta que queda en segundo plano y más tarde muestra una petición de acceso falsa. Puede cambiar su HTML y su icono, pero no el origen real que aparece en la barra de direcciones. El momento y el aspecto dependen del código del ataque; no hay un retraso fijo.

Si introduces una contraseña o un código de un solo uso en ese formulario, la página podría enviárselo al atacante. Después puede redirigirte al servicio real para disimular. Comprueba la barra de direcciones antes de introducir credenciales, sobre todo si una pestaña te pide iniciar sesión sin esperarlo. Una clave de acceso vinculada al origen auténtico puede resistir esta captura en un sitio falso.

Clickjacking mediante una página incrustada

En un intento de clickjacking, un atacante coloca una web legítima dentro de un iframe y dispone un señuelo para que el clic llegue a un control de la página incrustada. La web de destino debe permitir esa incrustación, y el clic tiene que alcanzar una acción disponible en el estado actual de la cuenta. MDN ilustra el mecanismo. Esto no da al atacante acceso indiscriminado a cualquier cuenta o transacción.

El ejemplo clásico es un botón social oculto bajo un elemento de un juego: al pulsar el juego, la persona acciona el botón sin querer. Las consecuencias dependen de lo que permita la página incrustada. Las acciones sensibles pueden requerir una confirmación nueva, y las reglas sobre cookies entre sitios pueden impedir que el iframe conserve tu sesión iniciada. No des por hecho que una pantalla de autorización o pago puede incrustarse solo porque tenga un botón.

La defensa principal corresponde a los responsables de la web. La directiva frame-ancestors de CSP limita qué sitios pueden incrustar una página. X-Frame-Options ofrece una restricción más sencilla para navegadores antiguos. Las webs que necesitan permitir la incrustación pueden autorizar sitios de confianza y pedir una confirmación para acciones importantes. La ausencia de restricciones puede abrir una vía de ataque, pero aprovecharla depende de la página y de sus demás defensas.

Cuándo importa window.opener

El tabnabbing inverso requiere una relación entre la ventana nueva y la que la abrió. Si una página abre otra ventana y deja disponible window.opener, la nueva podría redirigir la original a un sitio de phishing. Las reglas entre orígenes le impiden leer el contenido de la primera, pero pueden permitir la navegación, como explica MDN.

Los enlaces modernos con target="_blank" se comportan de forma implícita como si llevaran rel="noopener". Así, window.opener queda vacío salvo que se solicite expresamente conservarlo. MDN documenta este comportamiento. Los scripts que usan window.open() deberían solicitar noopener cuando corresponda. Un enlace a una web desconocida no supone automáticamente un riesgo de tabnabbing inverso.

Qué necesitan estos ataques para funcionar

Estos ataques usan funciones normales de la web para engañar. Una página puede cambiar su aspecto y algunas webs permiten que otras las incrusten. El riesgo depende del origen de la página, de sus reglas de incrustación, del estado de la cuenta y de tu siguiente acción. Que una página resulte familiar no demuestra que pertenezca al servicio que imita.

Los ajustes predeterminados de los navegadores han cerrado algunas vías antiguas, sobre todo la relación entre un enlace normal y la nueva pestaña que abre. Las webs aún deben escoger reglas de incrustación adecuadas, y quienes las usan deben revisar el origen antes de iniciar sesión o aprobar acciones. La guía de OWASP contra el clickjacking trata también las cookies SameSite y los pasos de confirmación como protecciones adicionales. Ningún hábito ni cabecera de respuesta por sí solo evita todos los engaños de interfaz.

Defensas para usuarios y webs

Aprovecha las protecciones del navegador y de la web, y comprueba la página antes de actuar.

1. 1

   Verifica las pantallas de acceso inesperadas

   Si una pestaña te pide de pronto que inicies sesión, mira su dirección. Si tienes dudas, abre el servicio por separado desde un marcador de confianza o escribe tú la dirección.
2. 2

   Comprueba el origen, no solo el diseño

   La barra de direcciones muestra dónde estás realmente. Un dominio parecido no es el servicio al que querías entrar. Cuando están disponibles, las claves de acceso vinculadas al origen correcto también reducen el riesgo de robo de credenciales en una página de acceso falsa.
3. 3

   Revisa las acciones importantes en su contexto

   Antes de aprobar un acceso o un pago, comprueba qué web lo pide y qué acción describe. Los responsables del sitio deben limitar la incrustación de páginas sensibles y exigir la confirmación adecuada.
4. 4

   Usa el aislamiento para lo que sí separa

   Una sesión de Browser.lol puede separar el contenido web de tu navegador local. No verifica si el aspecto de una página es auténtico ni impide que una página maliciosa dentro del navegador remoto cambie su aspecto o use un iframe permitido. Comprueba allí también el origen y la acción solicitada.