Anwendungen

Anwendungsübersicht

Jede Anwendung läuft als 4 lastverteilte Docker-Container hinter nginx-Upstream-Pools und ist über den nginx-Reverse-Proxy auf der VM erreichbar. Sticky Sessions stellen sicher, dass zustandsbehaftete Anwendungen (Juice Shop, DVWA, VAmPI, CSD Demo) konsistent weitergeleitet werden. Alle Anwendungen sind absichtlich verwundbar und für Sicherheitstests konzipiert.

Ersetzen Sie <ORIGIN> in allen nachfolgenden Beispielen durch http://<PUBLIC_IP>. Nach dem Deployment über Terraform erhalten Sie die IP mit terraform output -raw public_ip.

Kurzreferenz — Alle URL-Pfade

Pfad	Anwendung	HTTP-Methode	Erwartete Antwort
`/`	Startseite	GET	200 HTML mit Links zu allen Apps
`/health`	Gesundheitsprüfung	GET	200 JSON `{"status":"healthy","component":"origin-server",...}`
`/juice-shop/`	Juice Shop	GET	200 HTML (Angular SPA, ~75 KB)
`/juice-shop/rest/products/search?q=`	Juice Shop API	GET	200 JSON `{"status":"success","data":[...]}` (36 Produkte)
`/dvwa/`	DVWA	GET	302 Weiterleitung zu `/dvwa/login.php`
`/dvwa/login.php`	DVWA Login	GET	200 HTML Login-Formular
`/dvwa/setup.php`	DVWA Setup	GET	200 HTML (erstmalige Datenbank-Initialisierung)
`/vampi/`	VAmPI	GET	200 HTML (API-Dokumentation)
`/vampi/users/v1`	VAmPI API	GET	200 JSON `{"users":[...]}`
`/vampi/users/v1/register`	VAmPI API	POST	200 JSON `{"status":"success",...}`
`/vampi/users/v1/login`	VAmPI API	POST	200 JSON `{"auth_token":"...","status":"success"}`
`/httpbin/get`	httpbin	GET	200 JSON mit Anfrage-Details
`/httpbin/post`	httpbin	POST	200 JSON mit gesendeten Daten
`/httpbin/headers`	httpbin	GET	200 JSON `{"headers":{...}}`
`/httpbin/status/:code`	httpbin	GET	Gibt den angegebenen HTTP-Statuscode zurück
`/whoami/`	whoami	GET	200 Klartext mit Hostname, IP, allen Headern
`/csd-demo/`	CSD Demo	GET	200 HTML Checkout-Formular mit Angriffs-Panel
`/csd-demo/dashboard`	CSD Angreifer-Ansicht	GET	200 HTML mit exfiltrierten Daten
`/csd-demo/health`	CSD Gesundheitsprüfung	GET	200 JSON `{"status":"healthy","component":"csd-demo",...}`
`/csd-demo/exfil/log`	CSD Exfil-Protokoll	GET	200 JSON-Array der erfassten Daten
`/dvga/`	DVGA GraphiQL	GET	200 HTML (GraphiQL IDE)
`/dvga/graphql`	DVGA GraphQL API	POST	200 JSON GraphQL-Antwort
`/restaurant/`	RESTaurant	GET	200 (Weiterleitung zur Dokumentation)
`/restaurant/docs`	RESTaurant Swagger	GET	200 HTML (FastAPI Swagger UI)
`/restaurant/openapi.json`	RESTaurant OpenAPI	GET	200 JSON OpenAPI-Spezifikation
`http://<PUBLIC_IP>:8888`	crAPI	GET	200 HTML (SPA)
`http://<PUBLIC_IP>:8888/identity/api/auth/signup`	crAPI Registrierung	POST	200 JSON
`http://<PUBLIC_IP>:8888/identity/api/auth/login`	crAPI Login	POST	200 JSON `{"token":"..."}`

OWASP Juice Shop


