Comprendre l’intégrité des sousressources

Si vous avez déjà utilisé une version d'une bibliothèque JavaScript hébergée sur un CDN, vous avez peut-être remarqué un aspect étrange intégrité sur l'attribut script. Cet attribut contient des fichiers illimités alphanumériques apparemment interminables que vous pourriez être tentés d’éliminer dans votre quête de code plus propre.

Toute cette information indésirable est en réalité une fonctionnalité de sécurité très utile appelée SRI (Sub-Source Integrity) qui peut vous aider à défendre votre site contre certaines types de piratages et de compromis. Dans cet article, nous examinerons ce qu'est l'ISR, comment il peut vous protéger et comment l'utiliser dans vos propres projets, et pas seulement pour les fichiers hébergés sur des CDN.

19659002] À l'époque où JavaScript était le cousin le plus pauvre du HTML et du CSS, nous n'avions pas besoin de trop réfléchir à la manière dont nos scripts pourraient être utilisés comme vecteur d'attaque pour nos sites Web. La plupart des sites étaient tous hébergés sur un seul serveur physique, quelque part sur notre propre infrastructure d'hébergement, et c'était le serveur que nous pensions défendre en matière de sécurité.

Alors que les navigateurs devenaient plus performants et que les connexions réseau grossissaient, nous commencions pour utiliser de plus en plus de JavaScript, et finalement, des bibliothèques de JavaScript réutilisables ont commencé à jaillir. Dans les premiers temps, des bibliothèques telles que script.aculo.us, Prototype et éventuellement jQuery ont commencé à être adoptées par les développeurs qui cherchaient à ajouter plus d'interactivité à leurs pages.

Avec ces bibliothèques supplémentaires et les plugins suivants, le poids de la page a été augmenté. commençaient à réfléchir sérieusement à la performance initiale. Des ressources telles que les réseaux de diffusion de contenu (Content Delivery Network – CDN) qui constituaient auparavant une réserve d'entreprises gigantesques étaient en train de devenir monnaie courante pour la construction de sites Web accrocheurs.

Au cours du processus, des sources lumineuses ont remarqué que les sites réclamaient tous leur propre copie de bibliothèques communes – comme la dernière version de jQuery – et s’il existait une version CDN commune de ces bibliothèques pouvant être utilisée par tous les sites, l’utilisateur n’aurait alors pas besoin de télécharger le même fichier. Le premier site utiliserait le fichier, mais ce dernier serait placé dans la mémoire cache de son navigateur local et les téléchargements pourraient être ignorés pour chaque site suivant. Genius!

C’est la raison pour laquelle vous verrez les liens CDN de vos bibliothèques préférées qui utilisent des URL telles que jsdelivr.com – ils utilisent un CDN commun pour héberger les fichiers de manière à ce que leurs utilisateurs le voient. Avantages en termes de performances.

Que pourrait-il mal se passer?

Cela reste une bonne façon pratique de travailler, mais cela introduit un vecteur potentiel d’attaque. Imaginons qu’il s’agit de 2012 et que tout le monde utilise le tout nouveau jQuery 1.8. De retour avec la manière traditionnelle de faire les choses, tout le monde aurait son propre fichier jQuery 1.8 hébergé sur son propre serveur sur son propre site web.

Si vous étiez une sorte d'acteur pervers – comme une sorte de Hamburglar basé sur jQuery – et vous aviez trouvé un moyen sournois de pirater la bibliothèque pour vos propres gains pervers, il vous faudrait cibler chaque site Web individuellement et compromettre leurs serveurs pour avoir un impact quelconque. C’est beaucoup d’efforts.

Mais ce n’est plus la situation actuelle, tout le monde utilise jQuery chargé à partir d’un CDN commun. Et quand je dis tout le monde, je ne parle pas de centaines de pages Web. Je veux dire des millions de pages Web. Soudain, ce fichier est devenu une cible très attrayante pour notre pirate informatique louche. S'ils peuvent compromettre ce fichier, ils peuvent très rapidement avoir du code fonctionnant dans des millions de pages Web à travers le monde.

Peu importe la nature de ce code. Cela pourrait être une farce de déformer des pages, du code pour voler vos mots de passe, du code pour extraire la crypto-monnaie ou des suiveurs sournois pour vous suivre sur le Web et créer un profil marketing. L'important est que le fichier innocent que le développeur a ajouté à une page ait été modifié et que vous disposiez maintenant d'un JavaScript pervers en cours d'exécution sur votre site. C’est un gros problème.

Entrez l’intégrité des sous-ressources

Plutôt que de revenir en arrière et d’abandonner un moyen utile d’utiliser le code, SRI est une solution qui ajoute un niveau de sécurité simple. L'ISR et l'attribut d'intégrité d'intégrité consistent à s'assurer que le fichier que vous avez lié à une page ne change jamais. Et si cela change, le navigateur le rejettera.

Vérifier que le code n’a pas changé est un très vieux problème en informatique et, heureusement, il propose des solutions très bien établies. SRI réussit bien à adopter le hachage de fichier le plus simple.

Le hachage de fichier est le processus consistant à prendre un fichier et à l'exécuter via un algorithme qui le réduit à une représentation sous forme de chaîne courte, appelée hachage ou somme de contrôle. Sans entrer dans les mauvaises herbes, le processus est répétable ou réversible. Si bien que si vous donniez à un tiers un fichier avec le hachage, il serait capable d’exécuter le même algorithme pour vérifier que les deux correspondent. Si le fichier change ou que le hachage change, alors il n'y a plus de correspondance et vous savez que quelque chose ne va pas et devrait vous méfier du fichier.

