Supervisión de subrecursos con Compute

Gestores y usuarios de aplicaciones tienen que lidiar a diario con incontables amenazas para la protección de API y aplicaciones web (WAAP). Entre las más molestas figuran los ataques a recursos de sitios web para robar datos de pago o contraseñas o para instalar malware. 

Con esto en mente, nos propusimos buscar una solución con la que supervisar los subrecursos y, así, simplificar la pesada gestión de las modificaciones y manipulaciones de recursos. En esta entrada del blog hacemos una radiografía del problema y te contamos cómo solventarlo con Compute, nuestro entorno informático sin servidores.

¿Qué es un recurso? ¿Y un subrecurso? 

«Un recurso puede ser cualquier cosa que tenga una identidad, p. ej., un documento electrónico, una imagen, un servicio (como un parte meteorológico) o un conjunto de otros recursos».
RFC 2396, agosto de 1998

Un subrecurso es un recurso que se carga como parte de otro recurso. En el ámbito de este proyecto, se trata de cualquier objeto que tenga un identificador de recurso uniforme (URI), como pueden ser las URL. Si un usuario solicita la carga de una página web (un recurso) en el navegador, el archivo CSS encargado del aspecto de esta y el archivo JavaScript que contiene la funcionalidad necesaria son subrecursos que también deben cargarse. Estos subrecursos se pueden cargar —y a menudo se cargan— desde un tercero especializado en distribuir a los usuarios contenidos con rapidez y fiabilidad, como una red de distribución de contenidos (CDN).

Al haberse diseñado a partir de nuestra CDN, Compute es el punto idóneo desde donde supervisar estos subrecursos: nuestra red de edge computing permite a los desarrolladores ejecutar lógica personalizada directamente en nuestra plataforma de edge cloud, cuya distribución se extiende por todo el mundo.

¿Y si un atacante modifica un subrecurso?

En caso de ataque por modificación de un subrecurso, los problemas derivados son diversos, pero todos se engloban en el género de la modificación de dependencias de secuencias de comandos o scripts.

La mayoría de los sitios web requieren, como mínimo, un archivo JavaScript para poder ofrecer las funciones previstas a los usuarios. Estos archivos JavaScript que son necesarios se conocen como «dependencias de scripts». Magecart sería el típico ataque cuya estrategia se basa en el uso indebido de dependencias de scripts; los atacantes inyectan código JavaScript en formularios de pago en línea para robar tarjetas de crédito.

Aunque el objetivo de los ataques suelen ser dependencias de terceros para modificar el script original, también se pueden producir ataques profundos. En estos el atacante adopta la fachada de un mantenedor de scripts legítimo, para luego pasar a acciones maliciosas. 

La modificación de dependencias de secuencias de comandos también facilita el scripting entre sitios (XSS) y la falsificación de peticiones entre sitios (CSRF):

• Los ataques XSS secuestran la cuenta o la sesión de navegación de un usuario. Así, el atacante logra robar datos de pago o contraseñas, e incluso instalar malware.

• Los ataques CSRF fuerzan a los usuarios de una aplicación web a enviar con esta una petición sin que lo sepan y sin su consentimiento. De este modo, los atacantes logran manipular el estado de la aplicación con el fin de cambiar contraseñas, transferir dinero, realizar compras y, en general, usar la funcionalidad de la aplicación con fines maliciosos.

¿Qué defensa hay contra la modificación de subrecursos?

La defensa más habitual contra la modificación de subrecursos es hacer un inventario de scripts, hojas de estilos y otros recursos que necesite tu aplicación y aplicar Subresource Integrity (SRI). La función de seguridad SRI es un atributo opcional —aunque muy recomendable— destinado a etiquetas de vínculo de scripts y hojas de estilo que los navegadores aplican verificando que los recursos se distribuyan desde servidores de origen o CDN sin que se operen modificaciones imprevistas o no autorizadas. Las infracciones que se produzcan se podrán notificar a un punto de conexión específico mediante encabezados de Content Security Policy (CSP).

Sin embargo, SRI no sirve en caso de inyección de un script malintencionado, ya que este no te lo pone fácil: no proporciona un atributo de integridad, así que el navegador no tendrá nada que aplicar. Aun así, con CSP podrás prevenir este ataque si implantas una política rigurosa (es decir, que exija que no haya inserciones sin medidas de seguridad, etc.).

¿Cómo reforzamos aún más las defensas frente a la modificación de subrecursos?

Es posible ejecutar excelentes mecanismos de defensa desde el edge.  Compute nos permite implementar un proxy que rastrea subrecursos y supervisa automáticamente cualquier infracción de las políticas CSP. Veamos cómo funciona exactamente.

La implementación de un proxy en Compute nos permite realizar un seguimiento de todos los subrecursos detectados en las respuestas a peticiones de cliente. Así, si el proxy detecta un nuevo subrecurso destinado a un sitio web concreto, puede enviar una alerta al responsable del servicio que le advierta de que scripts externos y archivos CSS han sufrido este tipo de cambios sin autorización. En líneas generales, este es el aspecto del proceso del proxy:

Por ejemplo, si un cliente presenta el archivo «index.html» de su sitio web a través de Fastly, el proxy de Compute detecta en la respuesta proveniente del servidor de origen todo el código fuente de script que no se haya detectado antes. Esta información nos sirve para generar una alerta o mostrar una notificación en la IU. De este modo, los responsables del sitio web saben si el proxy detecta subrecursos imprevistos, como https://sketchcdn.attacker.com/js/bootstrap.bundle.min.js, que se muestra en la captura de pantalla siguiente.

Asimismo, podemos agregar el encabezado Content-Security-Policy-Report-Only al proxy implementado en Compute para facilitar la supervisión automática de infracciones de políticas. Por ejemplo, si un atacante trata de modificar un script en un URI conocido, podemos proporcionar también un punto de conexión de notificaciones a través de Compute que permite al navegador notificar infracciones. Estas se reenvían luego al cliente (gracias a nuestras integraciones de registros en tiempo real).

Conclusión

Gracias a las posibilidades y a la posición de Compute, nuestro proyecto ha logrado implementar un proxy que supervisa cualquier ataque de modificación de subrecursos. Esto nos ha permitido, entre otros logros, crear el equivalente a las comprobaciones de integridad del navegador, pero en una ejecución fuera del navegador. ¿Cómo? Mediante un proceso independiente que captura recursos de terceros y los combina de manera periódica en un hash con fines comparativos. El responsable del sitio recibe así alertas de los cambios en la integridad de los recursos.

Si te interesa descubrir qué otras funciones tiene Compute, regístrate sin compromiso alguno y saca partido del saldo gratis que ofrecemos. No le des más vueltas: pruébalo.