Prototype pollution côté client dans des bibliothèques tierces

Client-side prototype pollution in third-party libraries

Contexte du laboratoire

Ce laboratoire est vulnérable à une DOM XSS via une prototype pollution côté client. La particularité ici est que le gadget vulnérable se trouve dans une bibliothèque JavaScript tierce, dont le code est minifié, ce qui rend l’analyse manuelle plus complexe.

Le laboratoire s’inspire de vulnérabilités réelles mises en évidence par PortSwigger Research, notamment dans l’article Widespread prototype pollution gadgets de Gareth Heyes.

Objectif final : Exécuter alert(document.cookie) dans le navigateur de la victime, en utilisant le serveur d’exploit fourni.

Approche recommandée : attaque automatique avec DOM Invader

Activation de DOM Invader

  1. Ouvrir le navigateur intégré à Burp Suite.

  • Vérifier que l’extension DOM Invader est active.

Activer :

  • DOM Invader is ON

  • Attack type : Prototype Pollution

Identification de la source vulnérable

  • Dans l’onglet DOM Invader, une source de prototype pollution est automatiquement détectée.

  • DOM Invader indique que la pollution est possible via le fragment URL (#), et non via les paramètres classiques (?).

Recherche automatique de gadgets

  1. Lancer Scan for gadgets depuis DOM Invader.

Un gadget exploitable est identifié dans une bibliothèque tierce.

En cliquant sur Exploit, DOM Invader confirme l’exécution avec un alert(1).

Payload final (document.cookie)

Payload identifié par DOM Invader :

Ce payload déclenche bien l’alerte contenant les cookies

Livraison de l’exploit à la victime

À l’aide du serveur d’exploit, on envoie le code suivant :

Lorsque la victime charge la page, le JavaScript est exécuté dans son navigateur

Approche manuelle (analyse approfondie)

Tentatives de pollution classiques (échec)

Les payloads suivants ne fonctionnent pas :

Résultat

Pollution via le fragment URL (succès)

En revanche, la pollution fonctionne avec # :

Cela indique que la source vulnérable consomme le fragment de l’URL

Analyse de la bibliothèque tierce

  • Un fichier volumineux est chargé :

/resources/js/ga.js

Environ 3000 lignes, code minifié.

  • Ce fichier contient un callback nommé hitCallback, utilisé sans vérification stricte.

Identification manuelle du gadget

Technique de traçage avec Object.defineProperty

Pour repérer les propriétés lues sur Object.prototype, on injecte :

Mise en pause de l’exécution JavaScript

En interceptant la réponse HTML, on injecte :

Le navigateur s’arrête sur “paused on debugger statement”, ce qui permet d’analyser la pile d’appels.

Test de propriétés candidates

Exemple avec une propriété non exploitable

Aucune trace intéressante.

Découverte du gadget valide : hitCallback

Résultat :

  • console.trace() révèle une chaîne d’appels provenant de ga.js

  • La propriété est bien lue et exécutée comme fonction

Ce comportement confirme que hitCallback est invoqué comme callback JavaScript

Ce comportement confirme que hitCallback est invoqué comme callback JavaScript

  • Le gadget hitCallback permet une exécution JavaScript arbitraire, menant à une DOM XSS.

Mis à jour