Pfad	`/juice-shop/`
Image	`bkimminich/juice-shop:latest`
Instanzen	4 (Ports 3001-3004), Sticky via `hash $cookie_token`, Proxy-Cache (60 s TTL)
Ressourcen	2 CPU / 1 GiB RAM pro Instanz
Framework	Node.js / Angular
Projekt	owasp.org/www-project-juice-shop

OWASP Juice Shop ist die modernste und am aktivsten gepflegte verwundbare Webanwendung. Sie deckt die gesamten OWASP Top 10 mit über 100 Herausforderungen in einer realistischen E-Commerce-Anwendung ab.

Demo-Szenarien

Szenario	Kategorie	Angriffsvektor
SQL-Injection Login-Bypass	WAF	`' OR 1=1--` im Login-E-Mail-Feld
Reflektiertes XSS	WAF, CSD	Script-Injection über Suchparameter
DOM-basiertes XSS	CSD	Payload im URL-Fragment
Fehlerhafte Authentifizierung	WAF	Brute-Force-Login, JWT-Manipulation
API-Missbrauch	API-Sicherheit	Unautorisierter Zugriff auf `/api/`-Endpunkte
Offenlegung sensibler Daten	API-Sicherheit	Zugriff auf Benutzerdaten ohne Autorisierung
CSRF	WAF	Cross-Site Request Forgery bei Profiländerungen

Zugriff

curl -s "http://<PUBLIC_IP>/juice-shop/" -o /dev/null -w "%{http_code}"

DVWA (Damn Vulnerable Web Application)


Pfad	`/dvwa/`
Image	Benutzerdefiniertes `dvwa-fpm:latest` (php-fpm + nginx, erstellt aus `ghcr.io/digininja/dvwa:latest`)
Instanzen	4 (Ports 8101-8104), Sticky via `hash $cookie_PHPSESSID`
Ressourcen	0,5 CPU / 256 MiB RAM pro Instanz
Datenbank	Gemeinsame MariaDB 10.11 (`dvwa-db`-Container, 1 CPU / 768 MiB)
Framework	PHP 8 / php-fpm / MariaDB
Anmeldedaten	`admin` / `password`

DVWA ist der Industriestandard für WAF-Tests. Es verfügt über einstellbare Sicherheitsstufen (Low, Medium, High, Impossible), die schrittweise Eingabevalidierung und Ausgabekodierung hinzufügen.

Demo-Szenarien

Szenario	Kategorie	Sicherheitsstufe
SQL-Injection	WAF	Low: triviales `' OR 1=1#`, High: Blind SQLi
Command Injection	WAF	Low: `; ls`, High: gefilterte Zeichen
File Inclusion	WAF	Low: direkter Path Traversal, High: bereinigt
XSS (Reflektiert)	WAF, CSD	Low: einfaches `<script>`, High: kodierter Bypass
XSS (Gespeichert)	WAF, CSD	Low: persistentes Script im Gästebuch
Datei-Upload	WAF	Low: PHP-Shell-Upload, High: Erweiterungsfilterung
Brute Force	Bot-Schutz	Automatisierte Login-Versuche

Sicherheitsstufen

Setzen Sie die Sicherheitsstufe unter /dvwa/security.php nach dem Login:

Low — Keine Eingabevalidierung. Jeder Angriff funktioniert. Gut für WAF-Signatur-Demonstrationen.
Medium — Grundlegende Filterung. Einige Angriffe erfordern Kodierung oder Bypass-Techniken.
High — Starke Filterung. Nur fortgeschrittene Techniken sind erfolgreich. Gut um WAF-Einschränkungen aufzuzeigen.
Impossible — Vollständig sichere Implementierung. Demonstriert korrekte defensive Programmierung.

Ersteinrichtung

DVWA erfordert eine einmalige Datenbankeinrichtung nach dem ersten Deployment:

Navigieren Sie zu http://<PUBLIC_IP>/dvwa/setup.php
Klicken Sie auf Create / Reset Database
Melden Sie sich mit admin / password an

VAmPI (Vulnerable API)


