L'injection JavaScript se produit lorsqu'un pirate parvient à insérer et à exécuter du code JavaScript non autorisé dans une application web. Cela peut entraîner le vol de données, le détournement de session ou d'autres actions malveillantes. La prévention nécessite une validation appropriée des entrées, un encodage des sorties, la mise en œuvre d'une politique de sécurité du contenu et une gestion prudente de l'évaluation du code dynamique.
L'injection JavaScript est l'insertion et l'exécution de JavaScript non autorisé au sein d'une application web. Elle atteint le navigateur par plusieurs voies : des failles de cross-site scripting qui renvoient une entrée non échappée dans une page, l'évaluation dynamique non sécurisée de chaînes via eval, le constructeur Function ou les callbacks de minuterie, des scripts third-party compromis ou malveillants chargés depuis un CDN, et des données contrôlées par l'attaquant écrites dans un contexte de script. Une fois le code exécuté, le navigateur le traite comme un script légitime appartenant à l'origine du site. Certaines définitions incluent aussi le self-XSS via la console du navigateur et les bookmarklets, où l'on incite un utilisateur à coller le code de l'attaquant. Dans tous les cas, la caractéristique déterminante est que du JavaScript que le développeur n'a jamais prévu finit par s'exécuter dans la page.
Le JavaScript injecté s'exécute avec toute l'autorité de l'origine de la page, sa portée est donc large. Il peut lire et exfiltrer les cookies, les jetons de session et le contenu du DOM, détourner des sessions, enregistrer les frappes clavier et les champs de formulaire, envoyer des requêtes en silence, réécrire l'interface et charger d'autres charges utiles. Sur les pages de paiement, c'est le mécanisme derrière les skimmers numériques et Magecart : quelques lignes ajoutées à un script de confiance copient discrètement les champs de carte et d'adresse vers le domaine d'un attaquant tandis que les journaux du serveur et les pare-feux ne voient rien, car le vol se produit entièrement dans le navigateur. Les attaquants obscurcissent couramment le code et le conditionnent à des pages ou conditions spécifiques pour échapper aux revues, laissant un seul script injecté s'exécuter sans être détecté auprès de nombreux utilisateurs pendant des mois.
Réduisez la surface en éliminant l'évaluation dynamique de code, en encodant la sortie, en validant les entrées et en imposant une Content Security Policy stricte avec des nonces ou du Subresource Integrity afin que seuls les scripts éprouvés s'exécutent. Mais une CSP fait confiance aux scripts d'après leur domaine source, si bien qu'un fournisseur autorisé mais compromis s'exécute quand même. C'est là que cside s'intègre directement : il achemine les scripts third-party via un méthode Script et analyse la charge utile JavaScript réelle avant son exécution, détectant les comportements malveillants, la lecture de champs de carte ou le contact d'un domaine inconnu, d'après ce que fait le code plutôt que d'après l'endroit d'où il est chargé. cside peut bloquer ce comportement en temps réel et conserve une trace forensique du code exact qui s'est exécuté, ce qu'exigent PCI DSS 6.4.3 et 11.6.1.
Le XSS est la manière la plus courante dont se produit l'injection JavaScript, en injectant du script via une entrée non échappée. Mais l'injection peut aussi survenir sans bug XSS classique : par un script third-party compromis, une évaluation non sécurisée de données dynamiques, ou un utilisateur piégé collant du code dans la console. Le XSS est une voie vers l'injection JavaScript, pas la seule.
Une CSP restreint les domaines et les scripts inline autorisés à s'exécuter, ce qui bloque de nombreuses injections, mais elle fait confiance à tout script servi depuis une source autorisée. Si un fournisseur que vous autorisez déjà est compromis, le code injecté s'exécute comme légitime. L'arrêter suppose d'inspecter ce que fait réellement chaque script, et pas seulement d'où il provient.
We answer client-side security questions every day. Bring yours.