La política de seguridad de contenidos (CSP) es una función de seguridad implementada en los navegadores web para proteger los sitios y aplicaciones web de diversos tipos de ataques, como los ataques de secuencias de comandos en sitios cruzados (XSS) y de inyección de datos. La CSP controla y limita las fuentes de los distintos tipos de contenido que se pueden cargar o ejecutar en una página web. Estos tipos de contenido incluyen:
- Guiones
- Hojas de estilo
- Imágenes
En este post, primero echaremos un vistazo a cómo funciona CSP. Veremos que un uso más eficaz y dinámico de CSP incluye algunos cálculos que deben realizarse en el servidor. Sin embargo, es posible trasladar ese cálculo a la periferia, reduciendo la latencia y garantizando una experiencia óptima para el usuario final. También exploraremos cómo podría funcionar esta solución de computación en el borde.
¿Está listo para sumergirse? Empecemos por entender cómo funciona la DEP.
Cómo funciona la DEP
Un CSP se define normalmente del lado del servidor añadiendo un elemento Content-Security-Policy a su respuesta HTTP. La envía el servidor web al usuario que solicita una página web. Esta cabecera especifica las reglas que debe seguir el navegador al cargar y ejecutar el contenido de la página.
Ejemplos de fijación del Content-Security-Policy cabecera
Digamos que está trabajando con Express en Node.js. Usted configuraría su cabecera CSP de esta manera:
const express = require('express'); |
Si estuvieras usando Python con Flask, entonces el código se vería así:
app = Flask(__name__) |
Trabajar con directivas
Cada cabecera CSP puede tener múltiples directivas, y cada directiva puede tener valores apropiados para el tipo de configuración proporcionada. Estas directivas definen las reglas de seguridad para varios tipos de recursos. Por ejemplo, la directiva script-src especifica las fuentes permitidas para las hojas de estilo.
Considere la siguiente cabecera CSP:
Content-Security-Policy: default-src 'self'; script-src 'self' https://static.example.com; style-src 'self' 'unsafe-inline'; |
En el encabezado anterior, vemos tres directivas, cada una con valores adjuntos.
- El
default-srcestablecida en'self'especifica que, por defecto, todo el contenido debe cargarse desde el mismo origen que la propia página. - El
script-srcpermite que los scripts se carguen desde el mismo origen ('self') y la fuente externa especificada (https://static.example.com). - El
style-srcpermite que las hojas de estilo se carguen desde el mismo origen y también permite estilos en línea.
En realidad, la lista de directivas disponibles es bastante exhaustiva. Puede consultarla aquí. Entre las directivas se incluyen:
font-src: Fuentes para fuentes cargadas con@font-faceframe-src: Fuentes para contextos de navegación anidados cargados en elementos como<frame>y<iframe>img-src: Fuentes de imágenes y favicons
Vincular el CSP al HTML
Una vez establecida la cabecera CSP en el servidor, el navegador aplica estas reglas al cargar recursos en la página web.
En el código fuente HTML, los desarrolladores pueden añadir elementos (como scripts u hojas de estilo) en línea o haciendo referencia a recursos (del mismo origen o de otro). El navegador comprobará entonces la cabecera CSP para asegurarse de que estos recursos cumplen las normas definidas. Si un recurso no está permitido por la CSP, el navegador bloqueará su inclusión y ejecución.
Único en cada solicitud
Debido a cómo se definen las cabeceras CSP, suelen ser consistentes en todas las peticiones de una página web concreta. Los detalles y las directivas para cada solicitud de una sola página serán los mismos con cada solicitud posterior de esa página.
Esto plantea una cuestión interesante: ¿Cómo trataríamos los scripts y estilos dinámicos en línea? Es posible que queramos permitir la ejecución de scripts y estilos en línea específicos sin abrir la puerta a la inclusión de todos los scripts y estilos en línea.
En este caso, es posible introducir valores nonce o hashes para garantizar que, aunque el origen de un script o estilo no figure explícitamente en el CSP, pueda ejecutarse siempre que coincida con el valor nonce o hash especificado en la cabecera del CSP.
Estos valores nonce o hashes pueden cambiar en cada solicitud, lo que los hace únicos. Por lo tanto, tendrían que ser generados y gestionados en un servidor. Sin embargo, el hecho de que estos nonces o hashes deban ejecutarse en un servidor no implica necesariamente que deban ejecutarse en el servidor principal de su sitio web. Y aquí es donde entra en juego el edge computing.
¿Qué es el edge computing?
La computación de borde es esencialmente el concepto de que algunos cálculos se pueden configurar para ejecutarse en el borde exterior de la red, geográficamente cerca de los usuarios finales. Básicamente, se trata de un tipo de computación distribuida que permite acercarse a velocidades de cálculo en tiempo real, incluso a través de Internet, al tiempo que reduce la latencia de la red.
Con la computación de borde, podría trasladar las preocupaciones, generando nonces y hashes para sus cabeceras CSP más cerca de sus usuarios finales, reduciendo el tiempo que tienen que esperar para que usted asegure su sitio.
Cómo puede ayudar la computación de frontera a la CSP
Una de las principales razones por las que CSP puede ralentizar su sitio es que los nonces de las cabeceras pueden provocar pérdidas de caché, lo que obliga al navegador de su cliente a ir hasta el servidor para que su sitio obtenga las cabeceras más recientes generadas correctamente. Para solucionar este problema, puede implementar un generador dinámico de CSP nonce en una instancia edge. Esto le proporcionará una forma de garantizar que su almacenamiento en caché sigue siendo útil a la vez que mantiene la seguridad.
Las ventajas de este planteamiento son las siguientes:
- Latencia reducida: La instancia de edge compute genera e inserta el nonce en la solicitud. Las solicitudes, ahora con el nonce insertado, continúan atravesando la caché, evitando así la necesidad de ir al servidor de origen para obtener nuevas respuestas cada vez que se realiza una solicitud.
- Seguridad distribuida: Utilizar la computación de borde significa que dispone de una capa adicional de seguridad antes de que los clientes necesiten interactuar con los servidores primarios y el código de aplicación de su sistema. Incluso si se produce una vulnerabilidad en la aplicación, la computación de borde que calcula el nonce CSP proporciona una capa adicional de seguridad, ayudándole a mitigar posibles problemas.
- Facilidad de mantenimiento: Si gestiona el nonce dinámico para el encabezado CSP en el borde con un enfoque sin servidor, esto simplificará sus tareas de mantenimiento. En concreto, puede gestionar las políticas CSP sin modificar el código de la aplicación. También puede gestionar normalmente este tipo de cambios desde un sistema de control central sin necesidad de realizar ningún despliegue de código especial. Estas funciones de computación de borde también pueden ser utilizadas por múltiples aplicaciones independientes, separando así las preocupaciones de los equipos específicos que trabajan en cada aplicación y permitiendo a los profesionales de la seguridad asegurarse de que se está produciendo la correcta generación de nonce.
Conclusión
¿Está interesado en aprender más sobre el uso del edge computing? Si es así, eche un vistazo a algunos de los productos destacados de Akamai. En particular, los EdgeWorkers crean una experiencia sin servidor que puede hacer exactamente lo que hemos estado discutiendo en este artículo, sin la complejidad de averiguar cómo implementar servidores en el extremo de sus redes.
Cuando estés listo para probarlo por ti mismo, ¡regístrate para una prueba gratuita hoy mismo! Es hora de trabajar en la seguridad de su sitio con mejores cabeceras CSP que no arruinen su esquema de almacenamiento en caché.
Comentarios