Política de seguridad de contenido (CSP): Una guía completa para la prevención de XSS

En el panorama digital actual, la seguridad web es primordial. Los ataques de Cross-Site Scripting (XSS) siguen siendo una amenaza frecuente y peligrosa para las aplicaciones web a nivel mundial. La Política de seguridad de contenido (CSP) es un potente encabezado de respuesta HTTP que proporciona una capa adicional de seguridad, lo que ayuda a mitigar el riesgo de vulnerabilidades XSS. Esta guía ofrece una visión general completa de CSP, su implementación y las mejores prácticas para proteger sus aplicaciones web contra los ataques XSS.

¿Qué es Cross-Site Scripting (XSS)?

Cross-Site Scripting (XSS) es un tipo de ataque de inyección en el que se inyectan scripts maliciosos en sitios web de confianza y benignos. Los ataques XSS se producen cuando un atacante utiliza una aplicación web para enviar código malicioso, generalmente en forma de un script del lado del navegador, a un usuario final diferente. Los fallos que permiten que estos ataques tengan éxito están muy extendidos y se producen en cualquier lugar donde una aplicación web utilice la entrada de un usuario dentro de la salida que genera sin validarla ni codificarla.

Hay tres tipos principales de ataques XSS:

• XSS almacenado (persistente): El script malicioso se almacena permanentemente en el servidor de destino (por ejemplo, en una base de datos, un foro de mensajes, un registro de visitantes, un campo de comentarios, etc.). Cuando un usuario visita la página afectada, se ejecuta el script almacenado.
• XSS reflejado (no persistente): El script malicioso se refleja en el servidor web, como en un mensaje de error, un resultado de búsqueda o cualquier otra respuesta que incluya parte o la totalidad de la entrada enviada al servidor como parte de la solicitud. El usuario debe ser engañado para que haga clic en un enlace malicioso o envíe un formulario que contenga el script malicioso.
• XSS basado en DOM: La vulnerabilidad existe en el propio código del lado del cliente. El script malicioso se ejecuta porque el entorno DOM del navegador se manipula para incluir el script del atacante.

Los ataques XSS pueden tener graves consecuencias, entre ellas:

• Robo de credenciales de usuario (cookies, tokens de sesión).
• Desfiguración de sitios web.
• Redirección de usuarios a sitios maliciosos.
• Instalación de malware.
• Obtención de acceso no autorizado a datos confidenciales.

¿Qué es la Política de seguridad de contenido (CSP)?

La Política de seguridad de contenido (CSP) es una capa adicional de seguridad que ayuda a detectar y mitigar ciertos tipos de ataques, incluidos los ataques de Cross-Site Scripting (XSS) y de inyección de datos. CSP se implementa mediante un encabezado de respuesta HTTP que le permite controlar los recursos (por ejemplo, scripts, hojas de estilo, imágenes, fuentes, marcos) que el navegador puede cargar para una página específica. Al definir un CSP estricto, puede reducir significativamente la superficie de ataque de su aplicación web y dificultar que los atacantes inyecten código malicioso.

CSP funciona definiendo una lista blanca de fuentes desde las que el navegador puede cargar recursos. Cualquier recurso cargado desde una fuente no permitida explícitamente en el CSP será bloqueado por el navegador. Esto evita la ejecución de scripts no autorizados y reduce el riesgo de ataques XSS.

Cómo funciona CSP: Directivas y fuentes

CSP se configura utilizando una serie de directivas, cada una de las cuales especifica una política para un tipo particular de recurso. Cada directiva consta de un nombre seguido de una lista de fuentes permitidas. Estas son algunas de las directivas CSP más utilizadas:

