Integridad de Subrecursos (SRI): cómo funciona y qué no puede hacer

Cómo funciona la SRI

La SRI añade un atributo integrity a una etiqueta <script> o <link>. El atributo contiene un hash criptográfico del archivo que se espera, escrito como el nombre del algoritmo, un guion y el valor en base64. Se admiten SHA-256, SHA-384 y SHA-512; SHA-384 es una elección común.

<script src="https://cdn.example.com/lib/1.2.3/lib.min.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>

(El hash anterior es solo una ilustración del formato.) El navegador descarga el archivo, calcula su hash y compara el resultado con el atributo. Si coinciden, el script se ejecuta. Si no, el navegador bloquea el archivo y la página continúa sin él. Una etiqueta puede enumerar más de un hash, y el navegador acepta el archivo si coincide con el más fuerte que admite.

El atributo crossorigin

Para un archivo de otro origen, el navegador solo puede comprobar el hash si el servidor lo permite mediante CORS. Por eso las etiquetas externas con integrity llevan también crossorigin="anonymous", y el servidor debe enviar una cabecera Access-Control-Allow-Origin. Si no lo hace, el archivo no se carga.

Cómo obtener el hash

Sirve cualquier herramienta que pueda producir un resumen SHA-384 y codificarlo en base64. Una forma habitual por línea de comandos es openssl dgst -sha384 -binary file.js | openssl base64 -A, y anteponer sha384- al resultado. Genérelo a partir del archivo exacto que cargará su página, y desde su propia copia o una descarga verificada, no desde una dirección en vivo que no haya comprobado.

Contra qué protege la SRI

La SRI apunta a un solo riesgo: un archivo externo que se cambia después de que usted lo aprobó. Esto incluye un proveedor de alojamiento o de CDN que sufre una intrusión, una cuenta de una biblioteca de la que se toma el control y la manipulación entre el servidor y el navegador. Si el archivo cambia aunque sea en un carácter, el hash deja de coincidir y el navegador lo rechaza. Para archivos estáticos y con versión de terceros es un control barato y eficaz, y es una forma de asegurar la integridad a los efectos de PCI DSS 6.4.3.

Qué no puede proteger la SRI

• Scripts que cambian a propósito. Un proveedor que actualiza su script cada semana, o que sirve un archivo distinto a distintos visitantes, no puede fijarse a un solo hash. El servicio polyfill.io, por ejemplo, generaba su código dinámicamente a partir de datos de la solicitud, un tipo de entrega al que la SRI no se adapta (vea riesgo de JavaScript de terceros). Los contenedores de los gestores de etiquetas son otro ejemplo: el archivo cambia cada vez que alguien publica.
• Scripts en línea. El atributo integrity funciona con archivos externos. Para scripts en línea use en su lugar hashes o nonces de CSP (Política de Seguridad de Contenido para páginas de pago).
• Scripts que cargan otros scripts. La SRI comprueba el archivo al que está asociada, no lo que ese archivo cargue después.
• La página que lleva la etiqueta. Un atacante que pueda cambiar su HTML puede cambiar o quitar el atributo integrity. La SRI protege contra un host de archivos comprometido, no contra una página comprometida.
• Un archivo que ya era malicioso cuando se calculó su hash. La SRI demuestra igualdad, no seguridad.

Por qué se rompe la SRI y cómo convivir con ello

El fallo más común es una actualización legítima: el proveedor publica un archivo nuevo en la misma dirección, el hash deja de coincidir y el navegador bloquea un script del que su página de pago puede depender. Prepárese para eso:

• Use direcciones con versión (por ejemplo, un número de versión en la ruta) para que un archivo en una dirección no cambie después de que usted lo fijó.
• Mantenga el hash y la dirección en un solo lugar y actualícelos juntos después de revisar y probar la versión nueva.
• Pruebe en una página de preproducción antes de cambiar una página de pago en producción, porque un script bloqueado puede romper el pago.
• Monitoree los fallos de integridad y los cambios del lado del proveedor, para enterarse de una discrepancia antes que sus clientes.
• Considere alojar usted mismo una copia revisada cuando el proveedor no ofrezca archivos con versión.
• Recuerde el requisito entre orígenes: si el proveedor deja de enviar la cabecera CORS, el archivo no se carga aunque su contenido no haya cambiado.

Lo mejor es tratar la SRI como una capa más. Junto con una Política de Seguridad de Contenido, un inventario y la detección de cambios, cubre los casos que las demás no alcanzan.