Pfad	`/vampi/`
Image	`erev0s/vampi:latest` mit gunicorn-Einstiegspunkt (4 Worker)
Instanzen	4 (Ports 5101-5104), Sticky via `ip_hash` (SQLite pro Instanz)
Ressourcen	0,5 CPU / 512 MiB RAM pro Instanz
Framework	Python / Flask / gunicorn
Projekt	github.com/erev0s/VAmPI

VAmPI wurde speziell zum Testen der OWASP API Security Top 10 entwickelt. Es bietet eine realistische REST-API mit absichtlichen Schwachstellen. Jede Instanz führt gunicorn mit 4 Workern und einer eigenen SQLite-Datenbank aus. Die ip_hash-Sticky-Session stellt sicher, dass Registrierung und Login von derselben Client-IP immer dieselbe Instanz erreichen.

Demo-Szenarien

Szenario	OWASP API Top 10	Methode
Broken Object Level Authorization (BOLA)	API1	Zugriff auf Daten anderer Benutzer durch Manipulation von IDs
Fehlerhafte Authentifizierung	API2	Schwache Token-Verwaltung, kein Rate Limiting
Übermäßige Datenoffenlegung	API3	API gibt mehr Daten zurück als der Client benötigt
Mass Assignment	API6	Admin-Felder über unerwartete Parameter ändern
SQL-Injection	API8	Injection über API-Parameter
Unsachgemäße Asset-Verwaltung	API9	Undokumentierte API-Endpunkte

API-Endpunkte

# Neuen Benutzer registrieren
curl -X POST "http://<PUBLIC_IP>/vampi/users/v1/register" \
  -H "Content-Type: application/json" \
  -d '{"username":"test","password":"test123","email":"test@test.com"}'

# Anmelden
curl -X POST "http://<PUBLIC_IP>/vampi/users/v1/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"test","password":"test123"}'

# Benutzer auflisten (übermäßige Datenoffenlegung)
curl "http://<PUBLIC_IP>/vampi/users/v1"

httpbin


Pfad	`/httpbin/`
Image	`kennethreitz/httpbin:latest` mit gunicorn CMD-Überschreibung (`-w 4 -k gevent --timeout 30`)
Instanzen	4 (Ports 8201-8204), Round-Robin (zustandslos)
Ressourcen	0,5 CPU / 256 MiB RAM pro Instanz
Framework	Python / Flask / gunicorn + gevent
Projekt	httpbin.org

httpbin ist ein einfacher HTTP-Anfrage-/Antwortdienst, der für grundlegende API-Demos, das Testen von Anfrage-Headern und die Überprüfung des Proxy-Verhaltens nützlich ist.

Nützliche Endpunkte

Endpunkt	Zweck
`/httpbin/get`	Gibt GET-Anfragedaten zurück (Header, Argumente, Herkunft)
`/httpbin/post`	Gibt POST-Anfragedaten zurück (Body, Formular, JSON)
`/httpbin/headers`	Gibt Anfrage-Header zurück
`/httpbin/ip`	Gibt Herkunfts-IP zurück
`/httpbin/user-agent`	Gibt User-Agent-Header zurück
`/httpbin/status/:code`	Gibt den angegebenen HTTP-Statuscode zurück
`/httpbin/delay/:seconds`	Verzögert die Antwort um N Sekunden
`/httpbin/anything`	Gibt alles zurück, was in der Anfrage übergeben wurde

Beispiel

# Prüfen, welche Header der Origin sieht (nützlich zur Überprüfung der F5 XC Header-Injection)
curl -s "http://<PUBLIC_IP>/httpbin/headers" | jq .

# Einen bestimmten HTTP-Statuscode testen
curl -s -o /dev/null -w "%{http_code}" "http://<PUBLIC_IP>/httpbin/status/403"

whoami (Anfrage-Diagnose)


Pfad	`/whoami/`
Image	`traefik/whoami:latest`
Instanzen	4 (Ports 8082-8085), Round-Robin (zustandslos)
Ressourcen	0,25 CPU / 64 MiB RAM pro Instanz
Framework	Go
Projekt	github.com/traefik/whoami

