Herramientas de desarrollo · Calculadora de hash SHA
Integridad de los subrecursos: cómo los navegadores utilizan SHA-384 para comprobar los scripts
· Antecedentes
sha-256 base64 APIS del navegador seguridad
El atributo de integridad permite que un navegador rechace un script CDN cuyos bytes hayan cambiado. Esta publicación explica el formato del atributo, por qué SHA-384 en base64 es la opción común y contra qué no puede proteger SRI.
La CDN que podría servir para cualquier cosa: el riesgo de la cadena de suministro para el que se diseñó la SRI
Una etiqueta de script en una página web puede llevar un atributo de integridad: `<script src="https://cdn.example.com/lib.js" integrity="sha384-..."></script>`. El valor de integridad es un resumen criptográfico de los bytes del script. Cuando el navegador descarga el script, calcula el resumen de los bytes recibidos y lo compara con el atributo de integridad. Si coinciden, se carga el script. Si no coinciden, el navegador se niega a cargarlo e informa el fallo en la consola. Esto protege contra una CDN comprometida que sirve código modificado o contra un atacante de red que intercepta y altera la respuesta.
Subresource Integrity (SRI) es una especificación del W3C que se aplica a scripts y hojas de estilo. Es la única garantía criptográfica que un navegador puede ofrecer sobre el contenido de un recurso de origen cruzado: los bytes deben coincidir con el resumen o el recurso será rechazado. Esto no prueba quién creó el recurso, sólo que no ha cambiado desde que se calculó el resumen. Para un recurso servido a través de HTTPS desde una CDN de buena reputación, el resumen proporciona una protección contra la CDN que se ve comprometida o que le entrega contenido almacenado en caché obsoleto específicamente a usted.
El atributo de integridad: prefijo de algoritmo, guión, resumen base64 y compatibilidad con múltiples hashes.
El atributo de integridad tiene un formato específico: nombre del algoritmo, guión, resumen en base64. Ejemplo: `integrity="sha384-JZDdQnrrAMe+sxxpn47in+PwhkxrCrt4SNvt+xWqV3zPJUkeFF0Qq/wNtuvNqPP5"`. El nombre del algoritmo puede ser SHA-256, SHA-384 o SHA-512. Base64 es la codificación, no hexadecimal; esta es una elección deliberada de la especificación SRI. Base64 es más compacto que hexadecimal (aproximadamente un 33% más corto para el mismo resumen), lo cual es importante al incrustarlo en atributos HTML. El guión separa el nombre del algoritmo del resumen. Se pueden enumerar varios valores de integridad, separados por espacios: si alguno de ellos coincide, se acepta el recurso.
¿Por qué SHA-384? La especificación SRI permite SHA-256, SHA-384 y SHA-512. SHA-384 se convirtió en el valor predeterminado de la comunidad porque ofrece un saldo de tamaño /security. SHA-256 es más pequeño (32 bytes, 44 caracteres en base64) pero SHA-384 es más ancho (48 bytes, 64 caracteres en base64) y no aumentó significativamente el tamaño del atributo en comparación con SHA-256. SHA-512 está disponible pero rara vez se usa porque su resumen más grande no parecía necesario para este caso de uso. La elección de SHA-384 es histórica y pragmática, no un reflejo de propiedades de seguridad superiores (los tres son criptográficamente fuertes para este propósito).
SHA-384 se ofrece y produce el material base64 requerido; La preferencia de la comunidad no se infiere de la herramienta.
La codificación Base64 en SRI es base64 estándar, no base64url. Base64 estándar usa caracteres + y /, que son válidos en atributos HTML sin codificación porcentual, aunque tienen significados especiales en URL y datos de formulario. El formato SRI está diseñado para atributos HTML, no para URL, por lo que el estándar base64 es apropiado. Si está creando un valor de integridad a mano, calcula el resumen SHA-384 (una secuencia de bytes), luego codifica esos bytes como base64 estándar, luego antepone `sha384-` y lo pega en el atributo de integridad.
El navegador realiza los mismos pasos a la inversa: extrae la base64 del atributo de integridad, decodifica en bytes para recuperar el resumen, calcula SHA-384 de los bytes del script descargado y compara los dos valores del resumen. Deben coincidir exactamente; una diferencia de un solo bit en el resumen provoca el rechazo. No hay concordancia difusa ni crédito parcial: la integridad es binaria.
El comportamiento de SRI entre orígenes requiere documentación del navegador más allá de esta calculadora de hash
SRI requiere CORS en respuestas de origen cruzado. Si carga un script de un origen diferente, el servidor debe responder con `Access-Control-Allow-Origin: *` o un encabezado de origen específico que incluya el suyo. Sin los encabezados CORS, el navegador no puede verificar el SRI, porque sin CORS no puede confirmar que el cuerpo de la respuesta coincide con lo que el servidor pretendía enviar. Los encabezados CORS son la declaración del servidor de que es seguro verificar esta respuesta; SRI es su verificación de que los bytes sean correctos. Juntos, forman un compromiso de cadena de suministro: el servidor le permite verificar el contenido, y usted lo hace.
Si un script de origen cruzado carece de encabezados CORS y tiene un atributo de integridad, el navegador lo descargará (si el CSP del sitio permite scripts de ese origen), pero no verificará la integridad. El script se cargará como si el atributo de integridad estuviera ausente. Esto no es un fracaso del SRI; es un límite de seguridad: no puedes verificar una respuesta que no puedes leer.
Qué sucede si no coinciden: el navegador bloquea el recurso y lo informa en la consola
Cuando el navegador detecta una discrepancia de integridad, se niega a ejecutar el script y registra un mensaje en la consola del navegador. El mensaje normalmente nombra la URL, el hash esperado y el hash calculado. El fallo es atómico: el recurso se carga tal cual o se rechaza por completo. No hay carga parcial ni respaldo. Si un sitio web se basó en ese script y se rechaza, el sitio puede fallar. Esto es intencional: entregar código incorrecto es peor que no entregar ningún código, y las fallas silenciosas permiten que los ataques persistan indefinidamente.
Probar una configuración SRI es sencillo: abra la consola del navegador, cargue la página y busque mensajes sobre discrepancias de integridad. Si ve una discrepancia, compare el hash calculado que se muestra en la consola con el de su atributo de integridad. Si no coinciden, vuelva a calcular: es posible que el script se haya actualizado y necesite un nuevo resumen.
Ejemplo resuelto: calcular un resumen para un script y formatearlo en un valor de integridad, incluido el paso base64
Calcular un resumen SRI manualmente requiere solo los bytes del script y una herramienta hash. Descargue el script, péguelo en la calculadora de hash SHA de ToolAcre, seleccione SHA-384, copie la salida base64 (no la hexadecimal), anteponga `sha384-` y péguelo en el atributo de integridad. Si el script es grande, usar curl o wget para guardarlo en un archivo y luego leer el archivo es más rápido que pegarlo. Para scripts en línea (en una etiqueta `<script>` en HTML en lugar de una URL), SRI no es aplicable; Los scripts en línea siempre son confiables por definición. El SRI es para recursos externos.
Un ejemplo resuelto: supongamos que desea cargar jQuery desde una CDN con SRI. Busque la URL del script, descárguelo (o use curl para recuperarlo), pegue los bytes en la calculadora o use `sha384sum` en la línea de comando, obtenga el resumen SHA-384 como base64 y formatee como `sha384-[base64-digest]`. Pegue en el atributo de integridad de la etiqueta del script. Cargue la página y verifique que no aparezcan errores de consola.
Lo que esto no cubre: scripts que cambian intencionalmente y sitios como ToolAcre que no cargan ningún script externo y, por lo tanto, no tienen nada que fijar.
SRI no protege contra todos los ataques a la cadena de suministro. Protege contra el cambio de bytes después de que se calcula el resumen, pero no contra el cálculo del resumen a partir de código comprometido para empezar. Si una CDN se ve comprometida antes de calcular el resumen, SRI no puede ayudar. El resumen es tan confiable como la fuente a partir de la cual lo calculó. Para obtener la máxima seguridad, calcule resúmenes de la fuente original (las versiones de GitHub de la biblioteca, por ejemplo) y utilícelos al cargar desde una CDN. El resumen se convierte en un compromiso del mantenedor a través del proceso de publicación.
SRI tampoco protege contra una red comprometida en el momento de calcular el resumen, ni contra una máquina de desarrollo comprometida. Solo protege contra cambios en el script entre el momento en que se crea el resumen y el momento en que el navegador carga el script. Para garantizar una seguridad continua, algunas implementaciones utilizan la firma de versión además de SRI: la versión se firma mediante una clave de mantenedor, usted verifica la firma, calcula el resumen a partir de los bytes verificados y lo usa en SRI.
Este artículo no afirma el inventario de scripts externos de todo el sitio de ToolAcre a partir de fuentes de hash.
La calculadora de hash ToolAcre SHA emite el resumen en base64 estándar directamente (como salida `base64` de la función `toBase64()`). Para convertir al formato SRI, anteponga el nombre del algoritmo y un guión: `sha256-`, `sha384-` o `sha512-`. La calculadora no aplica ese prefijo automáticamente porque los hash aparecen en muchos contextos (git, Docker, npm, URL) donde el nombre del algoritmo está separado o codificado de manera diferente. El límite es claro: la calculadora codifica UTF-8 el texto que usted pega, no archivos ni claves binarias. Produce tanto hexadecimal como base64. Tú eliges cuál usar según tu contexto. Para SRI, la especificación requiere base64. Para git y otras herramientas, hexadecimal es convencional. Para npm y Go, se utiliza base64. La elección de codificación es tuya; los bytes de resumen son los mismos.
SRI sigue siendo una de las pocas comprobaciones criptográficas que un navegador puede realizar en el lado del cliente sin una autoridad centralizada. La informática se digiere a sí mismo con una herramienta confiable como la calculadora SHA de ToolAcre y verificarlos con los recursos cargados es una forma accesible de proteger un sitio web contra ciertos ataques a la cadena de suministro. La protección es tan buena como el resumen; Vuelva a calcular después de cada actualización del recurso externo y pruebe que el navegador cargue el script sin rechazarlo.