Lab académique — M2 FSI, module sécurité des applications. Cible : OWASP Juice Shop, une application e-commerce intentionnellement vulnérable. Objectif : exploiter systématiquement les vulnérabilités sur quatre niveaux de difficulté.
Environnement
Navigateur : Mozilla Firefox Proxy : OWASP ZAP 2.15.0 avec l’extension Foxy Proxy Cible : OWASP Juice Shop (instance locale)
ZAP s’intercale entre le navigateur et l’application, interceptant et permettant la modification de toutes les requêtes et réponses HTTP.
Niveau 1 — Bases
Exposition de la politique de confidentialité
L’application expose sa politique de confidentialité à une URL prévisible. Y accéder directement compte comme un challenge — pas d’authentification requise, pas de scan nécessaire. Divulgation d’information classique par absence de contrôle d’accès sur les pages statiques.
Divulgation d’informations via la gestion des erreurs
Déclencher une erreur non gérée révèle des stack traces et des chemins internes dans le corps de la réponse. L’application n’assainit pas la sortie d’erreur avant de l’envoyer au client — comportement mode développeur laissé actif en production.
Contournement du principe DRY — Inscription
Le formulaire d’inscription valide côté client que le mot de passe et le champ de confirmation correspondent. Intercepter la requête dans ZAP et modifier le champ de confirmation après la validation client contourne la vérification — le serveur accepte des mots de passe non concordants. Validation serveur absente.
DOM XSS — Champ de recherche
Le champ de recherche reflète la saisie dans le DOM sans assainissement :
Payload : <iframe src="javascript:alert('xss')">
Injecté dans le paramètre de recherche, l’<iframe> est rendu et s’exécute. L’application insère la valeur brute dans le DOM via innerHTML plutôt que d’utiliser des méthodes sûres comme textContent.
Injection SQL — Connexion admin
Le formulaire de connexion est vulnérable à l’injection SQL sur le champ email. Contournement de l’authentification avec un payload classique :
| |
Cela ferme la chaîne email, ajoute une tautologie et commente la vérification du mot de passe. L’application construit sa requête par concaténation de la saisie utilisateur — pas de requêtes paramétrées.
Contournement de la robustesse du mot de passe
Le formulaire d’inscription applique une robustesse minimale de mot de passe côté client. Intercepter la requête d’inscription dans ZAP et remplacer le mot de passe par une valeur faible (1) avant qu’elle n’atteigne le serveur contourne la vérification — validation serveur non implémentée.
Niveau 2 — Intermédiaire
Injection SQL — Énumération
Avec le contournement de connexion admin confirmé, l’étape suivante était d’énumérer les données utilisateurs. Le fuzzer de ZAP a été utilisé sur le champ email avec une wordlist de payloads SQL pour :
- Extraire l’adresse email de l’admin
- Énumérer les autres utilisateurs inscrits
- Cartographier la structure de la requête
L’application utilise un schéma de requête unique pour toute l’authentification — pas de requêtes préparées.
Manipulation de session — Accès au panier
Chaque utilisateur a un panier identifié par un ID dans un paramètre GET. Après authentification, intercepter la requête de panier dans ZAP et modifier l’ID vers celui d’un autre utilisateur (par ex. changer ?basketId=3 en ?basketId=2) retourne le panier de l’autre utilisateur sans vérification d’autorisation.
GET /rest/basket/2 → retourne le panier de l'utilisateur 2 connecté en tant qu'utilisateur 3
Pas de validation serveur que le panier demandé appartient à l’utilisateur authentifié. IDOR classique (Insecure Direct Object Reference).
Niveau 3 — Avancé
CSRF — Changement de nom d’utilisateur
L’endpoint de paramètres de compte est vulnérable au CSRF. Une requête forgée pointant vers un serveur externe (squarefree.com) a été utilisée pour changer le nom d’utilisateur du compte cible.
La requête :
- Cible l’endpoint de changement de nom d’utilisateur
- Est envoyée depuis une page que la victime visite
- Réussit car l’application ne valide pas l’en-tête
OriginouReferer, et ne requiert pas de jeton CSRF
Payback Time — Facture à quantité négative
Le flux de commande ne valide pas que les quantités sont des entiers positifs. Définir la quantité d’un article à une valeur négative produit un total de ligne négatif qui se propage à la facture :
Article : "Apple Juice" × -100 = -89,90 €
Total : -89,90 €
L’application génère et accepte une facture négative — une vulnérabilité de logique métier plutôt qu’une injection classique.
Niveau 4 — Expert
Contournement d’upload de fichier — Encodage null-byte
L’application restreint les uploads de fichiers à des extensions spécifiques (PDF attendu). Deux techniques null-byte ont été utilisées pour contourner la vérification d’extension :
.pdf.ndb— ajout de.ndbaprès une extension légitime.pdf.jpg— ajout de.jpgpour tromper le validateur MIME/extension
Le serveur vérifie la chaîne d’extension mais ne valide pas le contenu réel du fichier ni le type MIME de façon cohérente. Le null-byte amène certains validateurs à tronquer au null, ne lisant que le .pdf initial.
Énumération FTP
L’application expose un serveur FTP accessible sans authentification (ou avec des identifiants faibles). L’énumération de la racine FTP révèle :
- Listing du répertoire des fichiers serveur
- Fichiers de sauvegarde avec nommage prévisible :
coupons.013.mdb.bak - Artefacts de configuration non destinés à être publics
Accès aux fichiers de sauvegarde
Accéder à coupons.013.mdb.bak via l’exposition FTP récupère une sauvegarde de base de données. L’extension .bak n’est pas restreinte de l’accès public malgré son contenu applicatif.
Ce que j’en retiens
- L’injection SQL reste trivialement exploitable quand la saisie est concaténée dans les requêtes — les requêtes paramétrées sont non négociables
- La validation côté client est cosmétique — chaque vérification doit être dupliquée côté serveur
- L’IDOR nécessite des vérifications d’autorisation au niveau objet par requête, pas seulement l’authentification
- Les jetons CSRF et la validation de l’origine ne sont pas optionnels pour les requêtes modifiant l’état
- La sécurité des uploads de fichiers nécessite de valider le contenu du fichier (magic bytes), pas seulement la chaîne d’extension
- Les vulnérabilités de logique métier (quantités négatives, workflows contournés) n’apparaissent pas dans les scanners automatiques — elles nécessitent de comprendre le comportement prévu de l’application