Comment puis-je m'assurer que mes fichiers JavaScript livrés sur un CDN ne sont pas modifiés?

Je travaille sur un scénario dans lequel certains fichiers JavaScript doivent être hébergés sur un CDN. Je veux avoir un mécanisme pour que, lorsque ces fichiers sont téléchargés côté utilisateur, je puisse m'assurer que les fichiers n'ont pas été falsifiés et proviennent bien du CDN spécifié.

Je comprends que la tâche est très facile si j'utilise SSL, mais je veux quand même m'assurer que les bons fichiers sont servis même sur HTTP sans SSL.

Pour autant que je puisse rechercher, il n'existe aucun mécanisme existant comme la signature numérique pour les fichiers JavaScript qui est pris en charge sur toutes les plates-formes. Ce n'est peut-être pas nécessaire?

Existe-t-il une méthode intégrée aux navigateurs pour vérifier l'auteur des fichiers JavaScript? Puis-je faire quelque chose pour le faire de manière sécurisée?

En fait, une fonctionnalité comme celle-ci est en cours de rédaction sous le nom d' intégrité des sous- ressources . Regardez dans l' integrityattribut de la <script>balise. Bien qu'il ne soit pas encore pleinement adopté dans tous les domaines , il remplit précisément cet objectif.

integrity

Contient des métadonnées en ligne qu'un agent utilisateur peut utiliser pour vérifier qu'une ressource extraite a été livrée sans manipulation inattendue. Voir Intégrité des sous-ressources.

La source

L'intégrité des sous-ressources (SRI) est une fonction de sécurité qui permet aux navigateurs de vérifier que les fichiers qu'ils récupèrent (par exemple, à partir d'un CDN) sont livrés sans manipulation inattendue. Cela fonctionne en vous permettant de fournir un hachage cryptographique auquel un fichier récupéré doit correspondre.

La source

Exemple:

<script src="https://example.com/example-framework.js"
    integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
    crossorigin="anonymous"></script>

Notez cependant que cela ne vous protégera pas contre les attaques de Man in the Middle si vous transférez vos ressources via HTTP simple. Dans ce cas, le code de hachage peut être usurpé par l'attaquant, rendant inutile la défense contre les fichiers de script manipulés.

Pour cette raison, vous devez toujours utiliser des connexions HTTPS sécurisées au lieu de HTTP simple en plus des mesures de sécurité décrites ci-dessus.

Vous recherchez des contrôles d'intégrité des sous-ressources .

Par exemple, voici l'extrait de code jQuery CDN:

<script src="https://code.jquery.com/jquery-3.1.0.js"
        integrity="sha256-slogkvB1K3VOkzAI8QITxV3VzpOnkeNVsKvtkYLMjfk="
        crossorigin="anonymous"></script>

Clause de non-responsabilité: comme toujours, vous ne devez considérer ces mécanismes que comme utiles lors de l'utilisation de https, car ils peuvent facilement être désactivés via MitM avec http

En plus du mécanisme des réponses ci-dessus, vous pouvez également utiliser les en- têtes de réponse http de la stratégie de sécurité du contenu sur la page parente.

http://www.html5rocks.com/en/tutorials/security/content-security-policy/

Politique de sécurité du contenu: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng ='

Il y a quelques points à noter ici. Le préfixe sha * - spécifie l'algorithme utilisé pour générer le hachage. Dans l'exemple ci-dessus, sha256- est utilisé. CSP prend également en charge sha384- et sha512-. Lors de la génération du hachage, n'incluez pas les balises. Les majuscules et les espaces sont également importants, y compris les espaces de début ou de fin.

En utilisant Chrome 40 ou une version ultérieure, vous pouvez ouvrir DevTools, puis recharger votre page. L'onglet Console contiendra des messages d'erreur avec le hachage sha256 correct pour chacun de vos scripts en ligne.

Ce mécanisme existe depuis un certain temps, donc la prise en charge du navigateur est probablement assez bonne, assurez-vous simplement de vérifier.

En outre, si vous souhaitez vous assurer que les anciens navigateurs non conformes ne sont pas non plus sécurisés, vous pouvez inclure un script de redirection synchrone en haut de la page qui n'est pas autorisé par la stratégie.

Il y a un point important sur ce que ce type de signature peut et ne peut pas faire. Il peut protéger l'utilisateur contre des attaques hypothétiques dans lesquelles quelqu'un modifie votre code. Il ne peut garantir à votre site que votre code est le code en cours d'exécution. En d'autres termes, vous ne pouvez toujours pas faire confiance à tout ce qui vient du client sur votre site.

Si votre modèle d'adversaire permet à un attaquant de modifier les fichiers JavaScript au fur et à mesure qu'ils sont livrés à partir d'un CDN, alors votre modèle d'adversaire permet à un attaquant de modifier la source de référence au fur et à mesure qu'elle est livrée pour supprimer toute tentative de vérification, pour modifier l'adresse source autrement que le CDN, et / ou de supprimer entièrement la référence au JavaScript.

Et n'ouvrons pas la boîte de vers de la façon dont votre application peut déterminer si le résolveur de l'utilisateur est ou ne résout pas correctement le CDN via des requêtes HTTP (ou tout autre mécanisme qui n'a pas de chaîne de confiance vérifiée).

/ etc / hosts:

#  ...
1.2.3.4    vile-pirates.org    trustworthy.cdn
#  ...

Vous pouvez garantir cela avec l'intégrité des sous-ressources. De nombreux CDN publics incluent des hachages SRI dans le code intégrable proposé sur les sites Web CDN. Par exemple, sur PageCDN, lorsque vous cliquez sur le fichier jquery sur la page jQuery CDN , vous avez la possibilité de copier l'URL ou d'utiliser la balise de script qui contient le hachage SRI comme ci-dessous:

<script src="https://pagecdn.io/lib/jquery/3.4.1/jquery.min.js" integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=" crossorigin="anonymous"></script>

Lors du chargement de la page, le navigateur émettra une demande pour cette ressource et à la fin de la demande, il fera correspondre le hachage du fichier reçu avec celui indiqué comme valeur d'intégrité dans la balise de script. Si les deux hachages ne correspondent pas, le navigateur rejettera le fichier jquery.

Pour le moment, cette fonctionnalité est prise en charge par 91% des navigateurs dans le monde. Plus de détails sur caniuse .