Lorsque vous utilisez SRI, votre page Web contient le hachage et le serveur (CDN ou ailleurs) conserve le fichier. . Le navigateur télécharge le fichier, puis le calcule rapidement pour s'assurer qu'il correspond au hachage de l'attribut Integrity . S'il correspond, le fichier est utilisé et s'il est bloqué.

Essayez-le

Si je passe à aujourd'hui, getbootstrap.com pour obtenir un lien CDN vers une version de Bootstrap, I On me donne une étiquette qui ressemble à ceci:

Vous pouvez voir que l'attribut src est celui auquel nous sommes habitués, et l'attribut d'intégrité contient ce que nous savons maintenant. être un hash.

Le hash est en fait en deux parties. Le premier est un préfixe pour déclarer quel algorithme de hachage utiliser. Dans ce cas, il s’agit de sha384 . Ceci est suivi d'un tiret et ensuite du hachage lui-même, codé avec base64 .

(Vous connaissez peut-être base64 comme moyen de coder des fichiers en ligne comme des images dans des pages. Ce n'est pas un processus cryptographique, c'est simplement un moyen rapide et pratique de coder des données potentiellement désordonnées de manière à ce qu'elles soient parfaitement converties en ASCII. C'est pourquoi elles sont beaucoup utilisées sur le Web.)

Le navigateur va télécharger

. bootstrap.min.js . Avant de l’exécuter, il base64 décodera le hachage, puis utilisera l’algorithme de hachage sha384 pour confirmer que celui-ci correspond au fichier qu’il vient de télécharger. Si le fichier correspond, le fichier est exécuté.

Je peux le vérifier en plaçant cette balise dans une page, puis en basculant sur l'onglet Réseau de mes outils de navigateur pour vérifier que le fichier a été chargé.

Je constate que bootstrap.min.js (et le fichier jQuery dont il a besoin) ont été chargés avec succès.

Voyons ce que Il se passerait si j'actualisais le hachage comme quelque chose que je sais être incorrect.

Comme vous pouvez le constater, le hachage spécifié dans ma page n'est plus correspond au fichier, de sorte que le fichier est bloqué.

Utilisation de SRI dans vos propres projets

Posséder cette fonctionnalité pour les bibliothèques sur un CDN est excellent, et si vous voyez l'option d'utiliser un fichier incorporé avec une intégrité attribuez alors vous devriez définitivement favoriser cette option. Mais cela ne se limite pas aux gros projets sur les CDN, vous pouvez l’utiliser vous-même pour vos propres sites.

Il n’est pas exagéré de penser à un scénario dans lequel un pirate informatique parvient à accéder à quelques fichiers de votre site. Je pense que la plupart d’entre nous avons vu un client, un collègue ou un ami qui a déjà eu un site WordPress compromis avec un foutre de bric-à-brac dont il ne se rendait même pas compte.

SRI peut également vous protéger. Si vous générez des hachages d'intégrité pour vos propres fichiers, votre site peut rejeter les modifications comme il le ferait pour un fichier hébergé à distance.

Génération de hachages

Vous pouvez, comme vous le souhaiteriez, exécuter certaines commandes à le terminal de votre ordinateur pour générer un hachage pour un fichier. Cet exemple de procédure provient de la page MDN Subresource Integrity :

 cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A

Cela récupère le contenu de FILENAME.js et le transmet comme entrée à openssl pour créer un résumé utilisant sha384 qui est ensuite transmis en tant qu'entrée une autre commande openssl en base64 code le résultat. Non seulement cela est compliqué et obscur, mais ce n'est pas non plus le genre de chose que vous voulez faire à la main chaque fois que votre fichier JavaScript change.

Plus utilement, vous voudrez peut-être l'intégrer d'une manière ou d'une autre dans le processus de construction de votre site, et comme vous pouvez l’imaginer, il existe de nombreuses options toutes faites. L’implémentation exacte varie énormément en fonction de votre projet, mais voici quelques éléments de base.

Si vous utilisez Gulp pour créer vos sites, il existe gulp-sri qui produira un fichier JSON avec un liste de vos fichiers et leurs hachages. Vous pouvez ensuite en faire usage sur votre site. Par exemple, pour un site rendu dynamiquement, vous pouvez créer un plug-in de modèle pour lire ce fichier et ajouter les hachages à vos modèles si nécessaire.

Si vous êtes toujours avec Gulp mais que vous avez un site statique (ou un site généré de manière statique) ) vous pouvez utiliser gulp-sri-hash qui va réellement parcourir vos pages HTML et modifier ces pages pour ajouter des hachages si nécessaire, ce qui est très pratique.

Si vous utilisez Webpack, il y a webpage-sous-ressource-intégrité qui, dans le vrai style Webpack, est plus complexe que tout être humain pourrait l'imaginer, mais semble fonctionner.

Pour ceux qui utilisent le moteur de gabarit pour guidons Handlebars, il semble qu'il en existe . ] options disponibles pour vous et si votre processus de construction est constitué de JavaScript, il existe des solutions simples ici aussi.

Si vous utilisez un CMS tel que WordPress, j'ai trouvé un plugin qui semble simplifier les choses, même si je ne l’ai pas essayé moi-même. Googler pour votre propre plate-forme de choix avec SRI ou Sub Resource Integrity vous orientera probablement dans la bonne direction.

Vous voulez essentiellement accrocher votre hachage à après vos fichiers JavaScript ont été minifiés et ensuite le faire Le hachage est disponible d'une manière ou d'une autre à n'importe quelle partie de votre système qui génère les balises

Source link