Encabezados de seguridad web: Política de seguridad de contenido (CSP) frente a la ejecución de JavaScript

En el panorama siempre cambiante de la seguridad web, proteger sus aplicaciones web contra vulnerabilidades como los ataques de cross-site scripting (XSS) es primordial. Dos herramientas poderosas en su arsenal son la Política de seguridad de contenido (CSP) y una comprensión profunda de cómo se ejecuta JavaScript en el navegador. Esta publicación de blog profundizará en las complejidades de la CSP, explorará su relación con la ejecución de JavaScript y proporcionará información práctica para desarrolladores y profesionales de la seguridad en todo el mundo.

Entendiendo la Política de seguridad de contenido (CSP)

La Política de seguridad de contenido (CSP) es un potente estándar de seguridad que ayuda a mitigar el cross-site scripting (XSS) y otros ataques de inyección de código. Funciona permitiéndole controlar los recursos que el navegador puede cargar para una página web determinada. Piense en ello como una lista blanca para el contenido de su sitio web. Al definir una CSP, básicamente le dice al navegador qué fuentes de contenido (scripts, estilos, imágenes, fuentes, etc.) se consideran seguras y de dónde pueden originarse. Esto se logra mediante el uso de encabezados de respuesta HTTP.

Cómo funciona la CSP

La CSP se implementa a través de un encabezado de respuesta HTTP llamado Content-Security-Policy. Este encabezado contiene un conjunto de directivas que dictan qué fuentes están permitidas. Aquí hay algunas directivas clave y sus funcionalidades:

• default-src: Esta es la directiva de respaldo para todas las demás directivas de obtención (fetch). Si no se proporciona una directiva más específica, default-src determina las fuentes permitidas. Por ejemplo, default-src 'self'; permite recursos del mismo origen.
• script-src: Define las fuentes permitidas para el código JavaScript. Esta es posiblemente la directiva más crítica, ya que impacta directamente en cómo se controla la ejecución de JavaScript.
• style-src: Especifica las fuentes permitidas para las hojas de estilo CSS.
• img-src: Controla las fuentes permitidas para las imágenes.
• font-src: Define las fuentes permitidas para las fuentes tipográficas.
• connect-src: Especifica las fuentes permitidas para las conexiones (por ejemplo, XMLHttpRequest, fetch, WebSocket).
• media-src: Define las fuentes permitidas para audio y video.
• object-src: Especifica las fuentes permitidas para plugins como Flash.
• frame-src: Define las fuentes permitidas para marcos e iframes (obsoleto, use child-src).
• child-src: Especifica las fuentes permitidas para los web workers y el contenido de marcos incrustados.
• base-uri: Restringe las URL que se pueden usar en el elemento <base> de un documento.
• form-action: Especifica los puntos finales válidos para los envíos de formularios.
• frame-ancestors: Especifica los padres válidos en los que se puede incrustar una página (por ejemplo, en un <frame> o <iframe>).

A cada directiva se le puede asignar un conjunto de expresiones de origen. Las expresiones de origen comunes incluyen:

• 'self': Permite recursos del mismo origen (esquema, host y puerto).
• 'none': Bloquea todos los recursos.
• 'unsafe-inline': Permite JavaScript y CSS en línea. Generalmente, esto no se recomienda y debe evitarse siempre que sea posible. Debilita significativamente la protección que ofrece la CSP.
• 'unsafe-eval': Permite el uso de funciones como eval(), que a menudo se utilizan en ataques XSS. También es muy desaconsejable.
• data:: Permite URL de datos (por ejemplo, imágenes codificadas en base64).
• blob:: Permite recursos con el esquema blob:.
• https://example.com: Permite recursos del dominio especificado a través de HTTPS. También puede especificar una ruta específica, como https://example.com/assets/.
• *.example.com: Permite recursos de cualquier subdominio de example.com.

Ejemplos de encabezados CSP:

Aquí hay algunos ejemplos para ilustrar cómo se utilizan los encabezados CSP:

Ejemplo 1: Restringir JavaScript al mismo origen

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

              
                Copy
              
            
          

