Session 13 — Chaos Sécurité niveau Master (S10–S12) + Référence API + Décomposition Vibe Coding¶

Durée : ~4 heures (1 conversation Claude) Objectif initial : Ajouter le niveau 4 Master au Chaos Sécurité — compromission compte admin Objectif final : 4 failles Master implémentées (S10–S12 via portail admin caché + niveau 4 réarchitecturé), référence API exhaustive générée, bilan vibe coding décomposé par session

🎯 Réalisations¶

1. Chaos Sécurité — Niveau 4 Master (architecture portail admin caché)¶

Temps : ~2h Difficulté : ⭐⭐⭐⭐

Extension du système de sécurité avec 3 failles OWASP ciblant la compromission du compte administrateur, encapsulées dans un portail admin caché (/api/admin/portal/*) actif uniquement quand level == 4.

Failles implémentées¶

Code	Nom	OWASP	Endpoint	Mécanisme
S10	Admin Credentials Leak	A09	`GET /api/admin/portal/stats`	Aucune auth — expose `adminContact` (email superAdmin) + stats globales
S11	Login Admin SQLi	A03	`POST /api/admin/portal/login`	`EntityManager.createNativeQuery()` avec concaténation de chaîne — bypass `admin' OR '1'='1' --`
S12	IDOR + Privilege Escalation	A01 + A08	`PUT /api/admin/portal/accounts/{id}/promote` + `GET /api/admin/portal/accounts`	Promotion superAdmin sans vérification d'identité + liste comptes avec `passwordHash` exposé

Architecture niveau 4¶

SecurityChaosService.java : flags et compteurs S10/S11/S12
SecurityChaosController.java : endpoints public /api/chaos/public/security/status, /logs, /faults
AdminController.java : hooks S10–S12, méthode getTokenEmail() pour résoudre email → isSuperAdmin
AdminPortalController.java : nouveau — 4 endpoints portail caché, guard level < 4 → 404 corps vide
chaos-admin/public/index.html : carte niveau 4 Master + description failles S10–S12
monitoring/public/admin/monitoring.html : grille KPI étendue S1–S12, badges sévérité Master (noir)

Règle d'or respectée¶

Les failles S10–S12 sont actives uniquement en level == 4. Le portail caché n'interfère jamais avec le checkout ni les fonctions core e-commerce.

Bug de compilation corrigé¶

AdminPortalController.java appelait initialement a.getPassword() sur AdminUser — le champ s'appelle getPasswordHash() (convention Lombok + @Column(name = "password_hash")). Corrigé avant livraison.

Scénario étudiant Master (enchaînement des failles)¶

1. Fuzzing → découvre /admin (page React)
2. GET /api/admin/portal/stats [S10] → récupère email du superAdmin sans auth
3. POST /api/admin/portal/login [S11] → SQLi bypass → obtient adminToken valide
4. Accède chaos-admin + monitoring avec ce token (X-Admin-Token)
5. PUT /api/admin/portal/accounts/1/promote [S12] → s'auto-promeut superAdmin en DB
6. GET /api/admin/portal/accounts [S12] → liste tous les comptes + passwordHash exposé

2. Frontend React — Page AdminPortal¶

Temps : ~30 min Difficulté : ⭐⭐

frontend/src/pages/AdminPortal.jsx : nouveau — page React /admin non liée dans la navigation, découvrable uniquement par fuzzing
frontend/src/App.jsx : ajout de la route /admin → AdminPortal
Page affiche un formulaire de login et les stats portail une fois connecté

3. Documentation MkDocs — 4 fichiers¶

Temps : ~45 min

mkdocs/docs/chaos/security.md : section niveau Master ajoutée, tableau S10–S12, scénario exploitation chaîné, curl examples
mkdocs/docs/guides/student-guide.md : scénario étudiant Master détaillé (6 étapes)
mkdocs/docs/roadmap/roadmap.md : phase Chaos Sécurité N4 passée en ✅
mkdocs/docs/guides/hackathon.md / formation.md : mentions niveau Master ajoutées

4. Référence API exhaustive¶

Temps : ~45 min

Lecture de 15 controllers Spring Boot → génération de mkdocs/docs/architecture/api-reference.md avec l'inventaire complet des endpoints REST :

~70 endpoints documentés sur 8 sections (auth, produits, panier, checkout, commandes, pays, admin, chaos)
Symboles auth (🔓 public, 🔑 session, 🔐 admin, 👑 superAdmin, 🚨 vulnérable)
Section portail caché avec bloc !!! danger MkDocs + scénario exploitation
Tableau récapitulatif des 12 failles (S1–S12) par endpoint et niveau d'activation
Entrée ajoutée dans mkdocs.yml sous Architecture

5. Décomposition du bilan vibe coding¶

BILAN_SESSION_VIBE_CODING.md (~150 KB, 3282 lignes) → 12 fichiers session-01.md à session-12.md + session-index.md
mkdocs.yml mis à jour : section Vibe Coding remplacée par 14 entrées (index + sessions 01–13)
Sessions 9–12 complètes migrées (110–340 lignes chacune)
Sessions 1–3 complètes migrées avec contenu restructuré proprement

🐛 Obstacles & Difficultés¶

Comparaison architecture initiale vs finale (S10–S12)¶

La conception initiale prévoyait des failles dispersées dans les controllers existants (AdminController, UserController). L'architecture finale opte pour un portail caché isolé (AdminPortalController) — plus pédagogique (fuzzing requis pour le découvrir) et plus propre (aucun impact sur les controllers core).

Contrainte auth portail¶

Les endpoints portail n'acceptent que le token (X-Admin-Token) — pas le cookie de session. Ce choix garantit que l'étudiant doit exploiter la chaîne S11 → token → S12, et ne peut pas contourner en réutilisant une session existante.

Migration fichiers session¶

La décomposition du bilan (~150 KB) en 13 fichiers a nécessité une approche outillée (Python pour découper aux boundaries # Session N) puis des écritures Filesystem:write_file individuelles. La contrainte d'accès en lecture seule aux montages /mnt/ depuis bash Claude a imposé des allers-retours lecture bash → écriture Filesystem.

🤖 Erreurs imputables à Claude AI — Session 13¶

❌ Erreur S13-1 — `a.getPassword()` au lieu de `a.getPasswordHash()`¶

Ce que j'ai proposé : AdminPortalController.java avec appel a.getPassword() dans la méthode listAdminAccounts().

Ce qui s'est passé : Erreur de compilation — AdminUser n'a pas de méthode getPassword(). Le champ est @Column(name = "password_hash") → Lombok génère getPasswordHash().

Pourquoi c'était une erreur : J'aurais dû consulter le modèle AdminUser.java avant d'écrire le DTO de mapping. Convention Lombok + nom de champ différent du nom Java habituel (password vs passwordHash).

Temps perdu : ~5 min (détecté immédiatement) | Sévérité : ⭐⭐

❌ Erreur S13-2 — Conception initiale S10–S13 avec 4 failles dispersées¶

Ce que j'ai proposé : Une première conception avec S12 = Session Fixation et S13 = Mass Assignment isAdmin, réparties dans plusieurs controllers existants.

Ce qui s'est passé : Après discussion, la conception a été refondée : portail admin caché isolé, S10/S11/S12 réarchitecturés pour un scénario d'exploitation linéaire et pédagogique. La Session Fixation (proxy requis) et le Mass Assignment isAdmin ont été abandonnés au profit d'un IDOR privilege escalation plus direct.

Pourquoi c'était une erreur : Concevoir les failles sans scénariser d'abord l'exploitation end-to-end. L'architecture finale (portail caché → stats → SQLi → promote → liste comptes) est nettement plus pédagogique que 4 failles indépendantes dans des controllers dispersés.

Temps perdu : ~20 min (redesign en début de session) | Sévérité : ⭐⭐⭐

📊 Récapitulatif Session 13¶

#	Erreur	Temps perdu	Sévérité
S13-1	`getPassword()` au lieu de `getPasswordHash()`	~5 min	⭐⭐
S13-2	Conception initiale S10–S13 non scénarisée	~20 min	⭐⭐⭐
	TOTAL	~25 min

Pattern : Concevoir des failles de sécurité sans tracer le scénario d'exploitation end-to-end avant d'écrire du code. La leçon : pour le Chaos Sécurité, toujours commencer par le scénario étudiant (ce qu'il découvre, dans quel ordre, avec quel outil), puis concevoir les failles qui l'implémentent — pas l'inverse.

🎓 Conclusion Session 13¶

✅ Chaos Sécurité niveau 4 Master — portail admin caché /api/admin/portal/*, 3 failles S10/S11/S12 enchaînées, actives uniquement en N4 ✅ Bug compilation corrigé — getPasswordHash() au lieu de getPassword() ✅ Frontend — page AdminPortal.jsx découvrable uniquement par fuzzing, route /admin dans App.jsx ✅ Monitoring & chaos-admin — grille KPI et logs étendus à S1–S12, carte Master ✅ Documentation MkDocs — security.md, student-guide.md, hackathon.md, formation.md mis à jour ✅ Référence API exhaustive — architecture/api-reference.md (~70 endpoints) + entrée mkdocs.yml ✅ Bilan vibe coding décomposé — 12 fichiers session-01.md à session-12.md + index + présente session

Ratio temps productif / temps total : ~90% Total cumulé projet : ~78h de vibe coding sur 13 sessions Prochaine étape : Build Docker perfshop-backend:v33 + perfshop-frontend:v33, déploiement NAS