OWASP Top 10 — Atelier pratique

Vous prenez Juice Shop ou DVWA. Vous tombez trois vulnérabilités de trois catégories différentes du Top 10. Pour chacune : requête, réponse, preuve d'impact. Bonus : une chaîne qui enchaîne au moins deux d'entre elles.

Compter : 3 h.

Livrable : ~/labs/semaine-07/rapport/owasp.md avec trois fiches complètes + preuves/ avec tous les artefacts.

Cadre

Ces attaques s'exécutent exclusivement contre Juice Shop, DVWA, WebGoat ou une cible sous RoE explicite. Ce n'est pas négociable.

---

Prérequis

Installez au moins une des deux applications :

# Juice Shop (recommandé si vous voulez du Node/Angular moderne)
docker run -d --name juice -p 3000:3000 bkimminich/juice-shop

# DVWA (recommandé si vous voulez du PHP legacy)
docker run -d --name dvwa -p 8080:80 vulnerables/web-dvwa

Sur DVWA, réglez la difficulté sur Low puis Medium pour progresser.

Firefox + Burp Suite Community configuré (voir démonstration).

Créez :

mkdir -p ~/labs/semaine-07/{preuves,rapport}

---

Étape 1 — Choisir 3 catégories (10 min)

Vous devez couvrir 3 catégories différentes parmi ces 6 (les plus formatrices) :

1. A01 — Contrôles d'accès (IDOR ou vertical)
2. A03 — Injection SQL (avec ou sans sqlmap)
3. A03 — XSS stockée (avec preuve d'impact, pas juste alert(1))
4. A05 — Mauvaise configuration (dir listing, panneau exposé, headers)
5. A07 — Authentification (brute-force login, cookies faibles, JWT)
6. A10 — SSRF ou LFI (Local File Inclusion, souvent classée A03)

Notez votre choix en tête de rapport/owasp.md avec une phrase de justification par choix.

---

Étape 2 — Attaquer, catégorie 1 (60 min)

Pour chaque catégorie, produisez la fiche suivante :

## Vulnérabilité — <catégorie et titre>

### Contexte
- URL vulnérable : ...
- Rôle nécessaire : anonyme / utilisateur / admin
- Difficulté DVWA : low / medium / high (si applicable)

### POC (preuve technique)
- Requête envoyée (exportée depuis Burp) :
  ```http
  ...
  ```
- Réponse reçue (extrait révélateur) :
  ```
  ...
  ```

### Preuve d'impact
- Payload utilisé pour l'impact : ...
- Résultat concret : ...
- Extraits ou captures dans preuves/<catégorie>-*

### Recommandation
- Correction immédiate : ...
- Correction de fond : ...

Chaque section est obligatoire. Sans preuve d'impact, la fiche ne vaut rien.

---

Étape 3 — Catégorie 2 (60 min)

Idem. Une catégorie différente.

---

Étape 4 — Catégorie 3 (60 min)

Idem. Encore différente.

---

Étape 5 — La chaîne (30 min)

Une chaîne minimum, qui combine deux vulnérabilités que vous avez trouvées, produisant un impact supérieur à la somme des parties.

Exemples de chaînes :

• XSS stockée → vol de cookie admin → prise de contrôle admin.
• IDOR → énumération d'utilisateurs → password spraying → compromission de 10 comptes.
• LFI → lecture de /etc/passwd puis /proc/self/environ → récupération d'un secret d'application → JWT forgeable.
• SSRF → lecture des credentials AWS via metadata → prise cloud.
• Directory listing → .git exposé → clone → lecture du code source → repérage d'un mot de passe hardcodé.

Documentez la chaîne dans rapport/chaine.md :

# Chaîne d'attaque — <titre court>

## Étape 1 — <faille A>
[bref]

## Étape 2 — <faille B>
[bref]

## Étape 3 — <exploitation combinée>
[bref]

## Impact combiné
[une phrase forte]

## Pourquoi c'est plus grave que la somme des parties
[une phrase]

C'est la partie la plus valorisée en entretien technique : montrer qu'on sait enchaîner.

---

Étape 6 — Tableau de synthèse (15 min)

Ajoutez au rapport un tableau récapitulatif :

| Catégorie | Titre | Sévérité | Preuve | Chaînable |
| --- | --- | --- | --- | --- |
| A01 | IDOR sur /api/basket | Haute | preuves/A01.md | Oui, avec A03 |
| A03 | SQLi dans /search | Critique | preuves/A03.md | Oui |
| A07 | JWT alg=none | Critique | preuves/A07.md | Oui, avec A01 |

---

Grille d'auto-évaluation

• Trois catégories différentes couvertes.
• Chaque fiche : contexte + POC + preuve d'impact + recommandation.
• Toutes les requêtes / réponses exportées depuis Burp dans preuves/.
• Aucune fiche ne se limite à un alert(1) ou à un id=1'--.
• Une chaîne documentée dans chaine.md avec au moins deux failles.
• Tableau de synthèse complet.
• Aucune extraction massive de données (respect du RoE d'atelier).
• Toutes les attaques sur des cibles autorisées.

---

Extension optionnelle — Écrire un template Nuclei

Prenez la vulnérabilité la plus simple que vous avez trouvée. Écrivez un template Nuclei YAML qui la détecte :

id: juice-shop-idor-basket
info:
  name: Juice Shop - IDOR on /rest/basket
  author: <vous>
  severity: high

requests:
  - method: GET
    path:
      - '{{BaseURL}}/rest/basket/1'
    headers:
      Authorization: "Bearer {{token}}"
    matchers:
      - type: word
        words:
          - '"UserId":1'

Testez :

nuclei -u http://10.10.10.50:3000 -t votre-template.yaml

Un template Nuclei fonctionnel, c'est l'équivalent d'un billet de blog — c'est ce qu'on met dans un portfolio.

---

Ce qui bloque en général

Symptôme	Cause	Correction
Burp ne voit pas le HTTPS	Cert non installé	Rechargez http://burpsuite et importez le CA.
sqlmap dit not injectable	Point d'insertion mauvais	Précisez -p <param> et ajustez le niveau --level=3 --risk=2.
XSS payload filtré	Difficulté trop haute	Baisez à low pour comprendre, remontez ensuite.
JWT crackage ne trouve rien	Clé forte	Normal. Documentez comme échec pédagogique, ce n'est pas un problème.
SSRF ne renvoie rien	Serveur d'app filtre les IPs privées	Testez 127.0.0.1 puis localhost puis [::1] puis 2130706433 (encodage décimal).

---

Ce que vous emportez de cet atelier

• Trois vulnérabilités effectivement exploitées, avec preuves.
• Une chaîne qui montre votre mode de pensée.
• Un rapport structuré comme celui d'un pentest client.
• La capacité de reproduire ces attaques en entretien technique.

Prochaine étape : le quiz du module. Après quoi on entre dans le module 8 — Metasploit — où l'on automatise et l'on chaîne à grande échelle.