cucumberanorsncompany/sealsecurityassignmentRecherche sur la vulnérabilité CVE-2023-26136
Recherche sur la vulnérabilité CVE-2023-26136
Les versions du paquet tough-cookie antérieures à 4.1.3 sont vulnérables à la pollution de prototype (Prototype Pollution) en raison d'une gestion incorrecte des cookies lors de l'utilisation de CookieJar en mode rejectPublicSuffixes=false. Ce problème vient de la manière dont les objets sont initialisés.
https://nvd.nist.gov/vuln/detail/CVE-2023-26136
JavaScript a le concept d'objets, qui sont en quelque sorte similaires à des dictionnaires. Un objet peut contenir un ensemble de variables de différents types (par exemple, chaîne, booléen, entier, etc.), le nom de la variable est une clé, et sa valeur est la valeur, si nous continuons l'analogie avec les dictionnaires et les objets. Plus précisément, l'objet est analogue à la structure de données dictionnaire elle-même, et chaque variable est analogue à une paire clé-valeur. Les objets ont également le mot-clé proto qui permet d'ajouter des variables supplémentaires à un objet en modifiant son prototype. La pollution de prototype est une attaque dans laquelle l'attaquant pollue son objet en lui ajoutant des variables supplémentaires via le mot-clé proto. L'interaction ci-dessous avec la console du navigateur illustre l'attaque.
Comme nous pouvons le voir, nous avons deux utilisateurs : admin1 et user1. L'objet admin1 a une variable booléenne : « isAdmin », qui est définie sur true. User1 n'a pas cette variable du tout. À la ligne 7, nous ajoutons la variable isAdmin au prototype de user1, et bien qu'il soit évident à la ligne 10 que la variable n'a pas été ajoutée à l'objet user1 lui-même, la console répond positivement cette fois lorsque nous vérifions la valeur de user1.isAdmin. C'est parce que user1 hérite des propriétés de son prototype.
Il convient également de mentionner que le prototype est un objet en soi, qui hérite à son tour de propriétés et de méthodes de son prototype, créant ainsi une chaîne de prototypes. La chaîne se termine par un prototype null, donc une approche raisonnable pour prévenir la pollution de prototype est de faire en sorte que l'objet avec lequel nous travaillons hérite explicitement d'un prototype null.
Les cookies (souvent appelés cookies internet) sont des fichiers texte contenant de petits éléments de données — comme un nom d'utilisateur et un mot de passe — qui sont utilisés pour identifier votre ordinateur lorsque vous utilisez un réseau. Des cookies spécifiques sont utilisés pour identifier des utilisateurs spécifiques et améliorer leur expérience de navigation sur le Web.
Courtoisie de Kaspersky : https://www.kaspersky.com/resource-center/definitions/cookies
CookieJar est un objet permettant de stocker des cookies.
Selon la description de la vulnérabilité, elle provient de la manière dont Tough-Cookie initialise les cookies. Comme les cookies sont des objets, ils sont théoriquement, au moins, vulnérables à la pollution de prototype.
En pouvant altérer les objets et particulièrement les cookies, via le prototype de l'objet, l'attaquant peut potentiellement accéder à des données non autorisées, exécuter du code à distance, provoquer un déni de service, détourner la session si le site web repose sur les cookies pour gérer la session, et extraire des données sensibles des cookies eux-mêmes.
Le correctif a été apporté au fichier : memstore.js. Selon le suivi du problème ainsi que le correctif introduit dans la version 4.1.3, pour corriger la vulnérabilité, nous devons stocker les cookies dans une carte (map) ou créer l'objet this.idx. En créant this.idx avec : this.idx = Object.create(null); au lieu de this.idx = {}, nous mettons en pratique ma suggestion sur la façon de prévenir la pollution de prototype dans l'introduction, en héritant d'un prototype null, et nous coupons la chaîne de prototypes.
Snyk a publié une preuve de concept (PoC) pour la vulnérabilité discutée. J'ai construit index.js à partir de celle-ci. Je l'ai enveloppée dans une logique try-catch pour capturer les exceptions si elles surviennent, ajouté des sorties supplémentaires pour suivre la progression des tests et j'ai obtenu la sortie requise (par exemple « EXPLOITED SUCCESSFULLY » ou « EXPLOITED FAILED »). Lors de l'exécution de la commande : npm install [email protected] && node index.js Nous obtenons la sortie suivante :
Lors de l'exécution de la commande : npm install ./tough-cookie-2.5.0-PATCHED.tgz && node index.js Nous obtenons la sortie suivante :
Dans les deux scénarios (exécution avec la version publiée 2.5.0 et exécution avec ma version corrigée), nous avons réussi à installer à la fois le cookie normal et le cookie exploité, mais avec la version corrigée, nous n'avons pas réussi à accéder au cookie exploité.
Dans ce devoir, j'ai appris l'attaque par pollution de prototype, j'ai appris l'objet JavaScript et j'ai été initié au paquet Tough-Cookie.
