Hackathon Scenario¶
Objective¶
Learners are given access to the monitoring dashboard (without the chaos control panel) and must diagnose the active anomalies by analyzing the metrics.
Typical flow (2h)¶
Phase 1 — Baseline (15 min)¶
The instructor lets the application run without any anomaly. Learners observe the nominal metrics and write them down.
Phase 2 — Single anomaly (30 min)¶
The instructor enables a single anomaly at 50%. Learners must: - Identify which metric changes - Name the anomaly - Explain the causality chain
Phase 3 — Combined anomalies (45 min)¶
The instructor enables two anomalies simultaneously. The teams must untangle the crossed signatures.
Phase 4 — Debrief (30 min)¶
Each team presents its diagnosis and corrective strategy.
Rules of the game¶
- Allowed access: monitoring dashboard, student Grafana dashboards, public API
- Forbidden access: chaos control panel, Docker logs, source code
- Allowed tools: browser, paper notes, team communication, curl/Postman
Security mode
If the instructor enables Security Chaos, teams may also use Burp Suite or an HTTP proxy to intercept and modify requests.
Difficulty by anomaly¶
🔧 Backend Chaos¶
| Anomaly | Difficulty | Why |
|---|---|---|
| Backend CPU | ⭐ | Clear signal, direct metric |
| Network Delay | ⭐⭐ | Uniform impact on all latencies |
| Thread Pool | ⭐⭐ | Requires looking at Tomcat threads |
| Memory Leak | ⭐⭐⭐ | Slow rise, needs observation over time |
| DB Pool | ⭐⭐⭐ | HikariCP + latency correlation |
| Slow Query | ⭐⭐⭐ | Must be distinguished from DB Pool and Network |
| Deadlock | ⭐⭐⭐⭐ | Blocked threads + 503, hard to isolate |
🖥️ Frontend Chaos¶
| Anomaly | Difficulty | Why |
|---|---|---|
| CPU Burn | ⭐⭐ | Visible FPS, Long Tasks in the monitoring |
| DOM Flood | ⭐⭐ | Characteristic dom_node_count oscillations |
| Fetch Flood | ⭐⭐ | Network throughput and fetch_req_per_sec clearly rise |
| Memory Leak | ⭐⭐⭐ | JS heap rises slowly, requires observation time |
💼 Business Chaos¶
| Anomaly | Difficulty | Why |
|---|---|---|
| A2 Price rounding | ⭐ | Visible directly when comparing cart and catalog |
| A3 Stock not decremented | ⭐⭐ | Requires checking stock before and after order |
| A1 Incorrect VAT | ⭐⭐⭐ | 0.33% gap — requires manual calculation |
| A5 Double order | ⭐⭐ | Visible in the order list, reproduced by double-click |
| A6 Invalid promo code | ⭐⭐ | Test with a random code and observe the response |
| A10 False history | ⭐⭐⭐ | Requires several orders and a verification calculation |
| A11 Logout token | ⭐⭐⭐⭐ | Requires calling the API within 30s after logout |
🔒 Security Chaos¶
| Flaw | Difficulty | Why |
|---|---|---|
| S2 IDOR | ⭐ | Change the ID in the URL — immediate signal if 200 instead of 403 |
| S3 Exposed hash | ⭐ | Observe the /api/auth/me response — presence of the password field |
| S1 SQL Injection | ⭐⭐ | Try ' or ' OR '1'='1 in the search field |
| S4 Stored XSS | ⭐⭐ | Submit <script>alert(1)</script> in the shipping address |
| S5 Price tampering | ⭐⭐ | Intercept the purchase request (Burp) and change unitPrice |
| S6 Timing attack | ⭐⭐⭐ | Measure login δt — existing vs non-existing email (~300ms gap) |
| S9 Mass Assignment | ⭐⭐⭐ | Send email or password in the body of PUT /api/auth/me |
| S7 Weak HMAC token | ⭐⭐⭐⭐ | Decode X-Debug-Token, re-sign with known key, forge an admin token |
| S8 Path Traversal | ⭐⭐⭐⭐ | Inject ../ into the format parameter of the /invoice endpoint |
| S10 Portal stats | ⭐⭐ | Fuzz /api/admin/portal/stats — superadmin email exposed without auth |
| S11 Portal SQLi | ⭐⭐⭐ | Payload admin' OR '1'='1' -- on POST /api/admin/portal/login |
| S12 IDOR privesc | ⭐⭐⭐⭐ | Chain S10 → S11 → S12 to obtain a superAdmin account |