Resumen: JavaScript ofuscado y evasión de CSP
- Pasa por declaración: JavaScript ofuscado pasa CSP declarando solo lo que CSP permite. El comportamiento malicioso empieza después de que el script carga.
- Dominios, no integridad: CSP permite dominios, no integridad de código. Un dominio de confianza comprometido igual pasa. Polyfill.io pasó CSP en 490,000 sitios.
- El cumplimiento exige más: 6.4.3 y 11.6.1 requieren detección más allá de CSP: inventario de scripts, verificación de integridad, detección de manipulación.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
Tres vías por las que el código ofuscado evade la CSP
La CSP controla fuentes, no payloads. Tres patrones de ataque aprovechan esto:
Compromiso de CDN de confianza o host de terceros. El script se carga desde un dominio ya presente en el allowlist. Un payload modificado no activa la CSP porque la URL de origen no cambia. Polyfill[.]io, los ataques de web skimming Magecart y recientes compromisos de CDNs de analítica siguen esta vía.
Inyección en archivos propios. Un atacante con acceso al servidor inyecta código ofuscado en un archivo JavaScript propio existente. Ese archivo se carga desde el dominio del sitio, que siempre está permitido.
Construcción dinámica de código en tiempo de ejecución. Un script aprobado se carga y ensambla una función maliciosa a partir de fragmentos de cadena usando eval(), Function() o equivalentes indirectos. El payload peligroso nunca existe en ningún recurso cargado; se construye dentro del navegador tras una carga de página limpia.
Ninguna de estas vías viola un allowlist de fuentes. La CSP reporta limpio mientras el malware ofuscado se ejecuta.
Cómo los scripts ofuscados evaden también los escáneres automáticos
La ofuscación elimina las señales legibles que tanto los revisores humanos como los escáneres automáticos buscan:
| Técnica | Qué hace | Por qué los escáneres no la detectan |
|---|---|---|
| División y concatenación de cadenas | Fragmenta URLs y palabras clave en partes unidas en tiempo de ejecución | Ninguna cadena completa aparece en la fuente estática |
| Codificación Base64 con decodificación dinámica | Almacena el payload como un blob decodificado solo en ejecución | Parece datos, no código ejecutable, para un analizador estático |
| Secuencias de escape hexadecimal o Unicode | Codifica caracteres como \x61 o A | Las herramientas estáticas deben ejecutar el código para resolver el valor real |
| Nombres de variables aleatorios | Reemplaza identificadores legibles con nombres cortos aleatorios | Elimina la señal de palabras clave en la que se basan los detectores de patrones |
| Carga dinámica tardía | Obtiene el payload real de un servidor C2 tras ejecutar un script aprobado | El recurso cargado varía en cada análisis |
Los hashes de Subresource Integrity (SRI) defienden contra sustituciones silenciosas de payloads desde fuentes conocidas, pero solo cuando se puede fijar un hash para cada archivo. Los scripts de terceros que se actualizan frecuentemente hacen que SRI sea impracticable en producción, que es el reto central en la gestión de integridad de scripts dinámicos. SRI tampoco puede proteger contra payloads obtenidos dinámicamente desde un endpoint C2, porque ese payload no existía cuando se calculó ningún hash.
Por qué los escáneres estáticos no ven un CDN secuestrado
Las herramientas de análisis estático y de composición de software analizan el código antes de que se ejecute. Encuentran paquetes con CVE publicados, patrones inseguros como asignaciones a innerHTML desde entrada del usuario y dependencias desactualizadas. Lo que no pueden hacer es observar lo que un CDN entrega realmente al navegador de un visitante.
El incidente de polyfill[.]io es el ejemplo más claro. Cuando Funnull adquirió el dominio en febrero de 2024, el código fuente de cada sitio que incrustaba el script no cambió. El CDN empezó a inyectar JavaScript malicioso en las respuestas que servía, pero solo para usuarios móviles, solo con un referente falsificado y solo cuando el visitante carecía de un patrón de cookies asociado a Google Analytics y a las herramientas de desarrollo.
Un escáner estático habría visto <script src="https://cdn.polyfill[.]io/v3/polyfill.min.js"> en el HTML y no habría encontrado ningún CVE. Tampoco había un hash estable que fijar: el endpoint generaba una respuesta por petición, que es justo el caso en el que la SRI no se aplica. El ataque era invisible para cualquier herramienta que analice el código en reposo. Cuando los investigadores identificaron el payload en junio de 2024, unos 490.000 sitios web ya lo servían a usuarios reales.
La entrega condicional es lo que hace difícil detectar esta clase de ataque desde fuera de la sesión. Los atacantes condicionan los payloads al user agent, al referente, a la geografía y a la hora del día precisamente para quedar fuera de la monitorización sintética y de los perfiles de navegador de los investigadores. Un payload que solo se activa para usuarios móviles de un país una tarde concreta nunca aparece en un análisis estático ni se reproduce en un rastreador.
Enfoques para la protección contra JavaScript ofuscado
| Enfoque | Control de fuentes | Inspección de payload | Gestiona compromiso de host de confianza | Detecta inyección dinámica en ejecución |
|---|---|---|---|---|
| CSP | Sí | No | No | No |
| Subresource Integrity (SRI) | Parcial | Solo hash | Parcial | No |
| WAF o filtrado en capa de red | Parcial | No | No | No |
| Análisis estático de JavaScript | No | Parcial | Parcial | No |
| Monitorización conductual en capa del navegador | Opcional por política | Sí | Sí | Sí |
La monitorización en la capa del navegador es el único control de esta tabla que sobrevive a las tres vías de evasión descritas. Funciona junto a la CSP y cubre la brecha de visibilidad de payload que la CSP deja abierta.
Qué exigir a una herramienta resistente a la evasión de CSP
Cuatro preguntas antes de incluir un proveedor en la lista corta:
Observación del payload en tiempo de ejecución. ¿La herramienta analiza lo que los scripts ejecutan dentro del navegador, no solo las URLs desde las que se cargan? Pida al proveedor que demuestre la detección de un script que se carga desde un dominio de confianza y llama a un endpoint de exfiltración no autorizado. Si la demo necesita una URL de fuente maliciosa para activarse, la herramienta depende de la fuente.
Detección de patrones de código ofuscado. Pregunte específicamente sobre división de cadenas, equivalentes de eval() y decodificación dinámica de Base64. Las herramientas que solo detectan eval() literalmente se perderán la mayoría de la ofuscación real.
Monitorización conductual posterior a la carga. Muchos ataques obtienen su payload real de un servidor C2 después de la carga inicial de la página. La herramienta debe continuar monitorizando más allá de DOMContentLoaded, no solo en el parseo inicial.
Explicabilidad de las alertas. Una alerta que solo dice "script sospechoso detectado" no es accionable. Cada hallazgo debe identificar el script, el comportamiento que activó la detección y la llamada de red que intentó, para que un analista pueda clasificar sin adivinar.
Cómo encaja cside en este panorama
cside instrumenta el navegador a través de un script que se ejecuta dentro de cada sesión de visitante. Observa lo que cada script de terceros y propio hace en tiempo de ejecución: llamadas de red realizadas, cambios en el DOM aplicados, campos de datos sensibles accedidos y patrones de ejecución ofuscados detectados.
Cuando una CDN comprometida sirve un payload ofuscado a una página instrumentada por cside, la detección se activa en lo que el payload hace en tiempo de ejecución (llamada de red no autorizada, cadena eval ofuscada, patrón de exfiltración de datos) en lugar de en su origen. Un fallo en el allowlist de fuentes no puede producir un falso negativo en un sistema basado en el comportamiento.
Los requisitos 6.4.3 y 11.6.1 de PCI DSS v4.0.1 (obligatorios desde marzo de 2025) exigen a los comerciantes autorizar todos los scripts en las páginas de pago y detectar modificaciones no autorizadas en el contenido de los scripts o en las cabeceras HTTP. La monitorización conductual en la capa del navegador proporciona la evidencia a nivel de ejecución que esos controles esperan de una capa de monitorización que llega al interior del navegador en lugar de detenerse en el perímetro de red.
Para más información sobre las limitaciones prácticas de la CSP, consulte por qué la CSP no funciona. Para un análisis técnico de los métodos de ofuscación utilizados en ataques reales, consulte la guía de desofuscación de JavaScript de terceros.
