La protección resistente a la evasión de CSP hace referencia a controles de seguridad que detectan y bloquean JavaScript malicioso incluso cuando ese código usa ofuscación, carga dinámica o inyección desde hosts de confianza para evadir la Content Security Policy. La CSP impone un allowlist de fuentes de scripts aprobadas, pero no puede inspeccionar lo que esas fuentes aprobadas ejecutan. Los controles resistentes a la evasión observan el comportamiento en tiempo de ejecución de cada script dentro de la sesión del navegador, detectando amenazas que superan las comprobaciones de allowlist sin activar ninguna violación de política.
El ataque a la cadena de suministro de Polyfill[.]io en junio de 2024 mostró esta brecha. Más de 490.000 sitios web tenían cdn.polyfill[.]io en su allowlist de CSP. Cuando el dominio cambió de propietario y el nuevo operador sustituyó la librería legítima por malware ofuscado, cada sitio afectado cargó y ejecutó el payload malicioso mientras la CSP no reportó ninguna violación. (Investigación de Sansec, junio de 2024)
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.
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.
