Política de Seguridad de Contenidos
Una Política de Seguridad de Contenidos (CSP) es un estándar de seguridad del navegador definido por el World Wide Web Consortium (W3C). Ayuda a los desarrolladores a proteger los sitios web de ataques del lado del cliente como el cross-site scripting (XSS) y la inyección de datos. Al especificar fuentes confiables para scripts, estilos y medios, una CSP actúa como una lista blanca que los navegadores aplican automáticamente como parte del modelo de seguridad del lado del cliente del navegador.
Resumen (TL;DR)
- La CSP define qué fuentes puede confiar un navegador.
- Ayuda a bloquear scripts inyectados o no autorizados.
- Reduce los riesgos de XSS y exfiltración de datos.
- Se usa mejor junto con la validación de entrada y HTTPS.
- Requiere mantenimiento y pruebas continuas.
Entender la Política de Seguridad de Contenidos (CSP)
La Política de Seguridad de Contenidos (CSP) es una función de seguridad del navegador que se implementó para mitigar ciertos tipos de ataques basados en el navegador, como el cross-site scripting. La CSP fue estandarizada por el World Wide Web Consortium (W3C) en la especificación CSP Level 3, permite que un sitio web envíe un conjunto de reglas (a través de encabezados de respuesta HTTP o etiquetas dentro del HTML) que instruyen al navegador qué fuentes de contenido están permitidas.
Estas reglas, llamadas directivas, especifican orígenes aprobados para scripts, imágenes, estilos, iframes y más. El propósito principal de usar CSP es tener control total sobre de dónde se cargan los scripts, junto con controlar qué scripts tiene permitido ejecutar una página, intentando así prevenir que se ejecuten scripts inyectados o no autorizados.
Por ejemplo, una directiva CSP podría indicar que los scripts solo deben cargarse desde el propio dominio del sitio (hecho usando ‘self’), o desde dominios confiables específicos. El navegador bloqueará entonces cualquier archivo de script o script en línea que no sea de una fuente permitida, proporcionando una defensa crucial contra ataques XSS donde un atacante intenta inyectar etiquetas
Cómo funciona la Política de Seguridad de Contenidos (CSP)
Una Política de Seguridad de Contenidos se entrega a un navegador a través del encabezado de respuesta HTTP llamado `Content-Security-Policy`, o a través de una etiqueta meta en el HTML. La política consiste en directivas separadas por punto y coma, y cada directiva controla un tipo de recurso específico.
- ‘script-src’ self: permite scripts solo desde el mismo origen. Cualquier
- ‘connect-src’ self https://api.domain.com : permite llamadas AJAX/XHR/fetch solo al mismo sitio, o al dominio confiable api.domain.com. Esto previene que el código malicioso exfiltre datos a servidores desconocidos desde el sitio.
- img-src ‘self’ data: se puede usar para cargar imágenes solo desde el mismo sitio y bloquear imágenes externas, lo que se puede usar para prevenir fugas de datos a través de solicitudes de imagen.
Nonces CSP y Hashes CSP
CSP también admite mecanismos avanzados como nonces (‘nonce-abc123’) y hashes (‘sha256-xyz…’). Estos permiten que los scripts en línea se ejecuten de forma segura al probar criptográficamente su integridad. En lugar de prohibir todo el código en línea, los desarrolladores pueden autorizar selectivamente scripts específicos, mejorando la flexibilidad sin sacrificar la seguridad.
Hay multitudes de otras directivas que se pueden usar para otros tipos de datos como medios, fuentes, iframes, etc., pero la idea central de usar una Política de Seguridad de Contenidos es crear una lista blanca de fuentes confiables. Cuando el navegador carga una página y pregunta qué contenido cargar, primero consultará la CSP y aplicará estas reglas en cada carga. Cualquier script o recurso que cargue esta política no se cargará. Para una guía de implementación detallada, consulte la hoja de referencia OWASP CSP.
Directivas CSP Comunes y Su Propósito
| Directiva | Propósito | Caso de Uso Típico |
|---|---|---|
default-src | Establece una política base para todos los recursos cuando no se aplica otra regla. | Comience estricto: default-src 'none'; |
script-src | Controla qué fuentes de JavaScript están permitidas. | Lista blanca 'self', CDNs, o use scripts basados en nonce/hash. |
style-src | Limita de dónde se puede cargar CSS. | Use 'self'; evite 'unsafe-inline' cuando sea posible. |
img-src | Define fuentes de imagen confiables. | Prevenga fugas de datos a través de llamadas de imagen externas. |
connect-src | Restringe destinos AJAX, fetch y WebSocket. | Bloquee la exfiltración de datos a dominios desconocidos. |
frame-ancestors | Especifica qué sitios pueden incrustar sus páginas en iframes. | Prevenga clickjacking: frame-ancestors 'none'; |
report-uri / report-to | Define dónde se envían los informes de violación CSP. | Registre y analice las brechas CSP para ajustar la política. |
Cómo una CSP puede Proteger un Sitio Web
Mitigación de ataques XSS: En un ataque de cross-site scripting, o ataque XSS, un atacante generalmente encuentra una forma de inyectar y ejecutar código JavaScript malicioso en su página (como en una entrada no sanitizada). Por defecto, una CSP bloqueará cualquier script en línea de ejecutarse en la página, a menos que una directiva de política lo permita explícitamente. Esto significa que un atacante que inyecta algo como `` en una página, no se ejecutará (¡a menos que ‘unsafe-inline’ esté deshabilitado en la CSP!)
Bloqueo de scripts de terceros no autorizados: Muchos sitios tienen scripts de terceros para cosas como análisis, seguimiento de usuarios y publicidad. Con una CSP, los propietarios de sitios pueden limitar qué sitios externos pueden entregar scripts. Por ejemplo, si solo busca servir contenido desde `analytics.example.com` y nada más de example.com, la directiva script-src de CSP de su sitio puede permitir explícitamente solo eso.
Prevención de exfiltración de datos: Como se mencionó anteriormente, una CSP puede restringir acciones en una página que se pueden usar para detener que el código JavaScript malicioso envíe datos de vuelta a un dominio controlado por un atacante. Usar la directiva `connect-src` bloquea las solicitudes de red a servidores no autorizados, y se puede usar en combinación con la directiva `form-action` para asegurar que los datos solo se envíen a su dominio.
Aplicar prácticas de navegación seguras: Una CSP tiene directivas para aplicar comportamientos seguros que mejoran la seguridad de su sitio en general. Un ejemplo de esto es `upgrade-insecure-requests`, que fuerza al navegador a cargar todos los recursos sobre HTTPS, previniendo problemas de contenido mixto e inseguro. Otra directiva es `frame-ancestors`, que puede prevenir ataques de clickjacking al no permitir que su página se incruste en un marco controlado por un atacante.
Cómo CSP Previene Ataques Basados en el Navegador
1. Mitigación de ataques XSS:
En un ataque de cross-site scripting, o ataque XSS, un atacante generalmente encuentra una forma de inyectar y ejecutar código JavaScript malicioso en su página (como en una entrada no sanitizada). Por defecto, una CSP bloqueará cualquier script en línea de ejecutarse en la página, a menos que una directiva de política lo permita explícitamente. Esto significa que un atacante que inyecta algo como `` en una página, no se ejecutará (¡a menos que ‘unsafe-inline’ esté deshabilitado en la CSP!)
2. Bloqueo de scripts de terceros no autorizados:
Muchos sitios tienen scripts de terceros para cosas como análisis, seguimiento de usuarios y publicidad. Con una CSP, los propietarios de sitios pueden limitar qué sitios externos pueden entregar scripts. Por ejemplo, si solo busca servir contenido desde `analytics.example.com` y nada más de example.com, la directiva script-src de CSP de su sitio puede permitir explícitamente solo eso.
3. Prevención de exfiltración de datos:
Como se mencionó anteriormente, una CSP puede restringir acciones en una página que se pueden usar para detener que el código JavaScript malicioso envíe datos de vuelta a un dominio controlado por un atacante. Usar la directiva `connect-src` bloquea las solicitudes de red a servidores no autorizados, y se puede usar en combinación con la directiva `form-action` para asegurar que los datos solo se envíen a su dominio.
4. Aplicar prácticas de navegación seguras:
Una CSP tiene directivas para aplicar comportamientos seguros que mejoran la seguridad de su sitio en general.
- Un ejemplo de esto es `upgrade-insecure-requests`, que fuerza al navegador a cargar todos los recursos sobre HTTPS, previniendo problemas de contenido mixto e inseguro.
- Otra directiva es `frame-ancestors`, que puede prevenir ataques de clickjacking al no permitir que su página se incruste en un marco controlado por un atacante.
Combinadas, estas políticas resultan en una base sólida del lado del cliente para aplicaciones web modernas.
Limitaciones de Seguridad de CSP
Usar una Política de Seguridad de Contenidos proporciona una protección fuerte pero no es una solución definitiva para su sitio, como se destaca en nuestra publicación “Por qué la Política de Seguridad de Contenidos no funciona”.
Las políticas pueden desviarse con el tiempo, y las listas blancas no inspeccionan el comportamiento del código. Cada navegador principal implementa CSP a su manera, ligeramente diferente. Chrome, Firefox, Safari y Edge admiten CSP Level 3; el comportamiento de informes y los formatos de violación pueden variar. Para validar y mantener su política, pruébela regularmente con herramientas de desarrollador del navegador y escáneres automatizados como Mozilla Observatory o SecurityHeaders.io.
Emparejar una CSP con un proxy del lado del cliente activo como cside para agregar inspección y bloqueo en tiempo real a scripts de terceros en su sitio le brinda una gran capa de defensa, con tranquilidad para sus clientes. Desde una perspectiva de gobernanza, documentar las actualizaciones de CSP y monitorear los informes de violación mejora la auditabilidad y el cumplimiento a largo plazo con marcos como ISO 27001 y OWASP ASVS.
¿Funciona CSP para el Cumplimiento de PCI DSS 6.4.3?
Bajo el Requisito 6.4.3 de PCI DSS 4.0.1, los comerciantes deben probar que cada script del lado del cliente está autorizado y probar la integridad del script. CSP y SRI lo llevan parte del camino. CSP limita qué dominios pueden cargar scripts, y SRI verifica que el código de un archivo no haya cambiado. Pero juntos son una solución estática a un problema dinámico. Los scripts dinámicos se actualizan y los hashes se rompen. El mantenimiento manual de las listas CSP es casi imposible.
La mayoría de los sitios modernos usan scripts de terceros dinámicos, por lo que estos controles se degradan rápidamente. Este enfoque generalmente no alcanzará la evidencia requerida necesaria para PCI 6.4.3.
Un Ejemplo de una CSP Mal Configurada
El día que el check-out dejó de funcionar: Cómo una CSP Estricta Rompió la Producción
Todo comenzó con un despliegue nuevo ordinario. Nada especial, solo una nueva Política de Seguridad de Contenidos para hacer una tienda de comercio electrónico más segura y bloquear a los atacantes de colarse con código malo.
El default-src ‘none’ limpio se estableció sin pruebas. Y así, en el momento en que se activó la CSP, el sitio web bloqueó servicios que realmente necesitaba. Los análisis dejaron de funcionar y lo peor de todo, el sistema de pago fue bloqueado. Los clientes no pudieron completar sus pedidos y el sistema de check-out se rompió. Los desarrolladores se pusieron a trabajar y cambiaron el encabezado a Content-Security-Policy-Report-Only y recopilaron registros de violación. A partir de ahí, construyeron una lista blanca (script-src ‘self’ https://pay.examplecase.com) con todos los servicios que la tienda web necesitaba para funcionar correctamente.
Refinar la CSP permitió el despliegue sin interrupciones. Desafortunadamente, este descuido es un error común cuando los equipos gestionan CSP internamente. Olvidar agregar a la lista blanca un nuevo script de marketing, configuraciones técnicas incorrectas, o problemas con scripts dinámicos que rompen los protocolos de hash hacen que CSP sea una pesadilla de gestionar a escala.
