Cómo un escape de borde CSS comprometió las interfaces de webmail más confiables del mundo

Recuerdo estar sentado en un Centro de Operaciones de Seguridad sin ventanas hace tres años, observando cómo un red teamer eludía un firewall de aplicaciones web de varios millones de dólares con un solo carácter codificado. Fue un recordatorio humillante de que la complejidad es el enemigo de la seguridad. A menudo asumimos que cuanto más gastamos en una capa defensiva, más segura es su protección. Esta creencia es una falacia. Una investigación reciente presentada por Gareth Heyes de PortSwigger en Black Hat USA 2026 demuestra que incluso las plataformas de webmail más maduras son vulnerables a ataques basados en estilos.

Los proveedores de webmail como Gmail, Outlook y Proton Mail gastan millones en motores de sanitización. Estos sistemas actúan como el portero de un club VIP en cada puerta interna. Escanean cada correo electrónico HTML entrante en busca de scripts maliciosos y etiquetas peligrosas. Si una pieza de código parece sospechosa, el sanitizador la elimina. Esta investigación muestra que un atacante no necesita JavaScript para causar daño. Solo necesitan Hojas de Estilo en Cascada (CSS). Al explotar cómo los navegadores y los clientes de webmail interpretan el estilo, un atacante puede saltar la valla entre un correo electrónico no confiable y la interfaz confiable de la aplicación.

La paradoja arquitectónica de la sanitización del correo electrónico

El problema fundamental es el límite. Cuando abres un correo electrónico, el cliente de webmail coloca ese contenido no confiable dentro de su propia interfaz de usuario (UI) confiable. Hay una pared delgada entre el mensaje y tus botones de "Bandeja de entrada" o "Configuración". Por lo general, esta pared es una serie de filtros que evitan que el correo afecte al resto de la página. Esta investigación demuestra cómo el CSS puede atravesar esa pared.

Una vía implica abusar del HTML y CSS que el sanitizador ya permite. La otra vía crea una discrepancia entre lo que el sanitizador aprueba y lo que el navegador finalmente renderiza. Ambas vías conducen al mismo resultado: el contenido del correo electrónico interfiere con la interfaz de webmail. Esto puede provocar el robo de contraseñas, la filtración de tokens y acciones no autorizadas en la interfaz de usuario. Es un fallo sistémico del modelo de aislamiento en el que hemos confiado durante décadas.

La cadena de captura de contraseñas de Outlook

El hallazgo más dramático involucra a Outlook y Firefox. Esta cadena de ataque es una clase magistral sobre cómo combinar comportamientos menores del navegador para lograr un compromiso crítico. El investigador utilizó elementos de etiqueta (label) permitidos para activar controles fuera del mensaje de correo electrónico. Luego, un truco de análisis de media-queries permitió la inyección de CSS arbitrario que el sanitizador pasó por alto.

Dentro del correo electrónico, el atacante disfraza un elemento select estándar como una pantalla de inicio de sesión de Microsoft. Aquí es donde entra en juego el comportamiento de Firefox. Firefox tiene un temporizador interno de aproximadamente un segundo para los menús de selección. Si el elemento select se mueve fuera de la pantalla, el navegador reinicia este temporizador. Al mover el elemento estratégicamente, el atacante hace que la captura ocurra en tiempo real. Cuando un usuario piensa que está escribiendo su contraseña en un aviso confiable, en realidad la está enviando directamente al atacante. Esta técnica elude las advertencias tradicionales de phishing porque la URL en la barra de direcciones sigue siendo outlook.live.com.

La carrera de pegado de Yahoo y AOL

Yahoo Mail y AOL Mail revelaron una vulnerabilidad diferente arraigada en cómo los navegadores manejan el portapapeles. En Firefox, el HTML pegado puede retener brevemente el CSS activo antes de que el sanitizador de la aplicación tenga la oportunidad de limpiarlo. Esto es una "carrera de pegado" (paste race). La investigación demostró esto apuntando a los tokens de inicio de sesión por correo electrónico de Medium.

En este escenario, el atacante inicia un flujo de inicio de sesión para la cuenta de Medium de la víctima. La víctima recibe un correo electrónico de inicio de sesión legítimo. Sin embargo, el atacante ya ha enviado un correo electrónico separado que contiene CSS malicioso. La víctima copia este contenido y lo pega en un borrador en Yahoo o AOL. Durante ese microsegundo del pegado, el CSS malicioso realiza peticiones al servidor del atacante. Estas peticiones revelan suficientes caracteres del token de inicio de sesión de 12 dígitos para que el servidor reconstruya el código completo. El atacante luego usa ese token para iniciar sesión como la víctima. Todo el proceso depende de una condición de carrera que ocurre en un abrir y cerrar de ojos.

Exfiltración de tokens mediante inyección de prompts

