Prévenir la pollution de prototype dans votre dépôt

Si vous êtes arrivé sur cette page directement depuis une Pull Request Aikido Autofix et que vous souhaitez simplement savoir comment finaliser la PR, passez à ‘Comment implémenter’.

L'écosystème JavaScript est confronté à un problème : la pollution de prototype. Pour une entreprise SaaS développant avec JavaScript/npm, typiquement 20 à 30 % de toutes les vulnérabilités connues (CVE) détectées dans les dépendances sont causées par la pollution de prototype. Celles-ci ne sont généralement pas faciles à exploiter, mais dans les cas les plus graves, elles peuvent entraîner des failles d'exécution de code à distance. Cela signifie qu'elles sont difficiles à ignorer complètement.

Deux façons de prévenir la pollution de prototype

Node.js offre un support expérimental pour geler le prototype par défaut via un flag appelé --frozen-intrinsics. L'activation de ce flag neutralise toutes les attaques par pollution de prototype. Cependant, nous ne pouvons pas encore le recommander car il est expérimental et ne fonctionnerait pas non plus sur les bases de code frontend. Cela vous empêcherait de mettre en place la même protection sur votre frontend et votre backend.

Une alternative est nopp (No Prototype Pollution), une bibliothèque de 14 lignes qui gèle le prototype (et d'autres points d'entrée).

Comment implémenter

1. Importation de la bibliothèque

Après avoir installé nopp, il vous suffit de vous rendre dans le script qui démarre votre application. Là, vous requirez simplement la bibliothèque, après avoir requis toutes vos autres bibliothèques. Exemple de commit ci-dessous :

2. Vérification de sécurité à l'échelle de l'application pour les bibliothèques dépendant de la manipulation de prototypes

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 après s'être assuré de geler le prototype APRÈS avoir inclus d'autres bibliothèques, il est toujours possible que vous ayez besoin de refactoriser avant que votre application ne fonctionne à nouveau !

À titre d'exemple, le propre 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 pourriez devoir effectuer un refactoring 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 pourrait représenter un investissement en temps plus important pour les dépôts volumineux ayant une faible couverture de tests. Pour les dépôts plus petits, cela en vaudra la peine pour ne plus jamais avoir à gérer la pollution de prototype. Pour les dépôts plus importants, cela pourrait être plus complexe, mais l'investissement en ingénierie aura probablement toujours un ROI positif à long terme.