Aussi disponible en : English · Español · Português · العربية
Générateur de hash SRI
Des valeurs integrity calculées dans votre navigateur, avec la balise entière y compris l’attribut que tout le monde oublie, et un vérificateur pour celui que vous avez déjà.
Qu’est-ce que Subresource Integrity ?
Quand une page charge un script depuis le serveur de quelqu’un d’autre — un CDN, un fournisseur d’analytique, un service de polices — elle lui accorde une confiance totale. Les octets qui reviennent s’exécutent avec tous les privilèges de votre page. Si ce serveur est compromis, ou sert simplement autre chose un beau jour, vos visiteurs l’exécutent.
Subresource Integrity est le remède. Vous placez une empreinte cryptographique du fichier attendu dans un attribut integrity de la balise script ou link. Le navigateur télécharge le fichier, le hache et refuse de l’exécuter si l’empreinte ne correspond pas. Un CDN compromis casse alors votre page au lieu de s’en emparer, ce qui est une bien meilleure panne.
L’attribut se présente comme sha384- suivi d’une chaîne en base64. Cette page calcule cette chaîne à partir d’un fichier que vous choisissez ou d’un texte que vous collez, vous donne la balise complète à copier et, dans l’autre mode, reprend un attribut que vous avez déjà pour vous dire si un navigateur l’accepterait.
Comment l’utiliser
- Donnez-lui les octets exacts du fichier. Choisissez le fichier local ou collez son contenu. L’empreinte porte sur les octets tels qu’ils sont servis : un simple saut de ligne final change la réponse, et c’est pourquoi générer depuis une copie reformatée par votre éditeur ne correspondra pas.
- Choisissez l’algorithme et copiez la balise, pas seulement la valeur. sha384 est l’usage courant et ce qu’emploient les exemples de la norme elle-même. La balise générée inclut crossorigin, qui n’est pas facultatif pour un fichier d’une autre origine.
- Ou passez à Vérifier pour tester un attribut existant. Collez l’attribut integrity à côté du fichier et vous obtenez un verdict, l’algorithme que le navigateur consulterait réellement, et la liste des expressions écartées.
Un second algorithme remplace le premier, il ne l’épaule pas
Voilà la règle autour de laquelle la page est bâtie, et presque personne ne la connaît. Lorsqu’un attribut integrity énumère plusieurs expressions, le navigateur ne les vérifie pas toutes et n’accepte pas une correspondance avec l’une quelconque d’entre elles. La norme dit qu’il choisit la fonction de hachage la plus forte de la liste et n’emploie que celle-là, écartant toutes les plus faibles avant la moindre comparaison. L’ordre est fixé : sha256 est plus faible que sha384, lui-même plus faible que sha512.
La conséquence est tranchante. Si vous indiquez un sha256 correct et un sha512 mal recopié, votre fichier est bloqué : l’empreinte correcte est jetée sans être lue. Si vous indiquez un sha256 erroné et un sha384 correct, le fichier se charge parfaitement et l’empreinte cassée n’a jamais compté. Ajouter un second algorithme ressemble à de la défense en profondeur et n’en est nullement ; c’est un remplacement, et cela déplace silencieusement toute votre confiance sur le plus fort des deux.
Il existe un cas où plusieurs empreintes signifient bien l’une quelconque de celles-ci, et c’est le cas utile : plusieurs expressions employant le même algorithme. C’est ainsi qu’on autorise deux versions acceptables d’un fichier pendant un déploiement, et le navigateur acceptera une correspondance avec n’importe laquelle. Donc sha384-A sha384-B est une véritable alternative, tandis que sha256-A sha512-B n’en est pas une.
Quand vous vérifiez un attribut ici, tout ce que cette règle écarte est listé à part, car la règle est invisible dans l’attribut lui-même et un verdict sans elle serait une énigme.
Deux autres choses qui le cassent en silence
La première est l’attribut crossorigin manquant. Les requêtes vers une autre origine porteuses d’integrity sont tenues d’employer CORS : une balise script pointant vers un CDN avec un attribut integrity et sans crossorigin ne se charge donc pas du tout — et l’échec ressemble exactement à une empreinte fausse, ce qui envoie les gens recalculer une valeur qui était juste depuis le début. Toutes les balises produites ici comportent crossorigin="anonymous". Cela suppose aussi que le CDN lui-même envoie des en-têtes CORS permissifs ; s’il ne le fait pas, SRI est inutilisable avec lui.
La seconde est la façon dont la valeur est calculée. La norme demande d’appliquer l’algorithme aux octets puis d’encoder le résultat en base64 — le base64 de l’empreinte brute. Quantité de bricolages hachent d’abord vers une chaîne hexadécimale et encodent celle-ci, ce qui produit une valeur d’allure correcte qui ne correspond jamais. Les longueurs trahissent la chose : une empreinte sha384 fait 48 octets et s’encode en 64 caractères base64, alors que le base64 de sa forme hexadécimale de 96 caractères en fait 128. Le générateur affiche les deux côte à côte pour que la différence se voie plutôt que d’être affirmée.
Une dernière, moins spectaculaire : un navigateur qui ne reconnaît pas un algorithme ignore cette expression au lieu de rejeter le fichier. C’est délibéré, et c’est ce qui permet d’ajouter aujourd’hui un algorithme futur sans rien casser — mais cela veut dire aussi qu’un attribut rempli d’algorithmes que personne ne prend en charge ne protège absolument rien.
Limites honnêtes
Cette page ne peut pas récupérer une URL à votre place. Un navigateur n’a pas le droit de lire depuis un script un fichier d’une autre origine, à moins que ce serveur ne l’autorise par CORS — la règle même qui rend crossorigin obligatoire sur la balise. Vous choisissez donc le fichier local ou vous collez le contenu, et tout outil qui semble télécharger l’URL pour vous le fait sur un serveur, ce qui revient à lui confier ce téléchargement. Le faire localement est à la fois l’option honnête et l’option privée.
L’empreinte porte sur les octets et sur rien d’autre. Elle ne vous dit pas que le fichier est sûr, bien écrit ou de la provenance que vous croyez — seulement qu’il n’a pas changé depuis que vous avez pris l’empreinte. Si vous hachez un fichier compromis, SRI vous garantit fidèlement le fichier compromis.
Elle vous fige aussi sur une version. Toute mise à jour du fichier, y compris un correctif de sécurité publié par l’éditeur, fera échouer la vérification tant que vous n’aurez pas régénéré la valeur. C’est l’arbitrage que fait SRI, et c’est pourquoi il convient bien mieux à des URL versionnées qu’à un latest flottant.
Enfin, integrity s’applique aux scripts et aux feuilles de style. Ce n’est pas un mécanisme général pour les images, les polices ou les requêtes fetch : une balise produite ici a sa place sur un élément script ou link, et nulle part ailleurs.
Pourquoi est-ce gratuit ?
Parce que cela ne coûte rien à faire tourner. Le hachage se fait dans votre navigateur au moyen de la Web Crypto API déjà présente ; le fichier que vous choisissez ne quitte pas votre machine, rien n’est envoyé et aucun serveur ne le voit.
Ni compte, ni inscription, ni rien réservé. Les règles viennent de la norme Subresource Integrity elle-même, et les contrôles qui les vérifient emploient les empreintes d’exemple qu’elle publie, recoupées avec une implémentation distincte.