El auge de las herramientas de correo electrónico conectadas a la IA crea una nueva superficie de ataque. Gmail proporciona un ejemplo claro a través de su comportamiento de respaldo image-set(). A pesar de los esfuerzos de sanitización, esta función CSS aún puede realizar peticiones externas. Gareth Heyes y Pete Hendy encadenaron esto con un ataque de inyección indirecta de prompts. Esto se dirigió específicamente a los usuarios de la herramienta Claude Cowork de Anthropic, que se conecta a Gmail para procesar mensajes.

Un atacante envía un correo electrónico con instrucciones ocultas para la IA. Cuando la víctima le pide a Claude que procese sus correos electrónicos recientes, la IA sigue las instrucciones inyectadas en lugar del comando del usuario. En la demostración, la IA recuperó un token de Slack de un correo de confirmación separado y lo colocó en un nuevo borrador HTML. Cuando la víctima vio ese borrador, el bypass de image-set() exfiltró el token al atacante. Este giro de los acontecimientos muestra cómo los agentes de IA pueden convertirse en un caballo de Troya digital dentro de un entorno seguro.

Fastmail y el arte del "puenteo" CSS

Fastmail era vulnerable a lo que el investigador llama "CSS hotwiring" (puenteo CSS). Esta técnica redirige los clics hacia acciones de la interfaz de usuario no deseadas y de varios pasos. Mediante el uso de pseudoelementos CSS y opacidad, un atacante puede superponer botones invisibles sobre la interfaz legítima de Fastmail. Un usuario que cree estar haciendo clic en un enlace de un correo electrónico podría estar haciendo clic en realidad en un botón que elimina su bandeja de entrada o cambia la configuración de su cuenta.

Esta investigación también se centró en el navegador de IA Atlas de OpenAI. Un atacante puede usar CSS para mostrar una cosa a un humano y otra a una máquina. Por ejemplo, el humano ve un párrafo de texto inofensivo. El modelo de IA lee instrucciones ocultas codificadas en el CSS. Cuando el usuario le pide a Atlas que traduzca el texto visible, las instrucciones ocultas hacen que el navegador abra nuevas pestañas y filtre el nombre de la víctima en los fragmentos de la URL. Aunque OpenAI retirará Atlas el 9 de agosto de 2026, la técnica sigue siendo una advertencia para cualquier desarrollador que construya IA que interactúe con la web.

Filtraciones de privacidad en Proton Mail

Incluso los servicios centrados en la privacidad como Proton Mail no son inmunes. El investigador demostró un vector que exponía la dirección IP de un destinatario. Proton Mail está diseñado para ocultar esta información a los remitentes mediante la protección contra rastreadores. Sin embargo, un bypass de CSS específico permitió que se disparara una petición externa cuando se abría el correo electrónico. Esto reveló la hora exacta en que se leyó el correo y la dirección IP personal del usuario. Desde entonces, Proton ha abordado ciertos bypasses de proxy, pero la investigación destaca la dificultad de mantener un perímetro perfecto en un mundo de CSS complejo.

Fortaleciendo el webmail contra ataques de estilo

Estos hallazgos sugieren que nuestro enfoque actual de la seguridad del correo electrónico es reactivo. Esperamos a que un investigador encuentre un bypass y luego lo parcheamos. Para los proveedores de webmail, la guía defensiva es ahora mucho más estricta. La defensa más eficaz es el aislamiento total. Esto significa renderizar correos electrónicos HTML dentro de iframes con sandbox. Esto evita que el estilo del correo electrónico llegue alguna vez a la interfaz de usuario principal.

Los proveedores también deben restringir las propiedades CSS a una lista de permitidos estricta de caracteres seguros. Deben bloquear los menús de selección, los atributos personalizados y los selectores peligrosos como :has(). Además, deben evitar todas las peticiones de imágenes controladas por el atacante, incluso aquellas que parecen provenir de dominios permitidos. Desde la perspectiva del usuario final, la mejor defensa es una paranoia saludable. Desconfíe de cualquier correo electrónico que le pida copiar y pegar contenido o interactuar con elementos inusuales de la interfaz de usuario.

Puntos clave para los equipos de seguridad

• Implementar sandboxing estricto de iframes para todo el contenido HTML no confiable.
• Validar el CSS contra una lista de permitidos basada en caracteres en lugar de una lista de bloqueados basada en etiquetas.
• Auditar la interacción entre los asistentes de IA y el DOM del correo electrónico para evitar la inyección indirecta de prompts.
• Desactivar funciones CSS peligrosas como image-set() y pseudoselectores complejos en el cuerpo del correo electrónico.
• Revisar el comportamiento de los atributos HTML personalizados que JavaScript podría transformar posteriormente en elementos activos.

Fuentes:

• PortSwigger Research: Gareth Heyes, Black Hat USA 2026 Paper
• NIST Special Publication 800-45 Version 2: Guide to Electronic Mail Security
• MITRE ATT&CK Framework: T1566 (Phishing) y T1189 (Drive-by Compromise)

Este artículo es solo para fines informativos y educativos y no reemplaza una auditoría de ciberseguridad profesional o un servicio de respuesta a incidentes.