• `default-src`: Especifica la política predeterminada para la obtención de recursos si no hay otras directivas específicas de recursos presentes.
• `script-src`: Especifica las fuentes permitidas para el código JavaScript.
• `style-src`: Especifica las fuentes permitidas para las hojas de estilo (CSS).
• `img-src`: Especifica las fuentes permitidas para las imágenes.
• `font-src`: Especifica las fuentes permitidas para las fuentes.
• `connect-src`: Especifica las fuentes permitidas para realizar solicitudes de red (por ejemplo, AJAX, WebSockets).
• `media-src`: Especifica las fuentes permitidas para cargar recursos de vídeo y audio.
• `object-src`: Especifica las fuentes permitidas para los plugins, como Flash.
• `frame-src`: Especifica las fuentes permitidas para la incrustación de marcos (iframes).
• `base-uri`: Restringe las URL que se pueden utilizar en el elemento <base> de un documento.
• `form-action`: Restringe las URL a las que se pueden enviar formularios.
• `upgrade-insecure-requests`: Indica a los navegadores que actualicen automáticamente las solicitudes inseguras (HTTP) a solicitudes seguras (HTTPS).
• `block-all-mixed-content`: Evita que el navegador cargue cualquier recurso mediante HTTP cuando la página se carga a través de HTTPS.
• `report-uri`: Especifica una URL a la que el navegador debe enviar informes de violaciones de CSP. Obsoleto en favor de `report-to`.
• `report-to`: Especifica un punto final con nombre al que el navegador debe enviar informes de violaciones de CSP.

Los valores de fuente de uso común incluyen:

• `*`: Permite recursos de cualquier fuente (no recomendado para entornos de producción).
• `'self'`: Permite recursos del mismo origen (esquema, host y puerto) que el documento protegido.
• `'none'`: No permite la carga de recursos desde ninguna fuente.
• `data:`: Permite la carga de recursos a través del esquema `data:` (por ejemplo, imágenes en línea).
• `'unsafe-inline'`: Permite el uso de JavaScript y CSS en línea (muy desaconsejado).
• `'unsafe-eval'`: Permite el uso de `eval()` y funciones similares (muy desaconsejado).
• `'strict-dynamic'`: Especifica que la confianza otorgada explícitamente a un script presente en el marcado, acompañándolo con un nonce o hash, se propagará a todos los scripts cargados por ese script raíz.
• `'nonce-'`: Permite scripts o estilos con un atributo nonce coincidente.
• `'sha256-'`, `'sha384-'`, `'sha512-'`: Permite scripts o estilos con un hash SHA coincidente.
• `https://example.com`: Permite recursos de un dominio específico.

Implementación de CSP

CSP se puede implementar de dos formas principales:

1. Encabezado HTTP: El método preferido es configurar el servidor web para que envíe el encabezado de respuesta HTTP `Content-Security-Policy`. Esto le permite definir el CSP para cada página o recurso de su sitio web.
2. Etiqueta <meta>: CSP también se puede definir utilizando una etiqueta <meta> en la sección <head> de su documento HTML. Sin embargo, este método es menos flexible y tiene limitaciones en comparación con el uso del encabezado HTTP. Por ejemplo, las directivas `frame-ancestors`, `sandbox` y `report-uri` no se pueden utilizar en las etiquetas meta HTML.

Uso del encabezado HTTP

Para implementar CSP mediante el encabezado HTTP, debe configurar su servidor web para que incluya el encabezado `Content-Security-Policy` en sus respuestas. Los pasos de configuración específicos variarán según el servidor web que utilice.

Aquí hay ejemplos para servidores web comunes:

• Apache: Añada la siguiente línea a su archivo `.htaccess` o a la configuración del host virtual:

            Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:;"
            

              
                Copy
              
            
          

• Nginx: Añada la siguiente línea a la configuración del bloque del servidor:

            add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:;";
            

              
                Copy
              
            
          

• Node.js (Express): Utilice el middleware para establecer el encabezado:

            app.use(function(req, res, next) {
  res.setHeader("Content-Security-Policy", "default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:;");
  next();
});
            

              
                Copy
              
            
          

Uso de la etiqueta <meta>

Para implementar CSP mediante la etiqueta <meta>, añada la siguiente etiqueta a la sección <head> de su documento HTML:

            <meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:;">
            

              
                Copy
              
            
          

Consideraciones importantes:

• El atributo `http-equiv` debe establecerse en "Content-Security-Policy".
• El atributo `content` contiene las directivas CSP.
• Recuerde las limitaciones de usar etiquetas <meta> como se mencionó anteriormente.

Ejemplos de CSP

Aquí hay varios ejemplos de CSP con explicaciones:

1. CSP básico:

            Content-Security-Policy: default-src 'self';
            

              
                Copy
              
            
          

Esta política permite recursos sólo del mismo origen.

2. Permitir scripts de un dominio específico:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com;
            

              
                Copy
              
            
          

Esta política permite recursos del mismo origen y scripts de `https://example.com`.

3. Permitir estilos de una CDN:

            Content-Security-Policy: default-src 'self'; style-src 'self' https://cdn.example.com;
            

              
                Copy
              
            
          

