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

88

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?

javascript code-signing

— baba26
source

13

Bien que je trouve cette question intéressante, n'est-elle pas hors sujet?

— evolutionxbox

20

pourquoi serviriez-vous des fichiers sur http?

— njzk2

12

"Mais pourquoi un tel mécanisme n'existe-t-il pas?" Parce que c'est vraiment dur . Une fois que vos données ont quitté votre serveur, c'est du pain grillé. HTTPS aide mais s'il s'agit d'une simple connexion HTTP, toute validation peut échouer (ou plutôt réussir). Une attaque MITM peut simplement modifier votre signature attendue et / ou la signature de ce qui vous est fourni avant que le navigateur ne comprenne les attentes. Ainsi, lorsque l'utilisateur reçoit une charge utile, elle est considérée comme totalement sûre ... alors que ce n'est pas nécessairement cela.

— VLAZ

4

"Mais pourquoi un tel mécanisme n'existe-t-il pas?" Parce qu'il existe déjà une solution bon marché, efficace et largement applicable en HTTPS.

— Kevin Krumwiede

9

Cela devrait probablement être sur ServerFault ou Security, car il s'agit vraiment de servir des fichiers de manière sécurisée, et toute relation avec la programmation n'est tangentielle que dans la mesure où ces fichiers représentent du code source.

— underscore_d

140

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.

— Timo
source

9

Je pense qu'il vaut la peine de mentionner que la vérification d'intégrité peut facilement être falsifiée en supposant qu'OP envisage d'envoyer son HTML en HTTP ainsi que ses fichiers d'actifs. Si leur site est HTTPS et qu'ils souhaitent servir des actifs via HTTP, la plupart des navigateurs n'aimeront pas cela et ignoreront silencieusement les actifs HTTP.

— MonkeyZeus

3

@MonkeyZeus Ce ne serait vrai qu'en cas d'attaque MITM ou si notre propre serveur est compromis, n'est-ce pas? Je crois comprendre que la question demande explicitement comment se défendre contre un CDN compromis.

— Timo

10

@TimoSta Exactement! Sans ces vérifications, si vous incluez un script provenant, par exemple, de https://code.jquery.com/toute personne qui compromet code.jquery.compeut XSS votre site, indépendamment du fait qu'il soit code.jquery.comaccessible ou non via HTTPS. Avec ces vérifications en place, l'attaquant ne peut qu'empêcher le chargement des scripts, pas les remplacer par des scripts malveillants.

— Ajedi32

1

@MonkeyZeus J'ai ajouté une note à ma réponse, exprimant vos préoccupations. Êtes-vous d'accord avec le libellé?

— Timo

1

@TimoSta Très sympa, j'aime ça! btw, j'ai fait +1 avant même de

— publier

36

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>

— Brian
source

2

Totalement inutile car un attaquant peut modifier le champ d'intégrité en même temps qu'il modifie le script que vous téléchargez.

— Courses de légèreté en orbite

15

@LightnessRacesinOrbit: Pas si vous contrôlez votre propre domaine qui est accessible via HTTPS mais ne contrôlez pas code.jquery.com. Cela peut vous protéger d'un compromis code.jquery.com.

— SilverlightFox

2

@SilverlightFox: D'accord, totalement inutile contre les attaques MITM *

— Courses de légèreté en orbite

@LightnessRacesinOrbit Oui. Encore très utile et aurait empêché cette attaque par exemple: bleepingcomputer.com/news/security

— Adrian Mouat

6

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.

— Fabio Beltramini
source

existe depuis un certain temps, mais la prise en charge des navigateurs n'est pas très bonne. caniuse.com/subresource-integrity

— Sp0T

@ Sp0t - L'intégrité des sous-ressources (sur quoi porte votre lien) est le mécanisme des autres réponses. Ma réponse concerne la politique de sécurité du contenu, qui bénéficie d'un bien meilleur support

— Fabio Beltramini

3

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.

— ddyer
source

2

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
#  ...

— Eric Towers
source

2

La première phrase est manifestement fausse. Que faire si la page de référence est chargée via HTTPS et le fichier JavaScript est chargé via HTTP-not-S?

— user253751

Ou que faire si le CDN lui-même est compromis, mais pas votre propre serveur?

— Ajedi32

@immibis: Je choisis de supposer qu'OP n'est pas assez irrationnel pour proposer un tel scénario.

— Eric Towers

1

@immibis N'est-ce pas pourquoi les navigateurs n'autorisent généralement pas les pages HTTPS à charger JS sur HTTP?

— Barmar

1

@immibis Je disais que cela améliore une situation qui n'est même pas possible, car les navigateurs l'interdisent.

— Barmar

1

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 .

— 5377037
source