Scénario Hackathon¶
Objectif¶
Les apprenants reçoivent un accès au dashboard monitoring (sans panneau de contrôle chaos) et doivent diagnostiquer les anomalies actives en analysant les métriques.
Déroulé type (2h)¶
Phase 1 — Baseline (15 min)¶
Le formateur laisse l'application tourner sans anomalie. Les apprenants observent les métriques nominales et les notent.
Phase 2 — Anomalie simple (30 min)¶
Le formateur active une seule anomalie à 50%. Les apprenants doivent : - Identifier quelle métrique change - Nommer l'anomalie - Expliquer la chaîne de causalité
Phase 3 — Anomalies combinées (45 min)¶
Le formateur active deux anomalies simultanément. Les équipes doivent démêler les signatures croisées.
Phase 4 — Restitution (30 min)¶
Chaque équipe présente son diagnostic et sa stratégie corrective.
Règles du jeu¶
- Accès autorisé : dashboard monitoring, Grafana dashboards élèves, API publique
- Accès interdit : panneau de contrôle chaos, logs Docker, code source
- Outils autorisés : navigateur, notes papier, communication d'équipe, curl/Postman
Mode Sécurité
Si le formateur active le Chaos Sécurité, les équipes peuvent également utiliser Burp Suite ou un proxy HTTP pour intercepter et modifier les requêtes.
Difficulté par anomalie¶
🔧 Chaos Backend¶
| Anomalie | Difficulté | Pourquoi |
|---|---|---|
| CPU Backend | ⭐ | Signal clair, métrique directe |
| Network Delay | ⭐⭐ | Impact uniforme sur toutes les latences |
| Thread Pool | ⭐⭐ | Nécessite de regarder les threads Tomcat |
| Memory Leak | ⭐⭐⭐ | Montée lente, nécessite observation dans le temps |
| DB Pool | ⭐⭐⭐ | Corrélation HikariCP + latence |
| Slow Query | ⭐⭐⭐ | Distinguer de DB Pool et Network |
| Deadlock | ⭐⭐⭐⭐ | Threads bloqués + 503, difficile à isoler |
🖥️ Chaos Frontend¶
| Anomalie | Difficulté | Pourquoi |
|---|---|---|
| CPU Burn | ⭐⭐ | FPS visible, Long Tasks dans le monitoring |
| DOM Flood | ⭐⭐ | Oscillations dom_node_count caractéristiques |
| Fetch Flood | ⭐⭐ | Débit réseau et fetch_req_per_sec montent clairement |
| Memory Leak | ⭐⭐⭐ | Heap JS monte lentement, nécessite durée d'observation |
💼 Chaos Métier¶
| Anomalie | Difficulté | Pourquoi |
|---|---|---|
| A2 Arrondi prix | ⭐ | Visible directement en comparant panier et catalogue |
| A3 Stock non décrémenté | ⭐⭐ | Nécessite de vérifier le stock avant et après commande |
| A1 TVA incorrecte | ⭐⭐⭐ | Écart de 0,33% — nécessite de calculer manuellement |
| A5 Double commande | ⭐⭐ | Visible dans la liste des commandes, reproduire par double-clic |
| A6 Promo invalide | ⭐⭐ | Tester avec un code aléatoire et observer la réponse |
| A10 Historique faux | ⭐⭐⭐ | Nécessite plusieurs commandes et un calcul de vérification |
| A11 Token logout | ⭐⭐⭐⭐ | Nécessite d'appeler l'API dans les 30s post-logout |
🔒 Chaos Sécurité¶
| Faille | Difficulté | Pourquoi |
|---|---|---|
| S2 IDOR | ⭐ | Changer l'ID dans l'URL — signal immédiat si 200 au lieu de 403 |
| S3 Hash exposé | ⭐ | Observer la réponse de /api/auth/me — présence du champ password |
| S1 SQL Injection | ⭐⭐ | Tester ' ou ' OR '1'='1 dans le champ recherche |
| S4 XSS stocké | ⭐⭐ | Soumettre <script>alert(1)</script> dans l'adresse de livraison |
| S5 Prix falsifié | ⭐⭐ | Intercepter la requête d'achat (Burp) et modifier unitPrice |
| S6 Timing Attack | ⭐⭐⭐ | Mesurer les δt login — email existant vs inexistant (~300ms d'écart) |
| S9 Mass Assignment | ⭐⭐⭐ | Envoyer email ou password dans le body de PUT /api/auth/me |
| S7 Token HMAC faible | ⭐⭐⭐⭐ | Décoder X-Debug-Token, re-signer avec clé connue, forger un token admin |
| S8 Path Traversal | ⭐⭐⭐⭐ | Injecter ../ dans le paramètre format de l'endpoint /invoice |
| S10 Stats portail | ⭐⭐ | Fuzzer /api/admin/portal/stats — email superadmin exposé sans auth |
| S11 SQLi portail | ⭐⭐⭐ | Payload admin' OR '1'='1' -- sur POST /api/admin/portal/login |
| S12 Privesc IDOR | ⭐⭐⭐⭐ | Enchaîner S10 → S11 → S12 pour obtenir un compte superAdmin |