Aller au contenu

Scénario Formation

Objectif

Parcours guidé pour former les apprenants aux concepts de performance et de chaos engineering de façon progressive.

Programme type (demi-journée)

Module 1 — Introduction (30 min)

  • Présentation de PerfShop et de son architecture
  • Tour du monitoring et de Grafana
  • Métriques nominales : comprendre ce qu'on mesure

Module 2 — CPU & Mémoire (45 min)

  • Activer CPU Burn à 25%, 50%, 75%, 100%
  • Observer la corrélation CPU → latence
  • Activer Memory Leak : observer la montée du heap et les cycles GC
  • Discussion : que faire en production ?

Module 3 — Concurrence & BDD (45 min)

  • Thread Pool : saturation progressive des threads Tomcat
  • DB Pool : épuisement HikariCP
  • Slow Query : impact sur les percentiles p95/p99
  • Deadlock : erreurs 503 et threads bloqués

Module 4 — Frontend (30 min)

  • CPU Burn navigateur : FPS et Long Tasks
  • Memory Leak JS : heap navigateur
  • Fetch Flood : corrélation réseau client/serveur

Module 5 — Chaos Métier (30 min)

Objectif : identifier des anomalies fonctionnelles silencieuses dans un parcours e-commerce.

Règle d'or : avec les bonnes données de test, une commande doit toujours aboutir quel que soit le niveau actif. Les anomalies sont à observer et noter, pas à corriger.

Niveau Junior — A1, A2, A3 (10 min)

  • Activer le niveau 1 dans l'onglet 💼 Chaos Métier du chaos-admin
  • Passer une commande et relever le montant TTC — le comparer avec montant_HT × 1,20
  • Vérifier le stock d'un produit commandé — il reste inchangé (A3)
  • Comparer le prix panier avec le prix catalogue — arrondi à l'entier inférieur (A2)

Niveau Confirmé — +A4, A5, A6, A7 (10 min)

  • Double-cliquer rapidement sur "Commander" — deux commandes apparaissent (A5)
  • Saisir un code promo invalide — accepté sans erreur ni réduction (A6)
  • Observer l'email de confirmation — les frais de port sont absents (A4)

Niveau Expert — +A8, A9, A10, A11 (10 min)

  • Observer le total affiché dans "Mes commandes" — ne correspond pas à la somme réelle (A10)
  • Après un logout, appeler l'API dans les 30 secondes — token encore valide (A11)
  • Vérifier les logs container : docker logs perfshop-app | grep '\[BusinessChaos\]'
  • Observer l'onglet 🎯 Métier du monitoring — compteurs et logs par anomalie en temps réel

Module 6 — Chaos Scripting (45 min)

Objectif : apprendre à scripter dans un environnement où les tokens sont obligatoires.

Niveau Junior (15 min) - Activer Level 1 dans l'onglet Scripting du Chaos Admin - Montrer en live qu'un appel sans token reçoit un 400 - Les apprenants modifient leur script JMeter/k6 pour extraire X-Session-Token du login et l'injecter - Validation : le scénario login → panier → commande passe en 200/201

Niveau Confirmé (15 min) - Activer Level 2 - Introduire X-Action-Token et l'expiration 30s - Les apprenants implémentent un re-login automatique dans leur script - Discussion : comment gérer l'expiration sous charge ?

Niveau Expert (15 min) - Activer Level 3 - Présenter la rotation CSRF/Step/Signature et la séquence step1 → step2 - Décoder en groupe les erreurs cryptiques : E-CSRF-01, E-STEP-04, E-SIG-07, E-TKN-99 - Les apprenants les plus avancés résolvent le niveau Expert en autonomie

Module 7 — Chaos Sécurité (45 min)

Objectif : identifier et exploiter des failles web OWASP dans un environnement contrôlé.

Rappel éthique

Ces techniques s'appliquent uniquement à cet environnement pédagogique isolé. Toute exploitation sur des systèmes tiers est illégale.

Niveau Junior — S1, S2, S3 (15 min)

  • Activer le niveau 1 dans l'onglet 🔒 Chaos Sécurité du chaos-admin
  • S2 IDOR : noter l'ID de sa commande, tenter d'accéder à une commande d'un autre utilisateur (/api/orders/1, /api/orders/2, ...) — observer si le 403 est bien absent
  • S3 Hash exposé : appeler GET /api/auth/me — observer le champ password avec son hash BCrypt $2a$...
  • S1 SQLi : tester GET /api/products/search?q=' puis ?q=' OR '1'='1 — comparer le nombre de produits retournés

Niveau Confirmé — +S4, S5, S6 (15 min)

  • Activer le niveau 2
  • S5 Prix falsifié : intercepter un POST /api/orders (Burp Suite / DevTools), modifier unitPrice à 0.01 — vérifier le totalAmount dans la réponse
  • S4 XSS stocké : soumettre une commande avec <script>alert('XSS')</script> dans shippingAddress — observer que la balise est stockée non échappée
  • S6 Timing attack : scripter plusieurs appels login avec emails connus vs inconnus, mesurer le δt (~300ms si compte existant)

Niveau Expert — +S7, S8, S9 (15 min)

  • Activer le niveau 3
  • S9 Mass Assignment : envoyer email et password dans le body de PUT /api/auth/me — vérifier si l'email a changé en consultant /api/auth/me
  • S7 Token HMAC : capturer le header X-Debug-Token, décoder la partie gauche en Base64url, re-signer avec la clé "secret123" pour forger un token admin
  • S8 Path Traversal : tester GET /api/orders/1/invoice?format=../../etc/passwd — observer le contenu simulé retourné
  • Observer l'onglet 🔐 Sécurité du monitoring — compteurs et logs par faille en temps réel

Niveau Master — Scénario chaîné S10, S11, S12 (15 min)

Scénario avancé — public Bac+4/5

Ce scénario requiert de chaîner 3 failles pour atteindre une élévation de privilèges complète.

  • Activer le niveau 4 dans l'onglet 🔒 Chaos Sécurité du chaos-admin
  • Découverte : inspecter le bundle JS dans les DevTools (Sources) ou fuzzer les routes — trouver /admin
  • S10 : GET /api/admin/portal/stats (sans token) — relever l'email adminContact exposé sans authentification
  • S11 : POST /api/admin/portal/login avec {"email": "admin' OR '1'='1' --", "password": "x"} — récupérer l'adminToken
  • S12 : PUT /api/admin/portal/accounts/1/promote avec header X-Admin-Token: <token> — observer isSuperAdmin: true dans la réponse
  • Utiliser le token obtenu pour accéder au chaos-admin et au monitoring — démontrer l'accès complet

Module 8 — Exercice autonome (30 min)

Les apprenants reçoivent un scénario à diagnostiquer (mode hackathon simplifié).

Points clés à retenir

  1. Chaque anomalie a une signature reconnaissable dans les métriques
  2. Les anomalies se combinent et créent des effets secondaires inattendus
  3. Le monitoring est essentiel — sans métriques, on ne peut pas diagnostiquer
  4. Les percentiles p95/p99 révèlent des problèmes invisibles en médiane
  5. Frontend ≠ Backend — les deux ont leurs propres axes de dégradation
  6. Les failles sécurité sont silencieuses — aucune erreur visible côté utilisateur, d'où l'importance des logs et du monitoring dédié