whoami ist Traefiks leichtgewichtiger Request-Echo-Server. Er zeigt jedes Detail der eingehenden HTTP-Anfrage an, wie es der Origin sieht — Hostname, IP-Adressen, alle Header, Methode und URL. Dies ist das wichtigste Diagnosetool bei der Überprüfung, ob F5 XC die korrekten Header injiziert.

Wichtige Anwendungsfälle

Anwendungsfall	Worauf zu achten ist
F5 XC Header-Injection überprüfen	`X-Forwarded-For`, `True-Client-IP`, `X-Volterra-*` Header
Client-IP-Sichtbarkeit bestätigen	`X-Real-IP` vs `RemoteAddr`
WAF-False-Positives debuggen	Anfrage-Header vor/nach F5 XC vergleichen
Bot-Defense-Tagging validieren	`X-Volterra-Bot-Type`, `X-Volterra-Bot-Verified` Header
TLS-Terminierung prüfen	`X-Forwarded-Proto` zeigt `https` wenn TLS bei F5 XC terminiert wird

Beispiel

# Einfache Anfrage -- sehen was der Origin empfängt
curl "http://<PUBLIC_IP>/whoami/"

# Anfrage durch F5 XC simulieren (mit injizierten Headern)
curl "http://<PUBLIC_IP>/whoami/" \
  -H "X-Forwarded-For: 203.0.113.50" \
  -H "True-Client-IP: 203.0.113.50" \
  -H "X-Forwarded-Proto: https"

Beispielausgabe:

