Ce cas pratique restitue un audit mené sur OWASP Juice Shop, l’application volontairement vulnérable maintenue par l’OWASP à des fins pédagogiques, dans un cadre de laboratoire strictement autorisé. L’intérêt de l’exercice n’est pas la découverte — Juice Shop expose délibérément ses failles — mais la démarche : comment une reconnaissance méthodique fait émerger des hypothèses, et comment chaque hypothèse se transforme, ou non, en exploitation confirmée.
Méthodologie
L’audit suit une approche DAV (Détection et Analyse de Vulnérabilités) structurée en cinq phases : reconnaissance passive et active, formulation d’hypothèses, tests de validation, exploitation contrôlée, puis post-exploitation et évaluation d’impact. Le périmètre couvre l’ensemble des fonctionnalités accessibles avec et sans authentification, ainsi que les points d’entrée HTTP exposés.
Reconnaissance passive
Une première exploration de l’interface révèle une boutique en ligne classique — présentation de produits, avis publics, recherche, authentification, réinitialisation de mot de passe, retour client. Deux détails, en apparence anodins, orientent déjà l’analyse : une adresse admin@juice-sh.op affichée publiquement, et un formulaire de mot de passe oublié qui révèle la politique de longueur des mots de passe (5 à 40 caractères) ainsi que l’existence d’une question de sécurité.
De ces observations découlent plusieurs hypothèses de travail : failles XSS possibles au niveau des avis ou de la recherche, exposition d’informations via l’adresse admin, brute-force ciblé envisageable sur ce compte, risque d’injection SQL dans les formulaires, et fragilités potentielles dans la gestion des ressources statiques. Toute la suite de la navigation est instrumentée via un proxy d’interception (Burp).
Authentification et logique de connexion
Absence d’énumération par message d’erreur
Des tentatives de connexion avec des identifiants invalides, puis avec un email valide mais un mot de passe incorrect, ne produisent aucun message distinctif permettant de différencier les deux cas. Cette piste d’énumération d’utilisateurs par les messages d’erreur est donc invalidée — un résultat négatif, mais qui referme proprement une hypothèse plutôt que de la laisser en suspens.
Compromission du compte administrateur
Un brute-force manuel, combinant l’adresse admin@juice-sh.op avec les contraintes de longueur déjà identifiées, aboutit à une connexion réussie.
L’interception de la requête de connexion révèle un POST /rest/user/login avec un corps JSON — l’authentification repose donc sur un point d’entrée JSON sérialisé, dont le potentiel d’attaque mérite d’être creusé plus avant.
Une anomalie qui confirme une hypothèse
Un test de rupture syntaxique, en soumettant test' comme email, produit une réponse anormale de type [object Object] plutôt qu’un message d’erreur propre. Ce comportement trahit une mauvaise gestion des entrées côté serveur, sans validation ni nettoyage préalable — et renforce nettement l’hypothèse d’une injection SQL.
Cartographier le reste de l’application
Une exploration plus poussée met au jour un processus de commande complet (adresses, moyens de paiement), un suivi de commande piloté par un identifiant dans l’URL, une impression de bon de commande via un point d’entrée nommé ftp, une page de profil avec upload d’image, et une section confidentialité. Chacun de ces éléments ouvre une hypothèse propre : exposition de fichiers via le répertoire ftp, manipulation possible des identifiants de commande, injections potentielles dans les formulaires, export de données mal maîtrisé.
Exposition du répertoire /ftp
Un accès direct à http://127.0.0.1:42000/ftp/ révèle un listing de fichiers accessible sans la moindre authentification.
Tenter d’accéder à un fichier .gg échoue, mais l’échec lui-même est instructif : le message d’erreur précise que seules les extensions .md et .pdf sont autorisées, révélant au passage la stack backend (Express, Node.js). Le filtrage par extension existe donc bien — reste à savoir s’il résiste à un contournement.
Export de données personnelles
La fonctionnalité d’export du compte administrateur restitue un objet JSON complet : email, historique de commandes, détails produits, avis, et jusqu’aux identifiants internes de produit (productId). Cette dernière donnée pose question : rien ne justifie qu’un export de compte utilisateur expose des identifiants internes, ouvrant la voie à une énumération ou à un abus de logique métier. C’est une fuite de données par excès de générosité de l’export, plus qu’une faille technique à proprement parler.
Reconnaissance technique
L’empreinte technologique de l’application — Angular 15.2.10, Zone.js, Node.js, TypeScript, jQuery 2.2.4, core-js — confirme une architecture SPA consommant une API REST JSON, avec une part de logique métier déportée côté client. La présence d’une version ancienne de jQuery, historiquement associée à des vulnérabilités XSS documentées, oriente la priorité des tests suivants vers le XSS et l’analyse fine des échanges JSON.
Exploitation
Injection SQL sur l’authentification
L’hypothèse forgée plus haut se confirme sans détour : soumettre {"email":"'or 1=1--","password":"test"} au point d’entrée de connexion contourne intégralement l’authentification. La cause est nette — une concaténation directe de l’entrée utilisateur dans une requête SQL, sans requête préparée — et la conséquence l’est tout autant : la logique d’authentification est rompue de fond en comble.
Contourner le filtrage d’extension
Le filtrage repéré plus haut cède à une technique de byte poisoning : ajouter un octet nul encodé (%2500) suivi de l’extension autorisée trompe le contrôle, qui ne valide que la fin apparente du nom de fichier.
http://127.0.0.1:42000/ftp/eastere.gg%2500.md
L’accès au fichier réussit, révélant un contenu encodé en base64 dont le décodage expose un nouveau point d’entrée jusqu’alors inconnu — l’exploitation d’une faille en révèle une autre, un enchaînement typique d’un audit mené jusqu’au bout.
Contrôle d’accès absent sur l’administration
Un accès direct à http://127.0.0.1:42000/#/administration — sans jamais avoir été authentifié via ce chemin — donne accès à l’interface d’administration. Le contrôle d’accès, quand il existe côté client, ne vaut rien sans vérification équivalente côté serveur.
XSS confirmé
Un payload <iframe src="javascript:alert(xss)">, injecté via le champ de recherche, s’exécute côté client — confirmant l’hypothèse XSS formulée dès la reconnaissance initiale. La démonstration d’impact va plus loin : une telle exécution ouvrirait la voie à l’exfiltration de cookies de session vers un serveur contrôlé par l’attaquant, compromettant potentiellement toute session active.
Post-exploitation : ce que révèlent les fichiers internes
L’accès à http://127.0.0.1:42000/ftp/acquisitions.md, rendu possible par l’exposition du répertoire, livre un document interne présenté comme confidentiel, portant sur des informations stratégiques d’acquisition. La criticité est sévère : au-delà de la seule fuite technique, ce type de document engage un risque financier et boursier réel, et illustre bien pourquoi une simple exposition de répertoire, en apparence mineure, peut in fine livrer l’information la plus sensible de toute l’application.
Synthèse
L’application cumule des vulnérabilités critiques qui, prises ensemble, permettent une compromission totale : injection SQL, XSS, exposition de fichiers, contournement de contrôles, failles de logique métier, et contrôle d’accès insuffisant sur les routes sensibles. Aucune de ces failles n’est isolée — c’est leur combinaison, comme souvent dans un audit réel, qui transforme une série de faiblesses individuelles en compromission d’ensemble.
Les recommandations qui en découlent restent d’une remarquable généralité, ce qui n’enlève rien à leur pertinence : requêtes préparées systématiques, validation et assainissement stricts des entrées utilisateur, contrôle d’accès vérifié côté serveur sur chaque route sensible, suppression des listings de répertoires, séparation stricte des rôles, mise à jour des dépendances JavaScript, et revue complète de la logique métier plutôt qu’un simple correctif ponctuel par faille identifiée.