Por qué necesitas una política de seguridad de contenido sólida

La Importancia de los Encabezados de Seguridad

Cuando se diseñaron los navegadores por primera vez, nadie podría haber anticipado qué tipos de ataques serían posibles eventualmente. Algunos de los ataques que conocemos hoy podrían potencialmente eliminarse, o al menos limitarse, cambiando cómo funcionan los navegadores. Sin embargo, alterar el funcionamiento de los navegadores impactaría significativamente los servicios de internet existentes, por lo que no es una opción factible. ¿La alternativa? Proporcionamos a los usuarios con mayores necesidades de seguridad la capacidad de añadir capas adicionales de protección, conocidas como encabezados de seguridad. Cuando se visita un sitio, el servidor responde con un encabezado de respuesta HTTP. Esta es una instrucción adicional para tu navegador, haciendo que tu porción de internet—tu sitio web o aplicación web—sea más segura.

¿Qué es un CSP?

La Política de Seguridad de Contenidos, o CSP por sus siglas en inglés, es un ejemplo de dicho encabezado de seguridad [1,2]. La idea es simple: un CSP restringe lo que un navegador puede hacer con el contenido y de dónde puede provenir ese contenido. En la configuración predeterminada, hay pocas restricciones, lo que significa que un sitio web puede cargar contenido de casi cualquier fuente en internet. Esto incluye cosas aparentemente inocuas como imágenes, pero también código JavaScript que se ejecuta directamente en el navegador. Con un CSP, tú como propietario del sitio web determinas exactamente de dónde puede venir el contenido y bajo qué condiciones.

Piensa en el CSP como tu segunda línea de defensa. Si un atacante logra encontrar una vulnerabilidad, el CSP hace mucho más difícil que la explote. Consideremos un ejemplo concreto.

El Peligro del Cross-Site Scripting

Las vulnerabilidades de inyección de contenido y código en el frontend han sido un problema conocido durante mucho tiempo. Esta es una clase de vulnerabilidades donde los datos, como texto enviado por un usuario, no son procesados correctamente por la aplicación. Esto permite a un atacante evadir la seguridad y añadir su propio marcado (HTML), estilos (CSS) o código del lado del cliente (JavaScript) a la aplicación web. Esto es especialmente peligroso con JavaScript, ya que permite a un atacante ejecutar código del lado del cliente en el navegador de la víctima. Esto se conoce como cross-site scripting (XSS) y le da al atacante control total sobre la aplicación como si estuviera autenticado como la víctima.

Podrías pensar, "Pero si mi aplicación no es vulnerable a XSS, ¿no aporta nada un CSP?" ¿Estás realmente seguro de que no eres vulnerable? XSS puede ser uno de los métodos de ataque 'clásicos', pero sigue siendo un problema que afecta a muchas organizaciones. Más del 30% de las aplicaciones evaluadas por Computest Security en el último año fueron vulnerables a alguna forma de XSS [3]. Ten en cuenta que el cliente promedio de Computest Security ya es muy consciente de la seguridad y realiza pruebas de seguridad regularmente en sus aplicaciones. Por lo tanto, el número real de aplicaciones vulnerables a XSS probablemente sea aún mayor. No es un lujo establecer un CSP fuerte. Puede proporcionar ese extra de seguridad que necesitas para mitigar riesgos desconocidos.

¿Cómo Funciona el CSP?

Como con toda pregunta interesante, la respuesta es: depende. En este caso, depende de tu aplicación y cómo está estructurada. Veamos algunos ejemplos de posibles CSPs devueltos como encabezados de respuesta HTTP.