Esta política permite recursos del mismo origen y estilos de `https://cdn.example.com`.

4. Permitir imágenes de cualquier fuente:

            Content-Security-Policy: default-src 'self'; img-src *;
            

              
                Copy
              
            
          

Esta política permite recursos del mismo origen e imágenes de cualquier fuente (no recomendado para producción).

5. Informes de violaciones de CSP:

            Content-Security-Policy: default-src 'self'; report-uri /csp-report-endpoint;
            

              
                Copy
              
            
          

Esta política permite recursos del mismo origen y envía informes de violaciones a `/csp-report-endpoint`. Se recomienda utilizar `report-to` en lugar de `report-uri`.

6. Uso de `report-to` y `report-uri` juntos para la compatibilidad:

            Content-Security-Policy: default-src 'self'; report-uri /csp-report-endpoint; report-to csp-endpoint;
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint; report-to csp-endpoint;
Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"/csp-report-endpoint"}]}
            

              
                Copy
              
            
          

Este ejemplo demuestra la configuración de un `report-uri` (para navegadores antiguos) y un punto final `report-to`, junto con la configuración del propio encabezado `Report-To`. Asegúrese de que su servidor gestione correctamente el encabezado `Report-To`, estableciendo correctamente el `group`, `max_age` y `endpoints`.

7. Uso de Nonces para scripts en línea:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0mN0nc3Str1nG';
            

              
                Copy
              
            
          

Esta política permite recursos del mismo origen y scripts en línea con el atributo nonce coincidente.

            <script nonce="rAnd0mN0nc3Str1nG">
  // Su código de script en línea aquí
</script>
            

              
                Copy
              
            
          

CSP en modo solo informe

CSP se puede implementar en dos modos:

• Modo de cumplimiento: El navegador bloquea los recursos que violan el CSP.
• Modo solo informe: El navegador informa de las violaciones de CSP a un punto final especificado sin bloquear ningún recurso.

El modo Solo informe es útil para probar y refinar su CSP antes de aplicarlo. Para habilitar el modo Solo informe, utilice el encabezado HTTP `Content-Security-Policy-Report-Only` en lugar del encabezado `Content-Security-Policy`.

Ejemplo:

            Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint;
            

              
                Copy
              
            
          

Esta configuración enviará informes a `/csp-report-endpoint` sin bloquear ningún recurso.

Mejores prácticas para la implementación de CSP

Aquí hay algunas de las mejores prácticas para implementar CSP de manera efectiva:

1. Comience con una política estricta: Comience con una política restrictiva que sólo permita recursos del mismo origen y relájela gradualmente según sea necesario.
2. Utilice Nonces o hashes para scripts y estilos en línea: Evite el uso de `'unsafe-inline'` y utilice nonces o hashes para permitir scripts y estilos en línea específicos.
3. Evite `'unsafe-eval'`: Si es posible, evite el uso de `'unsafe-eval'` ya que puede introducir riesgos de seguridad. Considere enfoques alternativos para la ejecución de código dinámico.
4. Utilice HTTPS: Asegúrese de que todos los recursos se carguen a través de HTTPS para evitar ataques de intermediarios. Utilice la directiva `upgrade-insecure-requests` para actualizar automáticamente las solicitudes inseguras.
5. Supervise las violaciones de CSP: Configure un punto final de informes para supervisar las violaciones de CSP e identificar posibles problemas de seguridad.
6. Pruebe su CSP a fondo: Pruebe su CSP en diferentes navegadores y entornos para asegurarse de que funciona como se espera.
7. Itere y refina: La implementación de CSP es un proceso iterativo. Supervise y refine continuamente su CSP a medida que evoluciona su aplicación.
8. Considere la directiva `strict-dynamic`: Utilice `strict-dynamic` para reducir la complejidad de su CSP propagando la confianza a los scripts cargados por scripts confiables.

Herramientas para CSP

Varias herramientas pueden ayudarle a generar, probar y supervisar CSP:

• Generadores de CSP: Herramientas en línea que generan directivas CSP basadas en los recursos de su sitio web.
• Herramientas para desarrolladores de navegadores: La mayoría de los navegadores modernos proporcionan herramientas para desarrolladores que pueden ayudarle a analizar las violaciones de CSP.
• Servicios de supervisión de CSP: Servicios que recopilan y analizan informes de violaciones de CSP.