Hostname: 534c5084e169
IP: 127.0.0.1
RemoteAddr: 172.17.0.1:55118
GET / HTTP/1.1
Host: 20.12.78.159
User-Agent: curl/8.5.0
Accept: */*
True-Client-Ip: 203.0.113.50
X-Forwarded-For: 203.0.113.50, 10.0.0.1
X-Forwarded-Proto: https
X-Real-Ip: 104.219.105.84

DVGA (Damn Vulnerable GraphQL Application)


Pfad	`/dvga/`
Image	`dolevf/dvga:latest`
Instanzen	4 (Ports 5201-5204), Sticky via `ip_hash` (SQLite pro Instanz)
Ressourcen	0,5 CPU / 256 MiB RAM pro Instanz
Framework	Python / Flask / GraphQL
Projekt	github.com/dolevf/Damn-Vulnerable-GraphQL-Application

DVGA wurde speziell zum Testen von GraphQL-spezifischen Schwachstellen entwickelt. Es bietet eine GraphiQL-IDE unter /dvga/ für interaktive Query-Exploration und einen GraphQL-API-Endpunkt unter /dvga/graphql. Jede Instanz verwendet ihre eigene SQLite-Datenbank, daher stellen ip_hash-Sticky-Sessions einen konsistenten Zustand sicher.

Demo-Szenarien

Szenario	Kategorie	Angriffsvektor
GraphQL-Injection	API-Sicherheit	Bösartige Queries über String-Interpolation
Denial of Service	API-Sicherheit	Tief verschachtelte Queries, Batch-Queries, Ressourcenerschöpfung
Autorisierungs-Bypass	API-Sicherheit	Zugriff auf unautorisierte Daten über GraphQL
Informationsoffenlegung	API-Sicherheit	Introspection-Queries, die Schema-Details offenlegen
Batching-Angriff	API-Sicherheit	Mehrere Operationen in einer einzelnen Anfrage

Wichtige Endpunkte

# GraphiQL UI (interaktive IDE)
curl -sf "http://<PUBLIC_IP>/dvga/" -o /dev/null -w "%{http_code}"

# Introspection-Query -- vollständiges Schema enumerieren
curl -s "http://<PUBLIC_IP>/dvga/graphql" \
  -H "Content-Type: application/json" \
  -d '{"query":"{ __schema { types { name fields { name } } } }"}'

# Pastes auflisten (Beispiel-Query)
curl -s "http://<PUBLIC_IP>/dvga/graphql" \
  -H "Content-Type: application/json" \
  -d '{"query":"{ pastes { title content } }"}'

# Paste erstellen (Mutation)
curl -s "http://<PUBLIC_IP>/dvga/graphql" \
  -H "Content-Type: application/json" \
  -d '{"query":"mutation { createPaste(title:\"test\", content:\"hello\", public:true) { paste { title } } }"}'

RESTaurant (Damn Vulnerable RESTaurant API Game)


Pfad	`/restaurant/`
Image	Benutzerdefinierter Build aus `theowni/Damn-Vulnerable-RESTaurant-API-Game`
Instanzen	4 (Ports 8301-8304), Round-Robin (gemeinsame PostgreSQL)
Ressourcen	0,5 CPU / 256 MiB RAM pro Instanz
Datenbank	Gemeinsame PostgreSQL 15.4 (`restaurant-db`-Container, 0,5 CPU / 512 MiB)
Framework	Python / FastAPI / PostgreSQL
Anmeldedaten	`admin` / `password` (PostgreSQL)
Projekt	github.com/theowni/Damn-Vulnerable-RESTaurant-API-Game

RESTaurant ist eine gamifizierte verwundbare REST-API, die die OWASP API Security Top 10 2023 abdeckt. Sie verwendet FastAPI mit automatischer Swagger-UI-Dokumentation unter /restaurant/docs. Alle 4 Instanzen teilen sich eine einzelne PostgreSQL-Datenbank, sodass Round-Robin-Lastverteilung ohne Sticky Sessions funktioniert.

Demo-Szenarien

Szenario	OWASP API Top 10 2023	Methode
Broken Object Level Authorization (BOLA)	API1	Zugriff auf Bestellungen anderer Benutzer durch Manipulation von IDs
Fehlerhafte Authentifizierung	API2	Schwache Token-Verwaltung, Credential Stuffing
Broken Object Property Level Authorization	API3	Mass Assignment bei Benutzerprofil-Feldern
Unbeschränkter Ressourcenverbrauch	API4	Kein Rate Limiting bei Endpunkten
Broken Function Level Authorization (BFLA)	API5	Zugriff auf Admin-Endpunkte als normaler Benutzer
Server Side Request Forgery (SSRF)	API7	Manipulation serverseitiger URL-Anfragen
Sicherheitsfehlkonfiguration	API8	Ausführliche Fehlermeldungen, Standard-Anmeldedaten

Wichtige Endpunkte

# Swagger UI
curl -sf "http://<PUBLIC_IP>/restaurant/docs" -o /dev/null -w "%{http_code}"

# OpenAPI-Spezifikation
curl -s "http://<PUBLIC_IP>/restaurant/openapi.json" | jq .info

# BOLA -- auf Bestellung eines anderen Benutzers zugreifen (nach Authentifizierung)
curl -s "http://<PUBLIC_IP>/restaurant/orders/1" \
  -H "Authorization: Bearer <token>"

# BFLA -- Admin-Aktion als normaler Benutzer versuchen
curl -s -X POST "http://<PUBLIC_IP>/restaurant/admin/users" \
  -H "Authorization: Bearer <user_token>" \
  -H "Content-Type: application/json"

crAPI (OWASP Completely Ridiculous API)


Port	`8888` (dediziert — nicht pfad-präfixiert)
Images	`crapi/crapi-web`, `crapi/crapi-identity`, `crapi/crapi-community`, `crapi/crapi-workshop`, PostgreSQL, MongoDB, MailHog
Instanzen	7 Microservices (jeweils eine Instanz)
Ressourcen	~3,0 CPU / ~2,0 GiB RAM insgesamt
Framework	React SPA + Java/Go/Python Microservices
Projekt	github.com/OWASP/crAPI

crAPI ist das OWASP-Flaggschiffprojekt für API-Sicherheitstests. Es läuft als 7 Microservices auf einem dedizierten Port (8888), da die React-SPA ihre API-Pfade fest kodiert hat und nicht hinter einem Pfad-Präfix bereitgestellt werden kann. Die NSG erlaubt eingehenden Datenverkehr auf Port 8888.

MailHog erfasst alle von crAPI gesendeten E-Mails (Kontobestätigung, Passwort-Zurücksetzung). Zugriff auf MailHog über SSH-Tunnel auf Port 18025.

Herausforderungskategorien

Kategorie	Schwachstellen
BOLA (Broken Object Level Authorization)	Zugriff auf Fahrzeuge, Bestellungen und Berichte anderer Benutzer
BFLA (Broken Function Level Authorization)	Eskalation zum Admin, Zugriff auf eingeschränkte Endpunkte
Mass Assignment	Geschützte Felder (Rolle, Guthaben) über API ändern
SSRF (Server Side Request Forgery)	Manipulation des serverseitigen URL-Abrufs
JWT-Manipulation	JWT-Token fälschen oder ändern zur Privilegieneskalation
NoSQL-Injection	Queries in MongoDB-gestützte Endpunkte injizieren
Übermäßige Datenoffenlegung	API gibt sensible Benutzerdaten zurück

Erste Schritte

# Überprüfen ob crAPI läuft
curl -sf "http://<PUBLIC_IP>:8888" -o /dev/null -w "%{http_code}"

# Neuen Benutzer registrieren
curl -s -X POST "http://<PUBLIC_IP>:8888/identity/api/auth/signup" \
  -H "Content-Type: application/json" \
  -d '{"name":"Test User","email":"test@example.com","number":"1234567890","password":"Test1234!"}'

# Anmelden
curl -s -X POST "http://<PUBLIC_IP>:8888/identity/api/auth/login" \
  -H "Content-Type: application/json" \
  -d '{"email":"test@example.com","password":"Test1234!"}'

# Zugriff auf MailHog (über SSH-Tunnel für E-Mail-Verifizierung)
# ssh -L 18025:localhost:18025 azureuser@<PUBLIC_IP>
# Dann http://localhost:18025 im Browser öffnen

crAPI-Architektur

Port 8888 -> crapi-web (React SPA + nginx)
             -> crapi-identity (Java, Benutzer-Auth, JWT)
             -> crapi-community (Go, Foren, Beiträge)
             -> crapi-workshop (Python, Fahrzeugservice)
             -> crapi-postgres (PostgreSQL)
             -> crapi-mongo (MongoDB)
             -> crapi-mailhog (E-Mail-Erfassung, Port 18025)

Anwendungsabdeckungsmatrix

Demo-Anwendungsfall	Primäre App	Sekundäre App
WAF — SQL-Injection	DVWA	Juice Shop
WAF — XSS	DVWA	Juice Shop
WAF — Command Injection	DVWA	—
API-Sicherheit — BOLA	VAmPI	—
API-Sicherheit — Auth-Bypass	VAmPI	Juice Shop
API-Sicherheit — Datenoffenlegung	VAmPI	httpbin
Bot-Schutz — Brute Force	DVWA	Juice Shop
Bot-Schutz — Scraping	Juice Shop	—
Client-Side Defense — DOM XSS	Juice Shop	—
Client-Side Defense — Gespeichertes XSS	DVWA	Juice Shop
Client-Side Defense — Card Skimmer	CSD Demo	—
Client-Side Defense — Formjacker	CSD Demo	—
Client-Side Defense — Keylogger	CSD Demo	—
Client-Side Defense — Cryptominer	CSD Demo	—
Client-Side Defense — DOM Hijack	CSD Demo	—
API-Sicherheit — GraphQL-Injection	DVGA	—
API-Sicherheit — GraphQL DoS	DVGA	—
API-Sicherheit — OWASP API Top 10 2023	RESTaurant	crAPI
API-Sicherheit — BFLA	RESTaurant	crAPI
API-Sicherheit — Mass Assignment	crAPI	RESTaurant
API-Sicherheit — SSRF	crAPI	RESTaurant
API-Sicherheit — JWT-Manipulation	crAPI	—
API-Sicherheit — NoSQL-Injection	crAPI	—
Grundlegende Konnektivitätstests	httpbin	—
Anfrage-Diagnose	whoami	httpbin
Header-Injection-Überprüfung	whoami	—