SRI : Contrôle d’intégrité des ressources web externes
Sommaire
I. Présentation
Dans cet article, nous allons parler du Subresource Integrity (SRI), un mécanisme de sécurité qui permet de s'assurer que les ressources provenant de sites externes n'ont pas été modifiées. Ce mécanisme a été créé par le W3C en juin 2016.
II. Le danger des ressources externes
L'utilisation de ressources externes lorsque l'on développe une application web est devenue monnaie courante, que ce soit pour l'affichage, l'inclusion d'image, la mise en place de trackers ou simplement pour utiliser des fonctions JavaScript prédéveloppées. Ce faisant, nous déléguons à d'autres sites web une partie de la sécurité de notre propre application. Que se passerait-il en effet si le site web externe depuis lequel je télécharge un fichier JavaScript est compromis ?
La réponse est simple : l'attaquant sera en mesure de modifier le fichier JavaScript téléchargé par tous mes visiteurs via mon site, et de leur faire exécuter des instructions JavaScript .
Pour rappel, le JavaScript est un langage très pratique et puissant utilisé par les navigateurs pour rendre les pages web dynamiques. Lorsqu'un attaquant peut faire exécuter à ses victimes du code JavaScript sous son contrôle, il peut rediriger les utilisateurs vers d'autres sites web, voler les jetons de session et identifiants des utilisateurs, ou simplement modifier de manière importante la façon dont notre site web s'affiche (on parle de défiguration).
Le risque de l'utilisation de ressources externes est aisé à comprendre lorsque l'on parle de fichiers JavaScript, insérés grâce à une balise telle que celle-ci :
<script src=http://exemple.com/fichier.js></script>
Mais d'autres ressources externes peuvent également être impactées, comme les fichier CSS ou les icônes au travers la balise HTML link :
<link href="/media/examples/link-element-example.css" rel="stylesheet">
Dès lors, un attaquant qui souhaite s'en prendre à votre application, mais qui n'y trouve pas de vulnérabilité pourra envisager de s'attaquer aux sites web depuis lesquels vous faites télécharger à vos utilisateurs des scripts. Bien que vous ayez mis le paquet sur la sécurité de votre application, vous n'avez aucun contrôle sur la sécurité des applications web sur lesquelles des ressources que vous utilisez sont présentes. On retrouve ici une philosophie commune avec les attaques de type Supply Chain Attack. Plutôt que de s'en prendre directement à notre cible, on va s'attaquer à un maillon de la chaine qu'elle ne contrôle pas vraiment et dans lequel elle à une confiance par défaut.
III. Utilisation et intérêt du SRI
C'est ici qu'intervient le Subressource Integrity (SRI), un mécanisme de sécurité intégré aux navigateurs qui leur permet d'interpréter correctement le code HTML suivant :
<script src="https://exemple.com/exemple-framework.js" integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC" crossorigin="anonymous"> </script>
L'idée est simple, mais efficace, on demande aux navigateurs de télécharger un script sur un autre site web, mais aussi de contrôler son intégrité au travers un condensat (hash) SHA384. Ainsi, si le script a été modifié par un attaquant, le navigateur ne l'exécutera pas (JavaScript) ou ne l'affichera pas (CSS, image) et affichera une erreur telle que celle-ci dans sa console de débogage :
On peut alors, pour une version que l'on sait "stable" d'un élément externe téléchargé, y apposer son condensat SHA384, calculé à l'aide de la commande suivante :
cat fichier.js | openssl dgst -sha384 -binary | openssl enc -base64 -A
Le site srihash.org permet également de générer des condensats SHA384 à partir d'une ressource disponible sur internet. Pour plus de sécurité et de flexibilité, on peut utiliser plusieurs formats de condensat, le navigateur choisira alors le plus robuste en fonction de ce qu'il sait traiter :
<script src="hello_world.js" integrity="sha384-dOTZf16X8p34q2/kYyEFm0jh89uTjikhnzjeLeF0FHsEaYKb1A1cv+Lyv4Hk8vHd sha512-Q2bFTOhEALkN8hOms2FKTDLy7eugP2zFZ1T8LCvX42Fp3WoNr3bjZSAHeOsHrbV1Fu9/A0EzCinRE7Af1ofPrw==" crossorigin="anonymous"> </script>
La majorité des navigateurs récents sont aujourd'hui compatibles avec ce mécanisme de sécurité, bien qu'il existe toujours de mauvais élèves :
À noter enfin l'utilisation obligatoire de l'attribut crossorigin="anonymous" qui permet de configurer les requêtes CORS pour les données de l'élément à télécharger. On s'assure ainsi que la requête faite à un autre domaine ne contiendra aucun élément d'authentification.
IV. Limites et effets de bord
L'utilisation du mécanisme SRI est un vrai plus en termes de sécurité, il permet d'ajouter un minimum de contrôle aux ressources externes et de limiter les risques d'une confiance par défaut faite à d'autres sites web. Cependant, un effet de bord doit être connu lorsque l'on utilise ce mécanisme.
Dans le cas où l'éditeur qui propose la ressource partagée met à jour de manière intentionnelle sa ressource, celle-ci va mécaniquement changer de condensat et rendre la ressource indisponible pour vos utilisateurs. Il faut alors être vigilant sur le fait de n'utiliser ce mécanisme que pour des noms de fichier versionnés, ce qui garantit qu'une même version ne sera jamais modifiée. C'est par exemple le cas de la librairie CSS/JS Bootstrap, qui propose sur son site web le code HTML d'insertion d'un fichier versionné, et avec l'option integrity, bravo à eux :
Il faut donc en principe éviter d'utiliser ce mécanisme sur des fichiers tels que https://exemple.com/javascript-latest.js ou même https://exemple.com/javascript.js, car rien n'indique que la ressource ne sera jamais modifiée.
Également, ce mécanisme possède quelques limites, notamment dans le cas où votre application web est en HTTP, auquel cas un attaquant menant une attaque par l'homme du milieu (Man In The Middle ou MITM) sera naturellement en capacité de modifier et le code du fichier JavaScript, et son condensat pour le faire accepter au navigateur.
Enfin, ce mécanisme reposant sur des algorithmes de hashage, il ne faut pas perdre de vue les attaques par collisions qui peuvent exister sur certaines versions des algorithmes de hashage (MD5, SHA-1). L'utilisation de SHA384 ou SHA512 est une base sûre (en février 2021 en tout cas :)).
V. Outil de détection
Si vous souhaitez à présent contrôler si votre application web est protégée et comporte ce mécanisme de sécurité, le plus simple est d'utiliser l'extension SRI Check (gratuite) de l'outil de sécurité BurpSuite (gratuit également :)).
Pour présenter rapidement BurpSuite, il s'agit d'un proxy local, que l'on positionne entre notre client (Firefox, Chrome) et le serveur web, celui-ci va donc voir passer toutes les requêtes et réponses. Nous pourrons alors mener un tas d'analyses, de rejeux et de modifications sur ces requêtes.
L'extension BurpSuite porte le nom de SRI Check et est disponible dans l'onglet dédié aux extensions :
Une fois cette extension ajoutée, il vous suffit de parcourir votre site web comme un utilisateur normal, de vous rendre dans Target et de sélectionner le nom de domaine que vous souhaitez contrôler :
Dans le cas où une balise SRI est manquante, BurpSuite vous l'indiquera (Missing Subresource Integrity Attribute) 🙂
