Week 2, Practical — Threat Modelling on OWASP Juice Shop

Cybersecurity & Secure Programming

Slot: W2 P Real budget: 100 min Phase split: 10 + 15 + 30 + 40 + 15 + 10 Environment: Docker / Juice Shop v19.2.1 Book chapter: 6

Important

This is the practical that pays off Chapters 4 and 5. Students arrive with two lecture hours of threat-modelling theory (Shostack’s Four Questions, the DFD, STRIDE, LINDDUN, PASTA). The contract for the next two hours is short: identify the threat, then prove it. By the end of the session, every pair leaves with a Level-1 DFD, a STRIDE-mapped threat list of fifteen-plus rows, and three working exploits against a live Juice Shop instance.

Slides

Before the practical

Students should arrive with:

  • The Week 1 lab environment working — Kali VM with Docker, the clean-install snapshot, two-NIC network. If your Week 1 verification table is not green, fix that first. This practical assumes it.

  • The book chapter (Chapter 6 — Week 2, Practical: Threat-Modelling a Real App) read in advance. The chapter contains the full eighteen-threat answer key and the four-line scope statement; the lab is execution, not exposition.

  • OWASP Juice Shop v19.2.1 pre-pulled. Run this at home, not on campus Wi-Fi:

    docker pull bkimminich/juice-shop
