Outils de développement · Calculateur de hachage SHA
Intégrité des sous-ressources : comment les navigateurs utilisent SHA-384 pour vérifier les scripts
· Contexte
sha-256 base64 API du navigateur sécurité
L'attribut d'intégrité permet à un navigateur de refuser un script CDN dont les octets ont changé. Cet article explique le format de l'attribut, pourquoi SHA-384 en base64 est le choix courant et contre quoi SRI ne peut pas se protéger.
Le CDN qui peut servir à tout — le SRI sur les risques liés à la chaîne d'approvisionnement a été conçu pour
Une balise de script sur une page Web peut porter un attribut d'intégrité : `<script src="https://cdn.example.com/lib.js" integrity="sha384-..."></script>`. La valeur d'intégrité est un résumé cryptographique des octets du script. Lorsque le navigateur télécharge le script, il calcule le résumé des octets reçus et le compare à l'attribut d'intégrité. S'ils correspondent, le script est chargé. S'ils ne correspondent pas, le navigateur refuse de le charger et signale l'échec dans la console. Cela protège contre un CDN compromis diffusant du code modifié, ou contre un attaquant du réseau interceptant et modifiant la réponse.
Subresource Integrity (SRI) est une spécification du W3C qui s'applique aux scripts et aux feuilles de style. C'est la seule garantie cryptographique qu'un navigateur peut donner sur le contenu d'une ressource d'origine croisée : les octets doivent correspondre au résumé, sinon la ressource est rejetée. Cela ne prouve pas qui a créé la ressource, mais seulement qu'elle n'a pas changé depuis le calcul du résumé. Pour une ressource servie via HTTPS à partir d'un CDN réputé, le résumé fournit une protection contre la compromission du CDN ou contre la diffusion d'un contenu obsolète en cache pour vous spécifiquement.
L'attribut d'intégrité : préfixe d'algorithme, trait d'union, résumé base64 et prise en charge de plusieurs hachages
L'attribut d'intégrité a un format spécifique : nom-algorithme, trait d'union, résumé en base64. Exemple : `integrity="sha384-JZDdQnrrAMe+sxxpn47in+PwhkxrCrt4SNvt+xWqV3zPJUkeFF0Qq/wNtuvNqPP5"`. Le nom de l'algorithme peut être SHA-256, SHA-384 ou SHA-512. Base64 est le codage, pas hexadécimal ; il s'agit d'un choix délibéré de la spécification SRI. Base64 est plus compact que l'hexadécimal (environ 33 % plus court pour le même résumé), ce qui est important lors de l'intégration dans les attributs HTML. Le trait d'union sépare le nom de l'algorithme du résumé. Plusieurs valeurs d'intégrité peuvent être répertoriées, séparées par des espaces : si l'une d'entre elles correspond, la ressource est acceptée.
Pourquoi SHA-384 ? La spécification SRI autorise SHA-256, SHA-384 et SHA-512. SHA-384 est devenu la valeur par défaut de la communauté car il offre un solde de taille /security. SHA-256 est plus petit (32 octets, 44 caractères en base64) mais SHA-384 est plus large (48 octets, 64 caractères en base64) et n'a pas augmenté de manière significative la taille de l'attribut par rapport à SHA-256. SHA-512 est disponible mais rarement utilisé car son résumé plus volumineux ne semble pas nécessaire pour ce cas d'utilisation. Le choix de SHA-384 est historique et pragmatique, et ne reflète pas des propriétés de sécurité supérieures (les trois sont cryptographiquement forts à cet effet).
SHA-384 est proposé et produit le matériau base64 requis ; la préférence de la communauté n’est pas déduite de l’outil
L'encodage Base64 dans SRI est la base64 standard, et non l'url base64. La base64 standard utilise les caractères + et /, qui sont valides dans les attributs HTML sans codage en pourcentage, bien qu'ils aient une signification particulière dans les URL et les données de formulaire. Le format SRI est conçu pour les attributs HTML, pas pour les URL, la norme base64 est donc appropriée. Si vous créez une valeur d'intégrité à la main, vous calculez le résumé SHA-384 (une séquence d'octets), puis encodez ces octets en base64 standard, puis ajoutez `sha384-` et collez-le dans l'attribut d'intégrité.
Le navigateur effectue les mêmes étapes en sens inverse : extraire la base64 de l'attribut d'intégrité, décoder en octets pour récupérer le résumé, calculer SHA-384 des octets du script téléchargé et comparer les deux valeurs de résumé. Ils doivent correspondre exactement ; une différence d'un seul bit dans le résumé provoque le rejet. Il n’y a pas de correspondance floue ni de crédit partiel : l’intégrité est binaire.
Le comportement SRI d'origine croisée nécessite une documentation du navigateur au-delà de ce calculateur de hachage
SRI nécessite CORS sur les réponses d'origine croisée. Si vous chargez un script à partir d'une origine différente, le serveur doit répondre avec `Access-Control-Allow-Origin: *` ou un en-tête d'origine spécifique qui inclut le vôtre. Sans en-têtes CORS, le navigateur ne peut pas vérifier le SRI, car sans CORS, il ne peut pas confirmer que le corps de la réponse correspond à ce que le serveur avait l'intention d'envoyer. Les en-têtes CORS sont la déclaration du serveur selon laquelle cette réponse peut être vérifiée en toute sécurité ; SRI est votre vérification que les octets sont corrects. Ensemble, ils forment un engagement dans la chaîne d'approvisionnement : le serveur vous permet de vérifier le contenu, et vous le faites.
Si un script d'origine croisée ne dispose pas d'en-têtes CORS et possède un attribut d'intégrité, le navigateur le téléchargera (si les scripts de cette origine sont autorisés par le CSP du site), mais il ne vérifiera pas l'intégrité. Le script sera chargé comme si l'attribut d'intégrité était absent. Ce n’est pas un échec de l’ISR ; c'est une limite de sécurité : vous ne pouvez pas vérifier une réponse que vous ne pouvez pas lire.
Que se passe-t-il en cas de non-concordance : le navigateur bloque la ressource et signale dans la console
Lorsque le navigateur détecte une incompatibilité d'intégrité, il refuse d'exécuter le script et enregistre un message dans la console du navigateur. Le message nomme généralement l'URL, le hachage attendu et le hachage calculé. L'échec est atomique : soit la ressource est chargée telle quelle, soit elle est entièrement rejetée. Il n’y a pas de chargement partiel ni de repli. Si un site Web s'appuie sur ce script et que celui-ci est rejeté, le site peut tomber en panne. C’est intentionnel : fournir un mauvais code est pire que ne fournir aucun code, et les échecs silencieux permettent aux attaques de persister indéfiniment.
Tester une configuration SRI est simple : ouvrez la console du navigateur, chargez la page et recherchez les messages concernant les incompatibilités d'intégrité. Si vous constatez une incohérence, comparez le hachage calculé affiché dans la console avec celui de votre attribut d'intégrité. S'ils ne correspondent pas, recalculez : le script a peut-être été mis à jour et vous avez besoin d'un nouveau résumé.
Exemple pratique : calcul d'un résumé pour un script et formatage en une valeur d'intégrité, y compris l'étape base64
Le calcul manuel d'un résumé SRI ne nécessite que les octets de script et un outil de hachage. Téléchargez le script, collez-le dans le calculateur de hachage ToolAcre SHA, sélectionnez SHA-384, copiez la sortie base64 (pas l'hexadécimal), ajoutez `sha384-` et collez-le dans l'attribut d'intégrité. Si le script est volumineux, utiliser curl ou wget pour l'enregistrer dans un fichier, puis lire le fichier est plus rapide que le coller. Pour les scripts en ligne (dans une balise `<script>` dans le code HTML plutôt qu'à partir d'une URL), le SRI n'est pas applicable ; les scripts en ligne sont toujours fiables par définition. L'ISR est destiné aux ressources externes.
Un exemple concret : supposons que vous souhaitiez charger jQuery à partir d'un CDN avec SRI. Recherchez l'URL du script, téléchargez-la (ou utilisez curl pour la récupérer), collez les octets dans la calculatrice ou utilisez `sha384sum` sur la ligne de commande, obtenez le résumé SHA-384 en base64 et formatez-le en `sha384-[base64-digest]`. Collez-le dans l'attribut d'intégrité de la balise de script. Chargez la page et vérifiez qu'aucune erreur de console n'apparaît.
Ce que cela ne couvre pas : les scripts qui changent intentionnellement et les sites comme ToolAcre qui ne chargent aucun script externe et n'ont donc rien à épingler
L'ISR ne protège pas contre toutes les attaques de la chaîne d'approvisionnement. Il protège contre la modification des octets après le calcul du résumé, mais pas contre le calcul du résumé à partir du code compromis. Si un CDN est compromis avant que vous calculiez le résumé, SRI ne peut pas vous aider. Le résumé est aussi fiable que la source à partir de laquelle vous l’avez calculé. Pour une assurance maximale, calculez les résumés à partir de la source d'origine (les versions GitHub de la bibliothèque, par exemple) et utilisez ces résumés lors du chargement à partir d'un CDN. Le résumé devient un engagement de la part du responsable tout au long du processus de publication.
SRI ne protège pas non plus contre un réseau compromis au moment où vous calculez le résumé, ni contre une machine de développement compromise. Il protège uniquement contre les modifications apportées au script entre le moment où le résumé est créé et le moment où le navigateur charge le script. Pour une assurance continue, certains déploiements utilisent la signature de version en plus du SRI : la version est signée par la clé d'un responsable, vous vérifiez la signature, calculez le résumé à partir des octets vérifiés et utilisez-le dans SRI.
Cet article ne revendique pas l'inventaire de scripts externes de ToolAcre à l'échelle du site à partir de sources de hachage
Le calculateur de hachage ToolAcre SHA émet directement le résumé en base64 standard (en tant que sortie `base64` de la fonction `toBase64()`). Pour convertir au format SRI, ajoutez le nom de l'algorithme et un trait d'union : `sha256-`, `sha384-` ou `sha512-`. La calculatrice n'applique pas automatiquement ce préfixe car les hachages apparaissent dans de nombreux contextes (git, Docker, npm, URL) où le nom de l'algorithme est séparé ou codé différemment. La limite est claire : la calculatrice hache le texte UTF-8 que vous collez, pas les fichiers ou les clés binaires. Il produit à la fois hexadécimal et base64. Vous choisissez lequel utiliser en fonction de votre contexte. Pour SRI, base64 est requis par la spécification. Pour Git et d’autres outils, hex est conventionnel. Pour npm et Go, base64 est utilisé. Le choix de l’encodage vous appartient ; les octets de résumé sont les mêmes.
SRI reste l'une des rares vérifications cryptographiques qu'un navigateur peut effectuer côté client sans autorité centralisée. L'informatique se digère avec un outil fiable comme le calculateur SHA de ToolAcre et les vérifier par rapport aux ressources chargées est un moyen accessible de renforcer un site Web contre certaines attaques de la chaîne d'approvisionnement. La protection est aussi bonne que le digérer ; recalculez après chaque mise à jour de la ressource externe et testez que le navigateur charge le script sans le rejeter.