Whiskers in the dark (Harder) : prototype pollution jusqu’au gadget utile

Cette note est une lecture théorique du challenge Whiskers in the dark (Harder), présent dans la catégorie Web de Hackropole. Elle ne donne ni flag ni recette officielle : elle construit le modèle mental nécessaire pour comprendre la famille de vulnérabilités visée.

L’idée en une image

En JavaScript, un objet peut hériter de propriétés qu’il ne possède pas. Polluer le prototype revient à glisser une valeur dans le tiroir commun que d’autres objets consulteront par défaut.

Dans un challenge web avancé, la vulnérabilité est rarement « une ligne ». Elle apparaît quand plusieurs composants n’ont pas la même définition d’une URL, d’un objet, d’une identité ou d’un contenu sûr.

Le modèle technique

Une écriture dynamique comme target[key1][key2]=value devient dangereuse avec proto, constructor ou prototype. La pollution seule n’est pas l’impact : il faut un gadget, c’est-à-dire un code qui lit une propriété héritée dans une décision sensible.

Le réflexe utile est de dessiner les frontières : navigateur, reverse proxy, serveur, worker, base de données, bot. Pour chaque frontière, noter ce qui est parsé, normalisé, validé et transmis.

Indices à chercher

• Merge récursif ou assignation depuis du JSON utilisateur
• Clés d’objet non filtrées
• Options passées à un moteur de template, un processus ou un client HTTP

Un indice ne devient une preuve qu’après une observation reproductible. Préférer une différence bénigne — code HTTP, longueur, timing, valeur affichée — à une charge complexe impossible à diagnostiquer.

Démarche d’analyse

1. Prouver la pollution avec une propriété inoffensive.
2. Chercher les lectures de propriétés absentes.
3. Tracer la valeur jusqu’à un effet observable.
4. Distinguer propriétés propres et héritées.

Travailler avec une matrice aide beaucoup : lignes pour les acteurs, colonnes pour les objets et cases pour les opérations. Les trous de sécurité deviennent visibles lorsque deux chemins censés être équivalents appliquent des règles différentes.

Là où le niveau hardcore commence

Les protections existent souvent, mais au mauvais endroit ou sur une représentation intermédiaire. Une validation de chaîne peut être annulée par le parseur suivant ; un contrôle sur la route racine peut être contourné par une relation ; une propriété nettoyée peut réapparaître via héritage.

La question centrale n’est donc pas « le filtre bloque-t-il mon payload ? », mais : quelle représentation le composant décisif utilise-t-il au moment de prendre sa décision ?

Fausses pistes classiques

• S’arrêter après avoir pollué Object.prototype.
• Tester uniquement proto alors que le parser le neutralise.
• Chercher une exécution de commande avant un gadget logique.

Construire une preuve minimale pour chaque hypothèse. Si trois mécanismes sont testés en même temps, un échec ne dit pas lequel est faux.

Ce que l’architecte sécurité doit en retenir

Utiliser des maps sans prototype, filtrer les clés dangereuses et vérifier les propriétés avec Object.hasOwn.

Les meilleures défenses réduisent le nombre d’interprétations possibles : types stricts, politiques centralisées, sorties encodées selon leur contexte, identités propagées explicitement et accès réseau contraints.

Exercice conseillé

Reproduire le mécanisme sur une application locale minuscule avec deux utilisateurs, deux origines et un seul objet sensible. Ajouter ensuite proxy, bot ou cache. Cette progression révèle exactement à quel moment l’invariant de sécurité se casse.