SubResource Integrity (SRI): Fortifica tu web contra ataques al contenido que cargas remotamente

Durante el mes de Agosto de 2014 le dediqué una entrada a los riesgos de cargar contenido de terceros en tu web. Desde problemas como el Hotlinking o el RSS Injection, hasta poder sufrir ataques como el de la RSA o de malvertesing. Los problemas pueden ser muchos y por eso, en las auditorías de seguridad que realizamos usando nuestra plataforma Faast alertamos cuando una web carga contenido de un sitio de terceros que no está registrado a la misma compañía que estamos analizando.

Figura 1: Fortifica tu web contra ataques al contenido que cargas remotamente

Sin embargo, cargar contenido de terceros puede ser bueno y a veces necesario, sobre todo cuando hablamos del uso de CDNs (Content Delivery Networks) o aplicaciones JavaScript que se utilizan por muchos sitios y se actualizan en un único punto. ¿Cómo mitigar los riesgos de seguridad al cargar contenido externo y seguir disfrutando de las ventajas de hacerlo? Pues la propuesta del W3C es que utilices SRI: SubResource Integrity.

SRI: SubResouce Integrity

La propuesta es bastante sencilla y se basa en añadir a las etiquetas de link o de script dos nuevos campos, que son el campo integrity y el campo crossorigin para verificar que el archivo que se está cargando no ha sido manipulado y que es el mismo que se utilizó en la fase de creación de la web y que se cumple la política de seguridad CORS (Cross-Origin Resource Sharing) que llevan los navegadores - y a la que dedicaré un artículo próximamente -.

Figura 2: Estandarización de SRI por el W3C

Supongamos que tenemos una web a la que llamaremos WEB_A y queremos cargar un Script_JS en ella que está publicado en la WEB_B. Es decir, que en algún lugar en la WEB_A tenemos una entrada SCRIPT SRC=WEB_B/Script_JS. Si un atacante vulnera la seguridad de la WEB_B y cambia el Script_JS, entonces todos los navegantes de la WEB_A verán en riesgo su seguridad. Esto es lo que sucedió, por ejemplo, en el ataque a la web de la RSA Conference hace un par de años.

Figura 3: Ataque a la web de la RSA Conference vía JavaScript de terceros

Pero esto se puede proteger con SRI. Veamos un ejemplo con los blogs MSDN de Microsoft. En este caso, los Blogs MSDN de Microsoft cargan un script d la web de una CDN, en este caso de BootStrapCDN.com

Figura 4: Carga de un script sin protección SRI

Si alguien, como sucedió en el pasado con esta misma CDN, es capaz de manipular el contenido del script que va en el código, entonces todos los visitantes de los blogs de MSDN de Microsoft podrán ser atacados por malvertesing o por exploits que afecten a la seguridad de los equipos de los clientes y a la reputación del sitio.

Configuración de SRI en etiqueta Script

Sin embargo, según indica SRI, la inclusión de ese recurso podría hacerse de manera segura si en la etiqueta script que utiliza la web de los blogs MSDN de Microsoft se añaden las etiquetas integrity y crossorigin. Para ello, el desarrollador de la web primeramente genera el hash del archivo que quiere cargar con un algoritmo SHA-2 y lo codifica en Base64. Ese valor, precedido por el algoritmo que se ha utilizado para hacer el hash se añade a la etiqueta integrity. La opción de crossorigin debe seguir la política CORs de la web que se haya configurado.

Figura 5: Ejemplo de uso de SRI con etiquetas integrity y crossorigin en SCRIPT

Esto se puede calcular de muchas formas y en la misma especificación de SRI se muestra un ejemplo de cómo hacerlo con OpenSSL. 

Figura 6: Cálculo con OpenSSL del hash un string a cargarse remotamente

En el caso concreto de BootStrapCDN, en la web donde se publica el fichero JavaScript que debe ser cargado para sacar provecho de sus servicios se da directamente el hash que se debe utilizar para hacer la carga segura, algo que no se está utilizando en los blogs MSDN de Microsoft.

Figura 7: Recomendación de uso de SRI en web de BootStrapCDN

Una vez que se ha integrado en la web el recurso protegido con la opción integrity de SRI, el navegador comprobará el hash del fichero recibido antes de ser ejecutado o incluido en la web, por lo que si hubiera sido manipulado o cambiado el archivo a cargar, el navegador generaría una excepción y no lo cargaría.

Figura 8: Si el hash no es correcto, no se ejecuta el Script

De esta forma la carga de contenido de terceros en tu web estaría hecha de una forma más robusta, protegiendo la seguridad de los clientes que visiten tu web aún cuando los proveedores de contenido hayan sido vulnerados. Por ahora, no todos los navegadores implementan esta protección, pero es conveniente que vayas "hasheando" los archivos que cargas remotamente.

Saludos Malignos!