La vulnérabilité à détecter pour ce challenge était un défaut de contrôle d’accès due à un traitement inapproprié de la sensibilité de la casse et la validation incorrecte de l’équivalence des chemins d’accès.
La résolution de challenge demandait la connaissance du cadriciel web Express de Node.js.

Note : Cet article est aussi disponible en anglais 🇬🇧. Le challenge a été annoncé dans ce tweet 🐦.

Explication

Par défaut, le routage du cadriciel Express n’est pas sensible à la casse. Regardons ce que dit la documentation :

app.set(name, value)

Application Settings

Property Type Description Default
case sensitive routing Boolean Enable case sensitivity. When enabled, "/Foo" and "/foo" are different routes. When disabled, "/Foo" and "/foo" are treated the same. NOTE: Sub-apps will inherit the value of this setting. N/A (undefined)

express.Router([options])

Property Description Default Availability
caseSensitive Enable case sensitivity. Disabled by default, treating “/Foo” and “/foo” as the same.

Reférence – 4.x API – Express documentation

Par conséquent, le routage vers /secret, /SECRET, /SeCrEt, etc. aura le même débouché. Au contraire, le logiciel médiateur responsable de l’authentification qui est censé protéger le point de terminaison /secret, lui, est sensible à la casse et ne vérifie le jeton que quand la route commence exactement par /secret. Il suffit donc de contacter /Secret, ou toute autre forme ayant une casse différente, pour contourner le contrôle d’accès, car Express routera tout de même correctement la requête alors que l’authentification ne sera pas effectuée.

Code corrigé

Voici donc le code corrigé :

Code corrigé

Ici, les paramètres globaux de l’application ont été modifiées afin que les routes soient sensibles à la casse.

Une autre solution aurait pu être de garder l’application insensible à la casse et de seulement faire une vérification non sensible à la casse pour vérifier la route /secret mais la même étourderie pourrait se reproduire ailleurs dans le code.

Diff

Le code source est disponible sur le dépôt Github Acceis/vulnerable-code-snippets.

À propos de l’auteur

Article écrit par Alexandre ZANNI alias noraj, Ingénieur en Test d’Intrusion chez ACCEIS.