Centrarse en la directiva script-src, que maneja todas las fuentes de JavaScript como archivos *.js o código en línea entre etiquetas , esta directiva te protege contra vulnerabilidades con el mayor impacto.
Si tu aplicación (https://example.com) está configurada de manera que todo el JavaScript utilizado proviene de un dominio dedicado (https://js.example.com), entonces un CSP que te proteja contra muchos tipos de ataques XSS podría verse así:

Cualquier script cargado desde otra fuente no se ejecutará. Lo mismo aplica para cualquier JavaScript en línea. Si también se necesitan incluir scripts desde el mismo dominio que aloja la aplicación, podría verse así:

Permitir JavaScript en línea lo hace un poco más complejo ya que un navegador no puede distinguir entre contenido legítimo y contenido malicioso inyectado. Aun así, esto es posible usando nonces o hashes. Un nonce, un valor suficientemente aleatorio, puede incluirse en el encabezado CSP de la siguiente manera:

Este valor debe coincidir con el valor especificado en una etiqueta en la misma respuesta.

Si no se incluye el nonce adecuado, el código no se ejecuta. El valor del nonce cambia con cada solicitud, lo que impide que un atacante lo prediga con anticipación, haciendo que cualquier vulnerabilidad XSS potencial no sea explotable. Un método alternativo es usar un valor hash, calculado sobre el contenido completo de la etiqueta , asegurando que hashes no coincidentes signifiquen que no hay ejecución. Esto previene que un atacante inyecte su código malicioso.

Si no desarrollaste tu aplicación con un CSP en mente, elige una solución que se adapte a tu arquitectura. Afortunadamente, existen bibliotecas para varios frameworks de aplicaciones web que facilitan la implementación.

Los ejemplos proporcionados aquí no muestran todas las posibilidades de un CSP. Permite configuraciones detalladas para todos los recursos potenciales en una página HTML. ¿Interesado? Los enlaces al final de este blog ofrecen material de lectura adicional.

Errores de Implementación con un CSP

Ten cuidado, las cosas pueden salir mal al implementar un CSP. Particularmente al usar el enfoque de lista blanca de fuentes, existen trampas. En Computest Security, hemos visto a menudo que un CSP mal configurado se vuelve inútil o fácilmente eludible por un atacante. Ejemplos de tales errores incluyen:

• Si incluyes 'unsafe-inline' en la directiva script-src, esto permite todo el JavaScript en línea. Como su nombre indica, esto presenta un alto riesgo, anulando la mayoría de los beneficios de un CSP.
• Cuando se pueden subir y descargar archivos desde el dominio de la aplicación, existe un alto riesgo de que esto pueda ser explotado para eludir un CSP que permita ‘self’ en la directiva script-src, haciendo que tu aplicación sea vulnerable.
• Si permites un CDN o un host de fuente pública como AWS S3 (por ejemplo, https://s3.eu-central-1.amazonaws.com), un atacante puede usar estos servicios para alojar sus exploits maliciosos. Cualquiera puede crear una cuenta AWS para alojar recursos en S3, lo que representa riesgos potenciales.
• Si usas nonces, deben ser suficientemente aleatorios y usarse solo una vez. De lo contrario, un atacante puede reutilizar el nonce para sus ataques.
• Si permites JavaScript en línea con un valor nonce, el CSP no protege contra la inyección de JavaScript directamente en el script. Una etiqueta aprobada con un valor nonce siempre se ejecutará independientemente de su contenido.
• Los hosts permitidos con endpoints JSONP pueden ser explotados por atacantes para eludir parcialmente un CSP mediante el uso indebido de la funcionalidad de callback, potencialmente permitiendo la ejecución arbitraria de JavaScript.

Debido a estas configuraciones erróneas comunes, un CSP basado en nonce o hash combinado con 'strict-dynamic' se considera generalmente el enfoque más seguro [4]. Esto te permite especificar con precisión qué scripts pueden ejecutarse sin necesidad de incluir en la lista blanca todo el host. Un ejemplo de cómo podría verse:

Luego se puede incluir contenido adicional dentro del HTML:

Una Política de Seguridad de Contenido bien pensada y estricta determina con precisión qué puede suceder en el navegador cuando se carga su aplicación. Aunque una CSP fuerte no garantiza que su aplicación esté completamente protegida contra todos los ataques externos, lo pone en el camino correcto hacia un entorno en línea más seguro.

¿Interesado en ver si su organización se beneficiaría de una CSP? ¡Estamos aquí para ayudar! Contáctenos a través de [email protected] o llame al +31 (0)88 733 13 37 y le responderemos rápidamente.

Para más lectura sobre CSP:

1
2
3
4
5