web-dev-qa-db-fra.com

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 souhaite disposer d'un mécanisme permettant de garantir que, lorsque ces fichiers sont téléchargés côté utilisateur, ils ne sont pas altérés et proviennent effectivement du CDN spécifié.

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

Autant que je pouvais chercher, il n’existait aucun mécanisme tel que la signature numérique pour les fichiers JavaScript qui soit pris en charge sur toutes les plateformes. Peut-être que ce n'est pas nécessaire?

Existe-t-il une méthode intégrée dans les navigateurs pour vérifier l’auteur des fichiers JavaScript? Y a-t-il quelque chose que je puisse faire pour le faire de manière sécurisée?

javascriptcode-signing
87
baba26

En fait, une caractéristique comme celle-ci est en cours de rédaction sous le nom de Intégrité de la sous-ressource. Regardez dans l'attribut integrity de la <script>tiquette. Bien que pas encore complètement adopté , il remplit exactement cet objectif.

integrity

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

Source

L’intégrité de sous-ressource (SRI) est une fonctionnalité 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.

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 attaques de type "Man in the Middle" si vous transférez vos ressources via HTTP simple. Dans ce cas, l'attaquant peut usurper le code de hachage, rendant la défense contre les fichiers de script manipulés inutile.

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

139
Timo

Vous recherchez intégrité de la sous-ressource contrôles.

Par exemple, voici l'extrait de CDN jQuery:

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

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

Outre le mécanisme des réponses ci-dessus, vous pouvez également utiliser les en-têtes de réponse http content-security policy sur la page parent.

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

Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng ='

Il y a quelques choses à 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. La capitalisation et les espaces ont également leur importance, y compris les espaces de début ou de fin.

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

Ce mécanisme existe depuis assez longtemps, de sorte que la prise en charge du navigateur est probablement très bonne, assurez-vous simplement de vérifier.

En outre, si vous souhaitez vous assurer que les navigateurs non conformes plus anciens ne sont pas 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.

6
Fabio Beltramini

Il y a un point important sur ce que ce type de signature peut et ne peut pas faire. Il peut protège l'utilisateur contre les attaques hypothétiques dans lesquelles quelqu'un modifie votre code. Cela ne peut pas assurer à 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.

3
ddyer

Si votre modèle adversaire autorise un attaquant à modifier les fichiers JavaScript lorsqu’ils sont livrés à partir d’un CDN, il permet à l’attaquant de modifier le source référant lorsqu’il est remis afin d’éliminer toute tentative de vérification, de modifier l’adresse source autrement CDN, et/ou de supprimer entièrement la référence à JavaScript.

Et n'ouvrons pas la boîte de Pandore indiquant comment votre application peut déterminer si le résolveur de l'utilisateur se résout correctement ou non au CDN via des requêtes HTTP (ou tout autre mécanisme ne disposant pas d'une chaîne de confiance vérifiée).

/ etc/hosts:

#  ...
1.2.3.4    vile-pirates.org    trustworthy.cdn
#  ...
2
Eric Towers