Esta política permite que el navegador ejecute JavaScript solo desde el mismo origen que la página. Esto previene eficazmente la ejecución de cualquier JavaScript inyectado desde fuentes externas. Este es un buen punto de partida para muchos sitios web.

Ejemplo 2: Permitir JavaScript del mismo origen y de una CDN específica

            Content-Security-Policy: script-src 'self' cdn.example.com;
            

              
                Copy
              
            
          

Esta política permite JavaScript del mismo origen y del dominio cdn.example.com. Esto es común en sitios web que utilizan una CDN (Red de entrega de contenido) para servir sus archivos JavaScript.

Ejemplo 3: Restringir hojas de estilo al mismo origen y a una CDN específica

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

              
                Copy
              
            
          

Esta política limita la carga de CSS al origen y a cdn.example.com, evitando la carga de hojas de estilo maliciosas de otras fuentes.

Ejemplo 4: Una política más completa

            Content-Security-Policy: default-src 'self'; script-src 'self' cdn.example.com; style-src 'self' fonts.googleapis.com; img-src 'self' data:; font-src fonts.gstatic.com;
            

              
                Copy
              
            
          

Este es un ejemplo más complejo que permite contenido del mismo origen, JavaScript del mismo origen y de una CDN, CSS del mismo origen y de Google Fonts, imágenes del mismo origen y URL de datos, y fuentes de Google Fonts. Tenga en cuenta que debe permitir explícitamente los recursos externos si su sitio los utiliza.

Hacer cumplir la CSP

La CSP se puede hacer cumplir de dos maneras principales:

• Modo de solo informe (Report-Only): Puede establecer el encabezado Content-Security-Policy-Report-Only. Este encabezado no bloquea ningún recurso, sino que informa las violaciones a un punto final especificado (por ejemplo, un servidor que usted controle). Esto es útil para probar una política de CSP antes de aplicarla, lo que le permite identificar posibles problemas y evitar romper su sitio web. El navegador aún intenta cargar los recursos, pero muestra una advertencia en la consola del desarrollador y envía un informe a su punto final especificado. El informe contiene detalles sobre la violación, como la fuente del recurso bloqueado y la directiva infractora.
• Modo de aplicación (Enforce): Cuando utiliza el encabezado Content-Security-Policy, el navegador aplica activamente la política. Si un recurso viola la política (por ejemplo, se carga un script desde una fuente no autorizada), el navegador lo bloqueará. Esta es la forma prevista y más eficaz de utilizar la CSP para la seguridad.

Ejecución de JavaScript y la CSP

La interacción entre la CSP y la ejecución de JavaScript es crítica. La directiva script-src de la CSP es el punto de control principal sobre cómo se maneja JavaScript. Cuando un navegador encuentra JavaScript, verifica la directiva script-src del encabezado CSP. Si la fuente de JavaScript está permitida, el navegador lo ejecuta. Si la fuente no está permitida, el script se bloquea y se genera un informe de violación si los informes están habilitados.

Impacto en la ejecución de JavaScript

La CSP impacta significativamente en cómo escribe y estructura su código JavaScript. Específicamente, puede afectar a:

