Quel est le danger d'avoir un code JavaScript aléatoire, hors de mon contrôle, en cours d'exécution sur mes pages?
Les pages de mon site Web font référence à du code JavaScript provenant d'un CDN tiers (analytique, etc.). Donc je ne contrôle pas quel code est là - le tiers peut changer ces scripts à tout moment et introduire quelque chose mauvais dans ces scripts - peut-être accidentellement, peut-être délibérément. Une fois ces scripts modifiés, les utilisateurs commencent à recevoir et à exécuter un nouveau code dans leur navigateur.
Quels risques posent ce code incontrôlé? Quelle est la pire chose qui puisse arriver? Comment commencer à gérer le risque?
Risque
Dans le pire des cas, cela pourrait rendre le site Web complètement inaccessible pour les utilisateurs, il pourrait effectuer des actions particulières comme eux (par exemple, demander la suppression du compte, dépenser de l'argent) ou voler des données confidentielles.
La prévention
Impossible. Si vous exécutez le JavaScript de quelqu'un d'autre sur votre site Web, il ne devient pas plus sûr que ce tiers. Vous devez l'héberger vous-même.
Vous pouvez cependant vous rapprocher de la cible.
- Une chose peut être Politique de sécurité du conten . L'exemple de paramètre d'en-tête
Content-Security-Policyàscript-src 'self' www.google-analytics.com;, empêcherait l'exécution de scripts provenant d'autres domaines que le vôtre ouwww.google-analytics.com. De cette façon, si quelqu'un découvrait une vulnérabilité de script intersite (XSS) qui lui permettrait d'ajouter son propre code JavaScript en ligne à votre site Web - il ne s'exécuterait pas. - Une autre chose vraiment cool est ce qu'on appelle Intégrité des sous-ressources . Il s'agit essentiellement d'ajouter la somme de hachage de JS que vous prévoyez d'exécuter au paramètre
integrityque vous donnez à la balisescript.
<script src="https://example.com/example-framework.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"/>
Vous pouvez générer ces hachages en ligne sur https://www.srihash.org/ ou avec la commande:
openssl dgst -sha384 -binary FILENAME.js | openssl base64 -A
Bien sûr, cela a des inconvénients, par exemple les fournisseurs d'analyse peuvent modifier leurs scripts et vous devrez modifier le paramètre integrity pour les faire fonctionner. C'est également une nouvelle fonctionnalité (Chrome 45.0+, Firefox 43+, Opera 32+, pas de prise en charge IE, Edge ou Safari pour le moment), de sorte que vous définissez la sécurité de votre client sur son propre logiciel.
Voir aussi Aide-mémoire de gestion Javascript tiers de OWASP.
Quelle est la pire chose qui puisse arriver?
Le tiers peut faire tout ce que vous pourriez faire avec JavaScript - ou tout ce qu'un attaquant pourrait faire avec XSS.
Cela comprend le vol de cookies, l'injection d'un enregistreur de frappe JavaScript, le contournement de la protection CSRF et ainsi l'exécution de toute demande que vous pourriez exécuter - par exemple, l'ajout d'un nouvel utilisateur administrateur -, ou la modification du contenu de votre page Web (par exemple pour injecter des publicités ou pour des attaques de phishing).
Comment commencer à gérer le risque?
Si vous ne faites pas confiance aux intentions ou à la sécurité du tiers, la seule solution appropriée serait d'héberger le script vous-même (après vous être assuré qu'il ne fait que ce que vous voulez qu'il fasse).
Si vous ne le souhaitez pas, vous pouvez ajouter l'intégrité des sous-ressources pour atténuer quelque peu le risque:
Vous ajoutez un hachage du script à l'inclusion et navigateurs modernes comparera le hachage au hachage du fichier inclus. S'il ne correspond pas, le code ne sera pas exécuté: <script src="https://example.com/script.js" integrity="[hash]" crossorigin="anonymous"></script>. De cette façon, vous pouvez vous assurer que le script ne changera pas. Bien sûr, si cela change, vous devez revérifier le script et changer le hachage, sinon votre site Web sera cassé.
Quels risques posent ce code incontrôlé? Quelle est la pire chose qui puisse arriver?
Généralement, l'attaquant a accès à tout ce que vos méthodes d'authentification sont censées protéger.
Dans le pire des cas, supposez que le code est conçu sur mesure pour votre site. Les actions que l'utilisateur entreprend peuvent être invitées à entrer des informations d'identification de sécurité, donnant à l'attaquant l'accès au compte de cet utilisateur longtemps après sa déconnexion. Pour un compte bancaire, un portefeuille Bitcoin ou d'autres sites contrôlant l'accès aux actifs, l'attaquant aura accès à des actions irréversibles de grande valeur. S'il n'y a pas de valeur à l'époque mais qu'ils obtiennent les informations d'identification pour accéder au compte, ils peuvent attendre qu'il y ait suffisamment de valeur dans le compte pour que cela en vaille la peine.
Comment commencer à gérer le risque?
Bon: définissez la politique de sécurité du contenu et l'intégrité des sous-ressources sur les scripts que vous hébergez vous-même. Voir la réponse de @ Przemek pour plus d'informations à ce sujet. Je ne sais pas si cela doit être dit, mais tout JavaScript doit être servi via HTTP; cela augmente au moins le coût du MITM pour ces ressources.
Mieux: hébergez le code vous-même. Mais n'oubliez pas de le mettre à jour régulièrement. Ces fournisseurs publient leurs propres correctifs de sécurité. Ne vous laissez pas distancer.
Meilleur: Consultez tout le code source. La plupart du temps, vous pouvez trouver des versions non minifiées du JS que vous pouvez lire vous-même (et éventuellement simplement des différences), puis le réduire et le regrouper avec le reste de vos sites JS. Évidemment, c'est un coût élevé, pesez-le convenablement par rapport aux besoins de votre site.
Tout ce qui précède mérite d'être pris en considération, mais pour être juste, il existe des pratiques de développement bien acceptées ainsi que des protections intégrées dans les navigateurs modernes qui protègent contre les cas les plus graves signalés.
Il convient également de noter qu'il existe trois façons dont le code tiers peut s'exécuter dans le contexte (c'est-à-dire partager le même DOM de navigateur) que vos pages Web: 1) JS que vous incluez et restituez avec votre page, par exemple Google Analytics, ou 2) des Bookmarklets que l'utilisateur contrôle (par exemple Spritzlet ou Pinterest), et 3) des extensions de navigateur ou des barres d'outils. Les deux derniers sont presque complètement hors de votre contrôle; le premier est quelque chose que vous pouvez vérifier dans une certaine mesure.
De loin, la chose la plus importante à garantir est que le Web serveurs que vous contrôlez qui sert et répond au client (navigateur, bot, malware) est verrouillé. XSS, CSRF, SQL Injection et plusieurs autres vecteurs d'attaque sont sous votre contrôle côté serveur. Vous devez autoriser explicitement CORS du côté serveur, mais si vous le faites, assurez-vous de savoir ce que vous faites et soyez particulièrement vigilant. Cela ne veut pas dire que tout cela est facile ou évident ou quoi que ce soit, mais c'est entièrement indépendant de la vulnérabilité de la vulnérabilité via JS ou toute autre méthode.
En supposant que vous avez protégé votre serveur Web et verrouillé les points de terminaison qui peuvent être appelés, le reste de ce qui ne va pas appartient à une classe différente. JS (et les plugins/extensions/barres d'outils/bookmarklets) peuvent faire un large éventail de mauvaises choses - enregistreurs de frappe, injection d'éléments inoffensifs qui envoient réellement des données ailleurs, et ainsi de suite. Tous ces éléments sont exécutés par le navigateur.
Si vous servez le JS pour le compte d'un tiers, vous devez faire attention et faire confiance à la source. Un extrait de Google Analytics est probablement sûr. Un widget de diffusion d'annonces tiers pourrait valoir la peine d'être étudié plus attentivement. Dans tous les cas, le code derrière ceux-ci peut être inspecté: si le navigateur peut l'exécuter, vous pouvez voir le code JS et décider: est-ce quelque chose que vous voulez sur votre site?
JavaScript est un outil puissant. Mais au final, JS est un logiciel que le navigateur exécute et nous faisons donc beaucoup confiance aux navigateurs et aux systèmes d'exploitation qui les exécutent pour garantir la sécurité. JS n'est pas un logiciel qui a des capacités magiques particulières pour violer votre serveur ou faire faire à votre serveur des choses pour lesquelles il n'est pas conçu.
Votre site ne peut rien faire qui permette à JS d'exécuter arbitrairement du code sur l'ordinateur de l'utilisateur - c'est l'utilisateur qui doit avoir des mises à jour récentes des navigateurs et du système d'exploitation, etc. Vous pouvez détecter les anciennes versions et publier des avertissements pour être un Nice mec, mais c'est à peu près tout.
Sécurisez votre serveur, installez les mises à jour, assurez-vous que votre code est sûr, évitez de servir JS de tiers inconnus. Et puis, assurez-vous que votre site est enregistré avec les outils Google pour les webmasters qui vous informeront si votre site est piraté dans de nombreux cas, et si vous pouvez vous le permettre, obtenez un service qui analyse votre site pour détecter les vulnérabilités.
Quelle est la pire chose qui puisse arriver?
Le terme technique est exécution de code arbitraire. Dans ce contexte, "arbitraire" signifie "tout", comme dans "tout ce qu'il est possible de coder en JavaScript pourrait finir par s'exécuter sur votre site".
Est-il possible d'utiliser JavaScript pour lire les valeurs des champs de formulaire? Oui. Est-il possible d'utiliser JavaScript pour charger quelque chose à partir d'une URL? Oui. Ensuite, l'exécution de code arbitraire signifie que quelqu'un pourrait lire le nom d'utilisateur et le mot de passe d'un utilisateur lors de sa connexion et les transmettre à son propre serveur, codés en tant que paramètres dans une demande GET. (Cela fournit une fin de course soignée autour du cryptage HTTPS des données de connexion de vos utilisateurs, BTW.)
Est-il possible d'utiliser JavaScript pour lire des données sur une page? Oui. Ensuite, l'exécution de code arbitraire signifie que quelqu'un pourrait lire les données de profil privé d'un utilisateur lorsqu'il accède à la page qui les contient. (Et utilisez une requête HTTP pour la signaler au serveur de l'attaquant.)
...etc. Une vulnérabilité d'exécution de code arbitraire est considérée comme la pire chose possible du point de vue de la cybersécurité, car l'exploiter signifie que littéralement toute mauvaise chose possible peut être effectuée sur votre système.