docker run --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop

    Confirm the landing page loads at http://localhost:3000 from inside the Kali VM, then Ctrl-C the container until the lab.

  • OWASP Threat Dragon v2.6.0 installed (desktop AppImage / Windows / macOS binary from https://github.com/OWASP/threat-dragon/releases), or the hosted web app at https://www.threatdragon.com opened and tested. Fallbacks: draw.io (https://www.drawio.com) or Excalidraw (https://excalidraw.com).

  • Pen and paper. Non-negotiable. The first twenty minutes of any threat-modelling session belongs on paper, not in a tool. A3 if you can; A4 stapled together if not.

Warning

Bind to 127.0.0.1, not 0.0.0.0. The exact port-publish flag — -p 127.0.0.1:3000:3000 — is doing real work. The shorter -p 3000:3000 form binds Juice Shop to every interface on your laptop, which on the campus Wi-Fi means the entire room can see, browse and break your instance. Funny once. Two hours of cleanup the second time.

Lab activity

The chapter walks the two-hour flow minute by minute. Students work in pairs for the whole session except minutes 10–25, where pairs combine into tables of six to eight for the Elevation of Privilege card-game warm-up.

Phase Time What happens
1. Frame & recap 0:00–0:10 Four Questions back on the board. Lecturer models the four-line scope statement on the projector; students copy it.
2. EoP card-game warm-up 0:10–0:25 Tables of 6–8. Microsoft / Shostack’s Elevation of Privilege deck (78 cards, six STRIDE-suits, Tampering trumps). Goal: 5–10 plausible threats per table.
3. Draw the DFD 0:25–0:55 First ten minutes strictly on paper. Switch to Threat Dragon at minute 35. Lecturer says “stop drawing” out loud at minute 53.
4. STRIDE pass 0:55–1:35 Six pairs take a STRIDE letter; remaining pairs take a DFD element. Each pair produces 2–4 threats, every threat mapped to a specific Juice Shop challenge.
5. Report-out & consolidate 1:35–1:50 Master STRIDE × DFD-element matrix on the board. Force the four-way decision (Mitigate / Eliminate / Transfer / Accept) on every row. Reject “TBD”.
6. Live exploit of the top three 1:50–2:00 Class votes. Lecturer drives. Reliable picks: T1 (' OR 1=1--), T11 (forge JWT with the leaked key), T13 (decrement basket ID).

The Level-1 DFD — what to put on the page

The full DFD figure is in the chapter (Figure 6.1). The skeleton:

  • External entities (squares): E1 anonymous visitor, E2 registered customer, E3 administrator, E4 mock payment endpoint.
  • Processes (circles): P1 Angular SPA, P2 Auth API, P3 Basket API, P4 Coupon engine, P5 Order/payment processor.
  • Data stores (parallel-line boxes): D1 SQLite DB, D2 ftp/ receipts directory, D3 JWT signing key — encryptionkeys/jwt.key, in source.
  • Trust boundaries (dashed red lines): TB1 Internet ↔︎ Server, TB2 Server ↔︎ Database, TB3 Server ↔︎ Third-party payment, TB4 Server ↔︎ Filesystem.

A DFD without trust boundaries is decorative. Every interesting threat sits on a flow that crosses one.

The eighteen-threat STRIDE pass — six headline threats

The chapter’s full eighteen-row threat list (§6.3 of the book) is the spine of the lab. It is a STRIDE × DFD-element matrix populated with verified Juice Shop challenge keys from data/static/challenges.yml. The six threats below are the headline ones every strong cohort surfaces — point pairs at this list when they get stuck.

ID STRIDE Threat Juice Shop challenge
T1 S SQL injection in login: ' OR 1=1-- returns the admin row loginAdminChallenge
T7 T BasketId is client-supplied; POST a BasketItem to another user’s basket basketManipulateChallenge
T11 R / E JWT signing key checked into the public source tree at encryptionkeys/jwt.key. Any attacker on the open internet can forge a valid JWT for any user, including admin jwtForgedChallenge
T13 I Horizontal IDOR: decrement the basket ID in the URL, get the previous user’s basket. The Optus 2022 pattern, exactly basketAccessChallenge
T21 E POST /api/Users honours a role field from the request body — register yourself an admin account registerAdminChallenge
T22 E /#/administration is guarded only by client-side JavaScript. Direct navigation works adminSectionChallenge
Important

T11 — the marquee learning moment. The signing key for Juice Shop’s JWTs is a real RSA private key in the public GitHub repository at encryptionkeys/jwt.key. An attacker on the open internet has it. They can forge tokens that the server cryptographically trusts — defeating both authentication and repudiation. The “oh” moment when students realise this is the pedagogical payload of the practical. The mitigation is not “rotate the key occasionally”. It is eliminate: never commit signing keys to source control, hold them in a secrets manager (KMS, Vault), generate per environment, rotate, audit.

The full table covers every STRIDE letter: T1/T2/T4/T5 on Spoofing; T6/T7/T9 on Tampering; T10/T11/T12 on Repudiation; T13/T14/T15 on Information disclosure; T18/T20 on DoS; T21/T22/T25 on Elevation. See the chapter for the per-row threat statement, mitigation, and challenge key.

The four-way decision

Every row in the consolidated list gets a decision. The chapter is explicit: “TBD” is a row where the threat model has failed. The four choices:

  • Mitigate — most rows. Add a control: parameterised query, JWT-subject check, server-side role enforcement.
  • Eliminate — remove the threat surface entirely. T11 is eliminated: rotate the key, scrub history, KMS, never commit. Not mitigated.
  • Transfer — push it to someone else. Insurance. A third-party payment processor.
  • Accept — say so explicitly. T20 (legacy XML XXE) is the canonical “interface deprecated, sunset Q4” example.
Note

Pencil first. Switch to a tool only when the diagram is stable. Reaching for Threat Dragon before the diagram is settled means the next twenty minutes go on dragging shapes, not finding threats. Shostack: “obsessing over diagram types” is itself an anti-pattern.

Deliverable

One PDF, 4–6 pages, one per pair, due by 17:00 the Friday after the lab. Submitted to Moodle as comp09031-w2-<surname1>-<surname2>.pdf.

Section Length What’s in it
Cover ~½ page Pair names, student numbers, four-line scope statement, three named assumptions
DFD 1 page Level-1 diagram exported from Threat Dragon (or draw.io / Excalidraw); at least three trust boundaries, directional and labelled flows
Threat list 1–2 pages Table: ID, DFD element, STRIDE letter, threat, severity (L/M/H), decision, owner, linked challenge. 15–20 rows
Mitigation notes 1–1½ pages Top five threats by severity; one paragraph each on the recommended control, traceable to OWASP ASVS or CWE
Reflection 1 page Three retrospective prompts: what we missed, what we over-modelled, what we’d do differently

Rubric

Component Weight What “good” looks like
Scoping 10% Clear in/out scope statement. Three named assumptions.
DFD quality 20% All four shapes used correctly. Arrows directional and labelled. At least three trust boundaries. Not a network diagram.
STRIDE coverage and depth 40% At least one credible threat per letter on at least three elements. Every row carries a Juice Shop challenge key.
Mitigation realism 20% Each top-five mitigation names a specific control (a header, a cookie flag, a parser config, an IAM policy) — not “validate input”. One control must be a code/config change, not a process change.
Reflection 10% One page on what surprised the pair, what they’d do differently, and one assumption the model rests on that they did not write down.

Common student questions

These come up reliably; recognise the symptom and resolve in seconds rather than minutes.

  • “Why does Juice Shop bind to 127.0.0.1 rather than 0.0.0.0?” — Juice Shop is intentionally vulnerable. Binding to 0.0.0.0 exposes it to the whole lab subnet, which on the campus Wi-Fi means dozens of identical fish-in-a-barrel targets. Bind to localhost.
  • “I can’t find the JWT key inside the running container — where is it?” — You can find it inside the container, and that misses the point. The threat is that the key is also checked into the public source tree at encryptionkeys/jwt.key on GitHub. Browse to the upstream repo and find the file there. That is T11.
  • “Where do I draw the trust boundaries?” — Across any line where the level of trust changes. Browser → server (TB1), server → database (TB2), server → third-party payment (TB3), server → filesystem (TB4). The four-boundary skeleton in §6.2 is the minimum.
  • “Is this an architecture diagram or a DFD?” — A DFD has directional, labelled arrows and explicit trust boundaries. A box labelled Express with an unlabelled line to a box labelled SQLite is an architecture sketch. If your diagram could appear unchanged in a marketing deck, it isn’t a DFD.
  • “We have eighteen threats but no decisions — is that fine?” — No. A threat list without decisions is a wishlist, and it gets ignored. Every row needs Mitigate / Eliminate / Transfer / Accept, plus an owner role.
  • “Can I look up the Juice Shop walk-throughs?” — Use the Pwning OWASP Juice Shop guide (https://pwning.owasp-juice.shop/) after the session, not during. The pedagogical value depends on you finding bugs by reasoning, not by reading walk-throughs.

End-of-practical self-check

Optional, formative — not graded. Confirms the conceptual material from the lab landed.

Going further

These are optional and entirely up to you. Each is good. None is required.

  • pytm — threat modelling as code. Izar Tarandach’s library (https://github.com/izar/pytm) lets you declare the system as Python objects and run a script to emit a Graphviz DFD, a PlantUML sequence diagram, and a markdown threat report. The 20-line Juice Shop login sketch in the chapter is a worthwhile demo for the strong cohort. Setup wants Python 3.x, Graphviz, OpenJDK 10/11 and plantuml.jar — too much friction for the 2-hour lab itself; the right answer to “how does this scale to a real codebase?”
  • Brett Crawley, Threat Modeling Gameplay with EoP (Packt, 2024). The book-length companion to the EoP card game: each card gets a chapter; each chapter takes the threat from “interesting card” to “real-world mitigation”. The right next read for anyone who enjoyed the warm-up.
  • Pwning OWASP Juice Shop by Bjorn Kimminich (https://pwning.owasp-juice.shop/). Step-by-step solutions to every challenge, plus an architecture chapter and a hint system. Use it for the post-lab self-mark, not during the session.
  • MultiJuicer. OWASP’s Helm chart for running Juice Shop at thirty-students-at-once scale, with per-student namespaces and a per-student score board (https://github.com/juice-shop/multi-juicer). Overkill for this lab; the right answer for a CTF-style assessment later in the module.
  • Threat Modeling Manifesto (https://www.threatmodelingmanifesto.org/). Four values, five principles, and the Hero Threat Modeler / Admiration for the Problem anti-patterns. Worth bookmarking before any real-world threat-modelling session.

← Schedule ← Week 2 Lecture 2 Next: Week 3 (coming soon) →