• JavaScript en línea (Inline): El JavaScript escrito directamente dentro de las etiquetas <script> en su HTML a menudo está restringido. Usar 'unsafe-inline' en script-src relaja esta restricción, pero se desaconseja firmemente. Un mejor enfoque es mover el JavaScript en línea a archivos JavaScript externos.
• eval() y otra ejecución de código dinámico: Funciones como eval(), setTimeout() con un argumento de cadena y new Function() a menudo están restringidas. La expresión de origen 'unsafe-eval' está disponible pero debe evitarse. En su lugar, refactorice su código para evitar estas prácticas o utilice métodos alternativos.
• Archivos JavaScript externos: La CSP controla qué archivos JavaScript externos se pueden cargar. Esta es una defensa clave contra los ataques XSS que intentan inyectar scripts maliciosos.
• Manejadores de eventos (Event Handlers): Los manejadores de eventos en línea (por ejemplo, <button onclick=\"myFunction()\"></button>) a menudo se bloquean a menos que se permita 'unsafe-inline'. Es una mejor práctica adjuntar escuchadores de eventos en archivos JavaScript.

Mejores prácticas para la ejecución de JavaScript con CSP

Para utilizar eficazmente la CSP y asegurar la ejecución de su JavaScript, considere estas mejores prácticas:

• Evite el JavaScript en línea: Mueva todo el código JavaScript a archivos .js externos. Esto es lo más impactante que puede hacer.
• Evite eval() y otra ejecución de código dinámico: Refactorice su código para evitar el uso de eval(), setTimeout() con argumentos de cadena y new Function(). Estos son vectores de ataque comunes.
• Use nonces o hashes para scripts en línea (si es necesario): Si es absolutamente necesario usar scripts en línea (por ejemplo, para código heredado), considere usar un nonce (una cadena única generada aleatoriamente) o un hash (un resumen criptográfico del contenido del script). Agregue el nonce o el hash a su encabezado CSP y a la etiqueta del script. Esto permite que el navegador ejecute el script si coincide con los criterios especificados. Esta es una alternativa más segura que 'unsafe-inline', pero agrega complejidad.
• Utilice una política de CSP estricta: Comience con una política de CSP restrictiva (por ejemplo, script-src 'self';) y relájela gradualmente según sea necesario. Monitoree las violaciones utilizando el encabezado Content-Security-Policy-Report-Only antes de aplicar la política.
• Revise y actualice regularmente su política de CSP: Su aplicación web evolucionará con el tiempo, al igual que su política de CSP. Revise y actualice su política regularmente para asegurarse de que continúe brindando una protección adecuada. Esto incluye cuando agrega nuevas funciones, integra bibliotecas de terceros o cambia la configuración de su CDN.
• Use un Firewall de Aplicaciones Web (WAF): Un WAF puede ayudar a detectar y mitigar ataques que podrían eludir su CSP. Un WAF actúa como una capa adicional de defensa.
• Considere la seguridad en el diseño: Implemente principios de seguridad desde el inicio de su proyecto, incluidas prácticas de codificación segura y auditorías de seguridad periódicas.

La CSP en acción: Ejemplos del mundo real

Veamos algunos escenarios del mundo real y cómo la CSP ayuda a mitigar las vulnerabilidades:

Escenario 1: Prevención de ataques XSS desde fuentes externas

Un sitio web permite a los usuarios enviar comentarios. Un atacante inyecta JavaScript malicioso en un comentario. Sin CSP, el navegador ejecutaría el script inyectado. Con una CSP que solo permite scripts del mismo origen (script-src 'self';), el navegador bloqueará el script malicioso porque se origina en una fuente diferente.

Escenario 2: Prevención de ataques XSS por compromiso de una CDN de confianza

Un sitio web utiliza una CDN (Red de entrega de contenido) para servir sus archivos JavaScript. Un atacante compromete la CDN y reemplaza los archivos JavaScript legítimos por otros maliciosos. Con una CSP que especifica el dominio de la CDN (por ejemplo, script-src 'self' cdn.example.com;), el sitio web está protegido, ya que limita la ejecución solo a los archivos alojados en el dominio específico de la CDN. Si la CDN comprometida utiliza un dominio diferente, el navegador bloquearía los scripts maliciosos.

Escenario 3: Mitigación de riesgos con bibliotecas de terceros

Un sitio web integra una biblioteca de JavaScript de terceros. Si esa biblioteca se ve comprometida, un atacante puede inyectar código malicioso. Al utilizar una CSP estricta, los desarrolladores pueden limitar la ejecución de JavaScript de la biblioteca de terceros especificando directivas de origen en su política de CSP. Por ejemplo, al especificar los orígenes específicos de la biblioteca de terceros, el sitio web puede protegerse contra posibles exploits. Esto es particularmente importante para las bibliotecas de código abierto, que a menudo se utilizan en muchos proyectos en todo el mundo.

Ejemplos globales:

Considere el diverso panorama digital del mundo. Países como la India, con sus grandes poblaciones y acceso generalizado a Internet, a menudo enfrentan desafíos de seguridad únicos debido al creciente número de dispositivos conectados. Del mismo modo, en regiones como Europa, con el estricto cumplimiento del RGPD (Reglamento General de Protección de Datos), el desarrollo seguro de aplicaciones web es primordial. El uso de una CSP y el empleo de prácticas seguras de JavaScript pueden ayudar a las organizaciones de todas estas regiones a cumplir con sus obligaciones de cumplimiento de seguridad. En países como Brasil, donde el comercio electrónico está creciendo rápidamente, asegurar las transacciones en línea con CSP es crucial para proteger tanto al negocio como al consumidor. Lo mismo ocurre en Nigeria, Indonesia y en todas las naciones.

Técnicas avanzadas de CSP

Más allá de lo básico, varias técnicas avanzadas pueden mejorar su implementación de CSP:

• CSP basada en nonce: Al trabajar con scripts en línea, los nonces proporcionan una alternativa más segura a 'unsafe-inline'. Un nonce es una cadena única generada aleatoriamente que usted genera para cada solicitud e incluye tanto en su encabezado CSP (script-src 'nonce-SU_NONCE';) como en la etiqueta <script> (<script nonce=\"SU_NONCE\">). Esto le dice al navegador que solo ejecute scripts que tengan el nonce correspondiente. Este enfoque limita en gran medida las posibilidades de que los atacantes inyecten código malicioso.
• CSP basada en hash (SRI - Subresource Integrity): Esto le permite especificar el hash criptográfico del contenido del script (por ejemplo, utilizando el algoritmo SHA-256). El navegador solo ejecutará el script si su hash coincide con el del encabezado CSP. Esta es otra forma de manejar scripts en línea (menos común) o scripts externos. La integridad de subrecursos (Subresource Integrity) se utiliza generalmente para recursos externos como bibliotecas de CSS y JavaScript, y protege contra el riesgo de que una CDN comprometida sirva código malicioso que sea diferente de la biblioteca prevista.
• API de informes de CSP: La API de informes de CSP le permite recopilar información detallada sobre las violaciones de CSP, incluida la directiva infractora, la fuente del recurso bloqueado y la URL de la página donde ocurrió la violación. Esta información es esencial para monitorear, solucionar problemas y mejorar su política de CSP. Varias herramientas y servicios pueden ayudarle a procesar estos informes.
• Herramientas de creación de CSP: Existen herramientas que pueden ayudarle a generar y probar políticas de CSP, como CSP Evaluator y creadores de CSP en línea. Estas pueden agilizar el proceso de creación y gestión de sus políticas.

Ejecución de JavaScript y mejores prácticas de seguridad

Además de la CSP, considere las siguientes mejores prácticas generales de seguridad con respecto a JavaScript:

• Validación y saneamiento de entradas: Siempre valide y sanee las entradas del usuario en el lado del servidor y del cliente para prevenir XSS y otros ataques de inyección. Sanee los datos para eliminar o codificar caracteres potencialmente peligrosos, como los que se utilizan para iniciar un script.
• Prácticas de codificación segura: Siga los principios de codificación segura, como el uso de consultas parametrizadas para prevenir la inyección de SQL, y evite almacenar datos sensibles en el código del lado del cliente. Sea consciente de cómo el código maneja datos potencialmente sensibles.
• Auditorías de seguridad periódicas: Realice auditorías de seguridad periódicas, incluidas pruebas de penetración, para identificar y abordar vulnerabilidades en sus aplicaciones web. Una auditoría de seguridad, también conocida como prueba de penetración, es un ataque simulado a un sistema. Estas auditorías son esenciales para detectar vulnerabilidades que los atacantes pueden explotar.
• Mantenga las dependencias actualizadas: Actualice regularmente sus bibliotecas y frameworks de JavaScript a las últimas versiones para parchear vulnerabilidades conocidas. Las bibliotecas vulnerables son una fuente importante de problemas de seguridad. Utilice herramientas de gestión de dependencias para automatizar las actualizaciones.
• Implemente HTTP Strict Transport Security (HSTS): Asegúrese de que su aplicación web utilice HTTPS e implemente HSTS para obligar a los navegadores a conectarse siempre a su sitio a través de HTTPS. Esto ayuda a prevenir ataques de intermediario (man-in-the-middle).
• Use un Firewall de Aplicaciones Web (WAF): Un WAF agrega una capa adicional de seguridad al filtrar el tráfico malicioso y prevenir ataques que eluden otras medidas de seguridad. Un WAF puede detectar y mitigar solicitudes maliciosas, como inyecciones de SQL o intentos de XSS.
• Eduque a su equipo de desarrollo: Asegúrese de que su equipo de desarrollo comprenda las mejores prácticas de seguridad web, incluida la CSP, la prevención de XSS y los principios de codificación segura. Capacitar a su equipo es una inversión fundamental en seguridad.
• Monitoree las amenazas de seguridad: Configure sistemas de monitoreo y alerta para detectar y responder rápidamente a incidentes de seguridad. Un monitoreo eficaz ayuda a identificar y responder a posibles amenazas de seguridad.

Poniéndolo todo junto: una guía práctica

Construyamos un ejemplo simplificado para ilustrar cómo aplicar estos conceptos.

Escenario: Un sitio web simple con un formulario de contacto que utiliza JavaScript para manejar los envíos del formulario.

1. Paso 1: Analice las dependencias de la aplicación: Determine todos los archivos JavaScript, recursos externos (como CDN) y scripts en línea que utiliza su aplicación. Identifique todos los scripts necesarios para un funcionamiento adecuado.
2. Paso 2: Mueva el JavaScript a archivos externos: Mueva cualquier JavaScript en línea a archivos .js separados. Esto es fundamental.
3. Paso 3: Defina un encabezado CSP básico: Comience con una CSP restrictiva. Por ejemplo, si está utilizando el mismo origen, podría comenzar con lo siguiente:

               Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:;
               
   
                 
                   Copy
                 
               
             

4. Paso 4: Pruebe la CSP en modo de solo informe (Report-Only): Implemente inicialmente el encabezado Content-Security-Policy-Report-Only para identificar cualquier conflicto potencial. Recopile los informes y analícelos.
5. Paso 5: Aborde cualquier violación: Según los informes, ajuste el encabezado CSP para permitir los recursos necesarios. Esto puede implicar incluir en la lista blanca dominios de CDN específicos o, si es absolutamente necesario, usar nonces o hashes para scripts en línea (aunque esto rara vez es necesario si se siguen las mejores prácticas).
6. Paso 6: Despliegue y monitoree: Una vez que esté seguro de que la CSP funciona correctamente, cambie al encabezado Content-Security-Policy. Monitoree continuamente su aplicación en busca de violaciones y ajuste su política de CSP según sea necesario.
7. Paso 7: Implemente la validación y el saneamiento de entradas: Asegúrese de que el código del lado del servidor y del cliente valide y sanee las entradas del usuario para prevenir vulnerabilidades. Esto es fundamental para protegerse contra los ataques XSS.
8. Paso 8: Auditorías y actualizaciones periódicas: Revise y actualice regularmente su política de CSP, teniendo en cuenta nuevas funciones, integraciones y cualquier cambio en la arquitectura de la aplicación o las dependencias en las que se basa. Implemente auditorías de seguridad periódicas para detectar cualquier problema imprevisto.

Conclusión

La Política de seguridad de contenido (CSP) es un componente crítico de la seguridad web moderna, que trabaja junto con las prácticas de ejecución de JavaScript para proteger sus aplicaciones web de una amplia gama de amenazas. Al comprender cómo las directivas de CSP controlan la ejecución de JavaScript y al adherirse a las mejores prácticas de seguridad, puede reducir significativamente el riesgo de ataques XSS y mejorar la seguridad general de sus aplicaciones web. Recuerde adoptar un enfoque de seguridad por capas, integrando la CSP con otras medidas de seguridad como la validación de entradas, los Firewalls de Aplicaciones Web (WAF) y las auditorías de seguridad periódicas. Al aplicar consistentemente estos principios, puede crear una experiencia web más segura para sus usuarios, independientemente de su ubicación o la tecnología que utilicen. Asegurar sus aplicaciones web no solo protege sus datos, sino que también genera confianza con su audiencia global y construye una reputación de fiabilidad y seguridad.