Applications, sites et API
Particuliers et entreprisesPollution de prototypes JavaScript
Prototype pollution
Une donnée modifie des propriétés héritées par d’autres objets de l’application.
Je pense être concerné : que faire ?
Comprendre et agir
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
Une situation concrète
Un outil JavaScript importe les préférences d’un utilisateur. Une fusion mal contrôlée modifie un objet dont d’autres objets héritent. Une option destinée à cet utilisateur influence alors d’autres traitements.
Comment cela fonctionne
En JavaScript, un objet peut hériter de propriétés définies dans un autre objet, son prototype. La pollution de prototypes permet de modifier ces propriétés à partir de données non fiables. Le défaut peut changer des options, perturber un contrôle ou préparer une autre attaque. Ses conséquences dépendent du code qui lira ensuite les valeurs modifiées ; une pollution n’entraîne pas automatiquement une exécution de commandes.
- Des données sont importées
Une fusion doit modifier des préférences locales.
- Un objet partagé est modifié
La propriété rejoint une chaîne de prototypes.
- Un autre traitement en hérite
Son comportement peut changer à la lecture.
Ce que vous pouvez faire
Vos premiers réflexes
Signalez des paramètres qui changent sans votre action, surtout après un import. La vérification du code et des bibliothèques revient à l’équipe du service.
Si vous êtes responsable du service ou de l’organisation
Faites examiner les fusions d’objets et les options utilisées pour les décisions sensibles. Vérifiez l’isolation entre utilisateurs et recréez les contextes contaminés après correction.
Un document JSON correctement formé peut contenir des données dangereuses pour une fusion ultérieure. Le simple fait de le lire n’implique toutefois pas qu’un prototype a été modifié.
À vous de décider
Le fichier de préférences est un JSON valide. Cela garantit-il que son import ne changera que vos préférences ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Non. Un JSON valide respecte une syntaxe, pas les règles de l’application. Son contenu doit être contrôlé avant la fusion. Une fusion défectueuse peut modifier des propriétés dont d’autres objets héritent.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
Une préférence héritée modifie un export indépendant
L’import de préférences modifie un prototype dans ce cas fictif. L’objet d’export ne possède toujours pas directement l’option include_internal, mais sa recherche retrouve désormais une valeur héritée. Le traitement suivant utilise cette valeur et renvoie une ligne interne factice. Le test relie la modification du prototype à la décision d’export qui renvoie cette ligne.
Une propriété apparue dans le prototype ne suffirait pas à prouver cette fuite. Il faut retrouver les lectures concernées et vérifier l’autorisation métier. Les champs du test rendent ici cette chaîne visible ; un serveur JavaScript ordinaire n’enregistre pas spontanément ces transitions. La portée peut dépasser une requête lorsqu’un même contexte traite plusieurs utilisateurs.
La correction limite les clés reçues, remplace la fusion dangereuse et rend explicite le contrôle d’autorisation de l’export. Le module Kibana Timelion CVE-2019-7609 documente un autre effet, l’exécution de code. Cette conséquence appartient au chemin présent dans Kibana ; le scénario étudié ici porte sur une option d’export.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Import de préférences
Utilisateur vers Fusion d’objets
Trace prefs-61
- Action
Écriture non maîtrisée
Fusion d’objets vers Prototype
Trace prototype_changed
- Action sur place
Nouvelle propriété héritée
Prototype
Trace include_internal
- Action
Demande d’export
Utilisateur vers Export
Trace export-62
- Action
Lecture d’une option absente de l’objet
Export vers Prototype
Trace recherche dans le prototype
- Réponse
Valeur héritée retournée
Prototype vers Export
Trace option_origin
- Réponse
Ligne interne factice livrée
Export vers Utilisateur
Trace effet confirmé en test
Comment repérer cette attaque
Indices à rechercher
- Une option apparaît sur un objet qui ne la possède pas directement.
- Des traitements indépendants changent de comportement après un import.
- Un contrôle lit une propriété héritée alors qu’il attend une donnée validée.
Rechercher les changements de comportement après les imports et identifier les propriétés héritées utilisées dans les décisions sensibles. Rapprocher chaque valeur de sa source et de la version de la bibliothèque de fusion, avec une reproduction dans un processus isolé.
Quelles informations comparer
Établir deux liens : l’entrée vers l’écriture du prototype, puis la propriété héritée vers la décision d’export. Identifier le contexte et sa durée de vie pour savoir quelles autres requêtes ont pu utiliser la même valeur.
Ce que ces indices ne permettent pas de conclure
Une propriété héritée peut être légitime et une pollution peut rester sans effet observable. Le scénario prouve une ligne factice retournée en test, sans établir une exécution de code ou l’exposition de données réelles.
Comment réagir
Corriger l’écriture et les lectures dangereuses, vérifier les autres usages du même prototype et traiter les actions déjà réalisées. Recréer le contexte contaminé après application du correctif ; redémarrer avant de fermer le chemin laisse la pollution se reproduire. Examiner aussi les valeurs enregistrées durablement par les traitements affectés.
Vérifier la correction
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- L’import ne modifie aucun prototype partagé, y compris avec des objets imbriqués.
- Les options et autorisations de l’export sont vérifiées explicitement ; une propriété héritée ne les accorde pas.
- Des requêtes successives de deux utilisateurs restent indépendantes dans le même contexte corrigé.
À vous de raisonner
Le prototype est modifié après l’import, mais aucun traitement ne lit la propriété concernée. Pouvez-vous conclure à une fuite ou à une exécution de code ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Non. La pollution est établie, mais son effet dépend des lectures ultérieures. Il faut identifier ces consommateurs et leurs décisions. Le défaut d’écriture doit être corrigé, puis la séparation entre utilisateurs vérifiée dans un même contexte d’exécution.
Consulter les détails techniques
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-les dans les extraits.
own_include_internal- Observation pédagogique de la présence d’une propriété propre, distincte de la valeur trouvée par héritage.
option_origin- Provenance reconstituée de la valeur utilisée par l’export ; un journal Node.js ordinaire ne la fournit pas automatiquement.
État d’une option avant et après un import isolé
JSONLObservations fictives d’un test d’application. Ce format n’est pas un journal natif Node.js ; les champs décrivent des objets et décisions factices, sans séquence d’exploitation.
{"case":"prefs-61","phase":"before_import","own_include_internal":false,"inherited_include_internal":false}
{"case":"prefs-61","phase":"after_import","prototype_changed":true,"own_include_internal":false,"inherited_include_internal":true}
{"case":"export-62","environment":"isolated_test","option_origin":"inherited","synthetic_internal_row_returned":true}
{"case":"export-63","build":"fixed","option_origin":"validated_own_property","synthetic_internal_row_returned":false}Préparer une collecte dans votre environnement
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les secrets.
Service concerné — audit et historique à vérifier
- Où les trouver
- Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
- Quoi relever
- Retrouver les imports, le composant de fusion et la décision métier affectée. En test isolé, comparer les propriétés propres et héritées avant et après, sans journaliser de valeurs privées complètes.
- Accès et prérequis
- Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
Fichiers préservés — comparaison et empreintes complètes
- Où les trouver
- Sur des copies de travail des fichiers conservés, dans l’environnement d’analyse autorisé. Calculer les empreintes complètes avec un outil fiable, puis comparer les octets si une égalité mérite vérification.
- Quoi relever
- Préserver la version du code et des dépendances qui réalisent la fusion et l’export. Comparer les copies utilisées en laboratoire à la version déployée ; une empreinte différente peut aussi provenir d’une mise à jour légitime.
- Accès et prérequis
- Accès aux originaux ou à des copies dont la provenance est documentée. Préciser l’algorithme, la longueur et toute transformation ; un recalcul actuel ne prouve pas quel fichier le service a traité auparavant.
Si vous pensez être concerné
Si vous utilisez le service
Signalez des paramètres qui changent sans votre action, surtout après un import. La vérification du code et des bibliothèques revient à l’équipe du service.
Pour l’équipe qui exploite le service
- Conservez l’entrée reçue et la version du composant de fusion dans un espace d’analyse.
- Corrigez le chemin qui modifie le prototype et recherchez les lectures des propriétés affectées.
- Après correction, recréez les processus ou contextes contaminés et vérifiez les opérations déjà réalisées.
Pour comprendre votre situation et trouver de l’aide : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- OWASP — Prévenir la pollution de prototypes — cheatsheetseries.owasp.org
- CWE-1321 — Modification non maîtrisée des prototypes — cwe.mitre.org
- Rapid7 — Kibana Timelion, CVE-2019-7609 — rapid7.com
