Si vous êtes arrivé sur cette page directement à partir d'une Pull Request d'Aikido Autofix et que vous voulez juste apprendre comment terminer la PR, passez directement à Comment implémenter.
L'écosystème JavaScript a un problème qui s'appelle la pollution par les prototypes. Pour une entreprise SaaS qui utilise JavaScript/npm, 20 à 30 % de toutes les vulnérabilités connues (CVE) détectées dans les dépendances sont causées par la pollution des prototypes. Elles ne sont généralement pas faciles à exploiter, mais dans les cas les plus graves, elles peuvent conduire à des failles d'exécution de code à distance. Il est donc difficile de les ignorer complètement.
Deux façons de prévenir la pollution des prototypes
Il existe un support expérimental dans Node.js pour geler le prototype par défaut sous un drapeau appelé --frozen-intrinsics. L'activation de ce drapeau met en échec toutes les attaques par pollution du prototype. Cependant, nous ne pouvons pas encore le recommander parce qu'il est expérimental et qu'il ne fonctionnera pas sur les bases de code frontales. Cela vous empêcherait de construire la même protection pour votre frontend et votre backend.
Une alternative est nopp (No Prototype Pollution), une bibliothèque de 14 lignes qui gèle le prototype (et certains autres points d'entrée).
Comment mettre en œuvre
1. Importer la bibliothèque
Après avoir installé nopp, tout ce que vous avez à faire est d'aller dans le script qui démarre votre application. Là, il vous suffit d'exiger la bibliothèque, après avoir exigé toutes vos autres bibliothèques. Exemple de livraison ci-dessous :
2. Vérification de la sécurité des bibliothèques à l'échelle de l'application en fonction de la manipulation du prototype
La raison pour laquelle nous gelons le prototype après avoir inclus d'autres bibliothèques est que certaines de vos autres bibliothèques peuvent dépendre de la modification du prototype pour fonctionner ! Même en s'assurant de geler le prototype APRES avoir inclus d'autres bibliothèques, il est toujours possible que vous ayez besoin d'un remaniement avant que votre application ne fonctionne à nouveau !
Par exemple, le kit aws-sdk d'Amazon pour Node.js modifie le prototype lors de la construction d'objets tels que "new AWS.S3(...)". Dans de tels cas, vous devrez peut-être procéder à un remaniement comme indiqué ci-dessous, en vous assurant que l'objet est créé lorsque votre processus Node.js est démarré et non lors d'une phase ultérieure.
S'assurer que votre application fonctionne toujours après ce changement peut représenter un investissement en temps plus important pour les grands dépôts qui ont une faible couverture de test. Pour les référentiels plus petits, cela vaut la peine de ne plus jamais avoir à s'occuper de la pollution des prototypes. Pour les référentiels plus importants, cela peut s'avérer plus complexe, mais l'investissement en ingénierie aura probablement un retour sur investissement positif à long terme.
.jpg)
.avif)
