OWASP Top 10 — Hands-on lab

You take Juice Shop or DVWA. You drop three vulnerabilities from three different Top 10 categories. For each one: request, response, proof of impact. Bonus: a chain that links at least two of them together.

Budget: 3 h.

Deliverable: ~/labs/semaine-07/rapport/owasp.md with three complete records + preuves/ with all the artifacts.

Scope

These attacks run exclusively against Juice Shop, DVWA, WebGoat, or a target under explicit RoE. That is non-negotiable.

---

Prerequisites

Install at least one of the two applications:

# Juice Shop (recommended if you want modern Node/Angular)
docker run -d --name juice -p 3000:3000 bkimminich/juice-shop

# DVWA (recommended if you want legacy PHP)
docker run -d --name dvwa -p 8080:80 vulnerables/web-dvwa

On DVWA, set the difficulty to Low then Medium to progress.

Firefox + Burp Suite Community configured (see the walkthrough).

Create:

mkdir -p ~/labs/semaine-07/{preuves,rapport}

---

Step 1 — Pick 3 categories (10 min)

You must cover 3 different categories among these 6 (the most instructive):

1. A01 — Access control (IDOR or vertical)
2. A03 — SQL injection (with or without sqlmap)
3. A03 — Stored XSS (with a proof of impact, not just alert(1))
4. A05 — Security misconfiguration (dir listing, exposed panel, headers)
5. A07 — Authentication (login brute-force, weak cookies, JWT)
6. A10 — SSRF or LFI (Local File Inclusion, often classed as A03)

Note your choice at the top of rapport/owasp.md with one sentence of justification per choice.

---

Step 2 — Attack, category 1 (60 min)

For each category, produce the following record:

## Vulnerability — <category and title>

### Context
- Vulnerable URL: ...
- Required role: anonymous / user / admin
- DVWA difficulty: low / medium / high (if applicable)

### POC (technical proof)
- Request sent (exported from Burp):
  ```http
  ...
  ```
- Response received (revealing excerpt):
  ```
  ...
  ```

### Proof of impact
- Payload used for the impact: ...
- Concrete result: ...
- Excerpts or captures in preuves/<category>-*

### Recommendation
- Immediate fix: ...
- Root-cause fix: ...

Every section is mandatory. Without a proof of impact, the record is worthless.

---

Step 3 — Category 2 (60 min)

Same thing. A different category.

---

Step 4 — Category 3 (60 min)

Same thing. Different again.

---

Step 5 — The chain (30 min)

One chain minimum, combining two vulnerabilities you found, producing an impact greater than the sum of the parts.

Example chains:

• Stored XSS → admin cookie theft → admin takeover.
• IDOR → user enumeration → password spraying → compromise of 10 accounts.
• LFI → reading /etc/passwd then /proc/self/environ → recovery of an application secret → forgeable JWT.
• SSRF → reading AWS credentials via metadata → cloud takeover.
• Directory listing → exposed .git → clone → reading the source code → spotting a hardcoded password.

Document the chain in rapport/chaine.md:

# Attack chain — <short title>

## Step 1 — <flaw A>
[brief]

## Step 2 — <flaw B>
[brief]

## Step 3 — <combined exploitation>
[brief]

## Combined impact
[one strong sentence]

## Why it is worse than the sum of the parts
[one sentence]

This is the part most valued in a technical interview: showing that you can chain flaws.

---

Step 6 — Summary table (15 min)

Add a summary table to the report:

| Category | Title | Severity | Evidence | Chainable |
| --- | --- | --- | --- | --- |
| A01 | IDOR on /api/basket | High | preuves/A01.md | Yes, with A03 |
| A03 | SQLi in /search | Critical | preuves/A03.md | Yes |
| A07 | JWT alg=none | Critical | preuves/A07.md | Yes, with A01 |

---

Self-assessment checklist

• Three different categories covered.
• Each record: context + POC + proof of impact + recommendation.
• All requests / responses exported from Burp into preuves/.
• No record limited to an alert(1) or an id=1'--.
• One chain documented in chaine.md with at least two flaws.
• Summary table complete.
• No mass data extraction (lab RoE respected).
• All attacks against authorized targets.

---

Optional extension — Write a Nuclei template

Take the simplest vulnerability you found. Write a Nuclei YAML template that detects it:

id: juice-shop-idor-basket
info:
  name: Juice Shop - IDOR on /rest/basket
  author: <you>
  severity: high

requests:
  - method: GET
    path:
      - '{{BaseURL}}/rest/basket/1'
    headers:
      Authorization: "Bearer {{token}}"
    matchers:
      - type: word
        words:
          - '"UserId":1'

Test it:

nuclei -u http://10.10.10.50:3000 -t votre-template.yaml

A working Nuclei template is the equivalent of a blog post — it's what you put in a portfolio.

---

What usually blocks you

Symptom	Cause	Fix
Burp doesn't see the HTTPS	Cert not installed	Reload http://burpsuite and import the CA.
sqlmap says not injectable	Wrong insertion point	Specify -p <param> and tune the level --level=3 --risk=2.
XSS payload filtered	Difficulty too high	Drop it to low to understand, then raise it back.
JWT cracking finds nothing	Strong key	Normal. Document it as an instructive failure, it isn't a problem.
SSRF returns nothing	App server filters private IPs	Try 127.0.0.1, then localhost, then [::1], then 2130706433 (decimal encoding).

---

What you take away from this lab

• Three vulnerabilities actually exploited, with evidence.
• One chain that shows how you think.
• A report structured like a client pentest.
• The ability to reproduce these attacks in a technical interview.

Next step: the module quiz. After that we enter module 8 — Metasploit — where we automate and chain at scale.