CSP y marcos/bibliotecas

Cuando utilice marcos y bibliotecas, es importante configurar CSP correctamente para garantizar la compatibilidad y evitar problemas de seguridad. Aquí hay algunas consideraciones:

• Marcos JavaScript (por ejemplo, React, Angular, Vue.js): Estos marcos a menudo utilizan estilos en línea o generación de código dinámico, lo que puede requerir configuraciones CSP especiales (por ejemplo, nonces, hashes, `'unsafe-eval'`).
• Marcos CSS (por ejemplo, Bootstrap, Tailwind CSS): Estos marcos pueden utilizar estilos en línea o hojas de estilo externas, que deben permitirse en su CSP.
• Bibliotecas de terceros: Asegúrese de que cualquier biblioteca de terceros que utilice sea compatible con su CSP y no introduzca vulnerabilidades de seguridad.

CSP y CDN (Redes de entrega de contenido)

Las CDN se utilizan comúnmente para alojar activos estáticos como archivos JavaScript, hojas de estilo CSS e imágenes. Para permitir recursos de las CDN en su CSP, debe incluir explícitamente en la lista blanca los dominios de las CDN.

Ejemplo:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.jsdelivr.net; style-src 'self' https://cdnjs.cloudflare.com;
            

              
                Copy
              
            
          

Esta política permite scripts de jsDelivr y estilos del cdnjs de Cloudflare.

Errores comunes de CSP que deben evitarse

Estos son algunos errores comunes de CSP que debe evitar:

• Usar `*` como fuente: Permitir recursos de cualquier fuente puede negar los beneficios de CSP.
• Usar `'unsafe-inline'` y `'unsafe-eval'` sin justificación: Estas directivas pueden introducir riesgos de seguridad y deben evitarse si es posible.
• No supervisar las violaciones de CSP: No supervisar las violaciones de CSP puede impedirle identificar y solucionar problemas de seguridad.
• No probar CSP a fondo: Las pruebas insuficientes pueden conducir a un comportamiento inesperado y vulnerabilidades de seguridad.
• Configurar incorrectamente los nonces y los hashes: Los nonces y los hashes configurados incorrectamente pueden impedir que se carguen scripts y estilos legítimos.

Conceptos avanzados de CSP

Más allá de lo básico, varios conceptos avanzados de CSP pueden mejorar aún más su seguridad web:

• Directiva `frame-ancestors`: Especifica los padres permitidos que pueden incrustar un marco (iframe) en su página. Protege contra los ataques de secuestro de clics.
• Directiva `sandbox`: Habilita un sandbox para el recurso solicitado, aplicando restricciones a sus capacidades (por ejemplo, evitar la ejecución de scripts, el envío de formularios).
• Directiva `require-sri-for`: Requiere la integridad de los subrecursos (SRI) para los scripts o estilos cargados de fuentes externas. SRI garantiza que los archivos no hayan sido manipulados.
• API de tipos de confianza: Ayuda a evitar XSS basado en DOM al aplicar la seguridad de tipos en los receptores DOM.

El futuro de CSP

CSP evoluciona constantemente para hacer frente a los nuevos desafíos de seguridad. Los desarrollos futuros pueden incluir:

• Mejora del soporte del navegador: Mejoras continuas en el soporte del navegador para las funciones de CSP.
• Nuevas directivas y características: Introducción de nuevas directivas y características para hacer frente a las amenazas de seguridad emergentes.
• Integración con herramientas de seguridad: Integración más profunda con herramientas y plataformas de seguridad para automatizar la gestión y supervisión de CSP.

Conclusión

La Política de seguridad de contenido (CSP) es una herramienta poderosa para mitigar los ataques XSS y mejorar la seguridad web. Al definir una CSP estricta, puede reducir significativamente la superficie de ataque de su aplicación web y proteger a sus usuarios de código malicioso. La implementación efectiva de CSP requiere una planificación cuidadosa, pruebas exhaustivas y supervisión continua. Siguiendo las mejores prácticas descritas en esta guía, puede aprovechar CSP para mejorar la postura de seguridad de sus aplicaciones web y salvaguardar su presencia en línea en el ecosistema digital global.

Recuerde revisar y actualizar periódicamente su CSP para adaptarse a las amenazas de seguridad en evolución y asegurarse de que sus aplicaciones web permanezcan protegidas.