Applicazioni

Panoramica delle applicazioni

Ogni applicazione viene eseguita come 4 container Docker bilanciati dietro pool upstream nginx, accessibili tramite il proxy inverso nginx sulla VM. Le sessioni sticky garantiscono che le applicazioni stateful (Juice Shop, DVWA, VAmPI, CSD Demo) vengano instradate in modo coerente. Tutte le applicazioni sono intenzionalmente vulnerabili e progettate per i test di sicurezza.

Sostituire <ORIGIN> con http://<PUBLIC_IP> in tutti gli esempi seguenti. Dopo la distribuzione tramite Terraform, ottenere l’IP con terraform output -raw public_ip.

Riferimento rapido — Tutti i percorsi URL

Percorso	Applicazione	Metodo HTTP	Risposta attesa
/	Pagina di destinazione	GET	200 HTML con collegamenti a tutte le app
/health	Controllo integrità	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=	API Juice Shop	GET	200 JSON {"status":"success","data":[...]} (36 prodotti)
/dvwa/	DVWA	GET	302 reindirizzamento a /dvwa/login.php
/dvwa/login.php	Login DVWA	GET	200 HTML modulo di accesso
/dvwa/setup.php	Configurazione DVWA	GET	200 HTML (inizializzazione database al primo avvio)
/vampi/	VAmPI	GET	200 HTML (documentazione API)
/vampi/users/v1	API VAmPI	GET	200 JSON {"users":[...]}
/vampi/users/v1/register	API VAmPI	POST	200 JSON {"status":"success",...}
/vampi/users/v1/login	API VAmPI	POST	200 JSON {"auth_token":"...","status":"success"}
/httpbin/get	httpbin	GET	200 JSON con dettagli della richiesta
/httpbin/post	httpbin	POST	200 JSON con i dati inviati
/httpbin/headers	httpbin	GET	200 JSON {"headers":{...}}
/httpbin/status/:code	httpbin	GET	Restituisce il codice di stato HTTP specificato
/whoami/	whoami	GET	200 testo normale con hostname, IP, tutte le intestazioni
/csd-demo/	CSD Demo	GET	200 HTML modulo di pagamento con pannello di attacco
/csd-demo/dashboard	Vista attaccante CSD	GET	200 HTML con i dati esfiltrati
/csd-demo/health	Integrità CSD	GET	200 JSON {"status":"healthy","component":"csd-demo",...}
/csd-demo/exfil/log	Log esfiltrazione CSD	GET	200 array JSON dei dati acquisiti
/dvga/	GraphiQL DVGA	GET	200 HTML (GraphiQL IDE)
/dvga/graphql	API GraphQL DVGA	POST	200 JSON risposta GraphQL
/restaurant/	RESTaurant	GET	200 (reindirizzamento alla documentazione)
/restaurant/docs	Swagger RESTaurant	GET	200 HTML (Swagger UI FastAPI)
/restaurant/openapi.json	OpenAPI RESTaurant	GET	200 JSON specifiche OpenAPI
http://<PUBLIC_IP>:8888	crAPI	GET	200 HTML (SPA)
http://<PUBLIC_IP>:8888/identity/api/auth/signup	Registrazione crAPI	POST	200 JSON
http://<PUBLIC_IP>:8888/identity/api/auth/login	Accesso crAPI	POST	200 JSON {"token":"..."}

OWASP Juice Shop

Percorso	/juice-shop/
Immagine	bkimminich/juice-shop:latest
Istanze	4 (porte 3001-3004), sticky tramite hash $cookie_token, cache proxy (TTL 60 s)
Risorse	2 CPU / 1 GiB RAM per istanza
Framework	Node.js / Angular
Progetto	owasp.org/www-project-juice-shop

OWASP Juice Shop è l’applicazione web vulnerabile più moderna e attivamente mantenuta. Copre l’intero OWASP Top 10 con oltre 100 sfide in una realistica applicazione di e-commerce.

Scenari dimostrativi

Scenario	Categoria	Vettore di attacco
Bypass del login tramite SQL Injection	Firewall per applicazioni web (WAF)	' OR 1=1-- nel campo email di accesso
XSS riflesso	Firewall per applicazioni web (WAF), Difesa lato client	Iniezione di script tramite parametro di ricerca
XSS basato su DOM	Difesa lato client	Payload nel frammento URL
Autenticazione compromessa	Firewall per applicazioni web (WAF)	Attacco brute force al login, manipolazione JWT
Abuso API	Sicurezza API	Accesso non autorizzato agli endpoint /api/
Esposizione di dati sensibili	Sicurezza API	Accesso ai dati utente senza autorizzazione
CSRF	Firewall per applicazioni web (WAF)	Cross-site request forgery sulle modifiche al profilo

Accesso

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

DVWA (Damn Vulnerable Web Application)

Percorso	/dvwa/
Immagine	dvwa-fpm:latest personalizzata (php-fpm + nginx, costruita da ghcr.io/digininja/dvwa:latest)
Istanze	4 (porte 8101-8104), sticky tramite hash $cookie_PHPSESSID
Risorse	0,5 CPU / 256 MiB RAM per istanza
Database	MariaDB 10.11 condiviso (container dvwa-db, 1 CPU / 768 MiB)
Framework	PHP 8 / php-fpm / MariaDB
Credenziali	admin / password

DVWA è lo standard del settore per i test WAF. Dispone di livelli di sicurezza regolabili (Basso, Medio, Alto, Impossibile) che aggiungono progressivamente la validazione degli input e la codifica dell’output.

Scenari dimostrativi

Scenario	Categoria	Livello di sicurezza
SQL Injection	Firewall per applicazioni web (WAF)	Basso: banale ' OR 1=1#, Alto: SQLi cieco
Command Injection	Firewall per applicazioni web (WAF)	Basso: ; ls, Alto: caratteri filtrati
File Inclusion	Firewall per applicazioni web (WAF)	Basso: path traversal diretto, Alto: sanificato
XSS (Riflesso)	Firewall per applicazioni web (WAF), Difesa lato client	Basso: base <script>, Alto: bypass con codifica
XSS (Persistente)	Firewall per applicazioni web (WAF), Difesa lato client	Basso: script persistente nel guestbook
Caricamento file	Firewall per applicazioni web (WAF)	Basso: caricamento shell PHP, Alto: filtraggio estensioni
Brute Force	Difesa Bot standard	Tentativi di accesso automatizzati

Livelli di sicurezza

Impostare il livello di sicurezza su /dvwa/security.php dopo l’accesso:

• Basso — Nessuna validazione degli input. Ogni attacco funziona. Ideale per le dimostrazioni delle firme WAF.
• Medio — Filtraggio di base. Alcuni attacchi richiedono tecniche di codifica o bypass.
• Alto — Filtraggio robusto. Solo le tecniche avanzate hanno successo. Utile per mostrare i limiti del WAF.
• Impossibile — Implementazione completamente sicura. Dimostra una corretta codifica difensiva.

Configurazione iniziale

DVWA richiede una configurazione del database una tantum dopo la prima distribuzione:

1. Navigare su http://<PUBLIC_IP>/dvwa/setup.php
2. Fare clic su Create / Reset Database
3. Accedere con admin / password

VAmPI (Vulnerable API)

Percorso	/vampi/
Immagine	erev0s/vampi:latest con entrypoint gunicorn (4 worker)
Istanze	4 (porte 5101-5104), sticky tramite ip_hash (SQLite per istanza)
Risorse	0,5 CPU / 512 MiB RAM per istanza
Framework	Python / Flask / gunicorn
Progetto	github.com/erev0s/VAmPI

VAmPI è progettato appositamente per testare l’OWASP API Security Top 10. Fornisce una REST API realistica con vulnerabilità deliberate. Ogni istanza esegue gunicorn con 4 worker e il proprio database SQLite. La sessione sticky ip_hash garantisce che la registrazione e il login dallo stesso IP client raggiungano sempre la stessa istanza.

Scenari dimostrativi

Scenario	OWASP API Top 10	Metodo
Broken Object Level Authorization (BOLA)	API1	Accesso ai dati di altri utenti manipolando gli ID
Autenticazione compromessa	API2	Gestione debole dei token, nessun rate limiting
Esposizione eccessiva dei dati	API3	L’API restituisce più dati di quanti ne abbia bisogno il client
Mass Assignment	API6	Modifica dei campi admin tramite parametri inattesi
SQL Injection	API8	Iniezione tramite parametri API
Gestione impropria degli asset	API9	Endpoint API non documentati

Endpoint API

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

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

# Elenco utenti (esposizione eccessiva dei dati)
curl "http://<PUBLIC_IP>/vampi/users/v1"

httpbin

Percorso	/httpbin/
Immagine	kennethreitz/httpbin:latest con override CMD gunicorn (-w 4 -k gevent --timeout 30)
Istanze	4 (porte 8201-8204), round-robin (stateless)
Risorse	0,5 CPU / 256 MiB RAM per istanza
Framework	Python / Flask / gunicorn + gevent
Progetto	httpbin.org

httpbin è un semplice servizio HTTP di richiesta/risposta utile per demo API di base, test delle intestazioni di richiesta e verifica del comportamento del proxy.

Endpoint utili

Endpoint	Scopo
/httpbin/get	Restituisce i dati della richiesta GET (intestazioni, argomenti, origine)
/httpbin/post	Restituisce i dati della richiesta POST (corpo, form, JSON)
/httpbin/headers	Restituisce le intestazioni della richiesta
/httpbin/ip	Restituisce l’IP di origine
/httpbin/user-agent	Restituisce l’intestazione User-Agent
/httpbin/status/:code	Restituisce il codice di stato HTTP specificato
/httpbin/delay/:seconds	Ritarda la risposta di N secondi
/httpbin/anything	Restituisce qualsiasi cosa passata nella richiesta

Esempio

# Verificare quali intestazioni vede il server di origine (utile per verificare l'iniezione di intestazioni F5 XC)
curl -s "http://<PUBLIC_IP>/httpbin/headers" | jq .

# Testare un codice di stato HTTP specifico
curl -s -o /dev/null -w "%{http_code}" "http://<PUBLIC_IP>/httpbin/status/403"

whoami (Diagnostica delle richieste)

Percorso	/whoami/
Immagine	traefik/whoami:latest
Istanze	4 (porte 8082-8085), round-robin (stateless)
Risorse	0,25 CPU / 64 MiB RAM per istanza
Framework	Go
Progetto	github.com/traefik/whoami

whoami è il server echo HTTP leggero di Traefik. Visualizza ogni dettaglio della richiesta HTTP in entrata come la vede il server di origine — hostname, indirizzi IP, tutte le intestazioni, metodo e URL. Questo è lo strumento diagnostico più importante quando si verifica che F5 XC stia iniettando le intestazioni corrette.

Casi d’uso principali

Caso d’uso	Cosa cercare
Verificare l’iniezione di intestazioni F5 XC	Intestazioni X-Forwarded-For, True-Client-IP, X-Volterra-*
Confermare la visibilità dell’IP client	X-Real-IP vs RemoteAddr
Debug dei falsi positivi WAF	Confrontare le intestazioni di richiesta prima/dopo F5 XC
Validare il tagging della difesa bot	Intestazioni X-Volterra-Bot-Type, X-Volterra-Bot-Verified
Verificare la terminazione TLS	X-Forwarded-Proto mostra https quando TLS termina su F5 XC

Esempio

# Richiesta base -- vedere cosa riceve il server di origine
curl "http://<PUBLIC_IP>/whoami/"

# Simulare una richiesta tramite F5 XC (con intestazioni iniettate)
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"

Esempio di output:

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)

Percorso	/dvga/
Immagine	dolevf/dvga:latest
Istanze	4 (porte 5201-5204), sticky tramite ip_hash (SQLite per istanza)
Risorse	0,5 CPU / 256 MiB RAM per istanza
Framework	Python / Flask / GraphQL
Progetto	github.com/dolevf/Damn-Vulnerable-GraphQL-Application

DVGA è progettato appositamente per testare le vulnerabilità specifiche di GraphQL. Fornisce un GraphiQL IDE su /dvga/ per l’esplorazione interattiva delle query e un endpoint API GraphQL su /dvga/graphql. Ogni istanza utilizza il proprio database SQLite, quindi le sessioni sticky ip_hash garantiscono uno stato coerente.

Scenari dimostrativi

Scenario	Categoria	Vettore di attacco
GraphQL Injection	Sicurezza API	Query dannose tramite interpolazione di stringhe
Denial of Service	Sicurezza API	Query profondamente annidate, query in batch, esaurimento delle risorse
Bypass dell’autorizzazione	Sicurezza API	Accesso a dati non autorizzati tramite GraphQL
Divulgazione di informazioni	Sicurezza API	Query di introspezione che rivelano i dettagli dello schema
Attacco di batching	Sicurezza API	Operazioni multiple in una singola richiesta

Endpoint principali

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

# Query di introspezione -- enumerare lo schema completo
curl -s "http://<PUBLIC_IP>/dvga/graphql" \
  -H "Content-Type: application/json" \
  -d '{"query":"{ __schema { types { name fields { name } } } }"}'

# Elenco paste (query di esempio)
curl -s "http://<PUBLIC_IP>/dvga/graphql" \
  -H "Content-Type: application/json" \
  -d '{"query":"{ pastes { title content } }"}'

# Creare una paste (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)

Percorso	/restaurant/
Immagine	Build personalizzata da theowni/Damn-Vulnerable-RESTaurant-API-Game
Istanze	4 (porte 8301-8304), round-robin (PostgreSQL condiviso)
Risorse	0,5 CPU / 256 MiB RAM per istanza
Database	PostgreSQL 15.4 condiviso (container restaurant-db, 0,5 CPU / 512 MiB)
Framework	Python / FastAPI / PostgreSQL
Credenziali	admin / password (PostgreSQL)
Progetto	github.com/theowni/Damn-Vulnerable-RESTaurant-API-Game

RESTaurant è una REST API vulnerabile e gamificata che copre l’OWASP API Security Top 10 2023. Utilizza FastAPI con documentazione Swagger UI automatica su /restaurant/docs. Tutte le 4 istanze condividono un singolo database PostgreSQL, quindi il bilanciamento del carico round-robin funziona senza sessioni sticky.

Scenari dimostrativi

Scenario	OWASP API Top 10 2023	Metodo
Broken Object Level Authorization (BOLA)	API1	Accesso agli ordini di altri utenti manipolando gli ID
Autenticazione compromessa	API2	Gestione debole dei token, credential stuffing
Broken Object Property Level Authorization	API3	Mass assignment sui campi del profilo utente
Consumo illimitato di risorse	API4	Nessun rate limiting sugli endpoint
Broken Function Level Authorization (BFLA)	API5	Accesso agli endpoint admin come utente normale
Server Side Request Forgery (SSRF)	API7	Manipolazione delle richieste URL lato server
Configurazione errata della sicurezza	API8	Messaggi di errore dettagliati, credenziali predefinite

Endpoint principali

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

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

# BOLA -- accedere all'ordine di un altro utente (dopo l'autenticazione)
curl -s "http://<PUBLIC_IP>/restaurant/orders/1" \
  -H "Authorization: Bearer <token>"

# BFLA -- tentare un'azione admin come utente normale
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)

Porta	8888 (dedicata — senza prefisso di percorso)
Immagini	crapi/crapi-web, crapi/crapi-identity, crapi/crapi-community, crapi/crapi-workshop, PostgreSQL, MongoDB, MailHog
Istanze	7 microservizi (singola istanza ciascuno)
Risorse	~3,0 CPU / ~2,0 GiB RAM totali
Framework	React SPA + microservizi Java/Go/Python
Progetto	github.com/OWASP/crAPI

crAPI è il progetto principale OWASP per i test di sicurezza delle API. Viene eseguito come 7 microservizi su una porta dedicata (8888) perché la React SPA codifica i propri percorsi API e non può essere servita dietro un prefisso di percorso. Il NSG consente il traffico in entrata sulla porta 8888.

MailHog acquisisce tutte le email inviate da crAPI (verifica account, reimpostazione password). Accedere a MailHog tramite tunnel SSH sulla porta 18025.

Categorie di sfide

Categoria	Vulnerabilità
BOLA (Broken Object Level Authorization)	Accesso ai veicoli, ordini e report di altri utenti
BFLA (Broken Function Level Authorization)	Escalation ad admin, accesso agli endpoint con restrizioni
Mass Assignment	Modifica dei campi protetti (ruolo, saldo) tramite API
SSRF (Server Side Request Forgery)	Manipolazione del recupero URL lato server
Manipolazione JWT	Falsificazione o modifica dei token JWT per l’escalation dei privilegi
NoSQL Injection	Iniezione di query negli endpoint basati su MongoDB
Esposizione eccessiva dei dati	L’API restituisce dati utente sensibili

Per iniziare

# Verificare che crAPI sia in esecuzione
curl -sf "http://<PUBLIC_IP>:8888" -o /dev/null -w "%{http_code}"

# Registrare un nuovo utente
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!"}'

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

# Accedere a MailHog (tramite tunnel SSH per la verifica email)
# ssh -L 18025:localhost:18025 azureuser@<PUBLIC_IP>
# Quindi aprire http://localhost:18025 nel browser

Architettura crAPI

Port 8888 -> crapi-web (React SPA + nginx)
             -> crapi-identity (Java, user auth, JWT)
             -> crapi-community (Go, forums, posts)
             -> crapi-workshop (Python, vehicle service)
             -> crapi-postgres (PostgreSQL)
             -> crapi-mongo (MongoDB)
             -> crapi-mailhog (email capture, port 18025)

Matrice di copertura delle applicazioni

Caso d’uso dimostrativo	App principale	App secondaria
WAF — SQL Injection	DVWA	Juice Shop
WAF — XSS	DVWA	Juice Shop
WAF — Command Injection	DVWA	—
Sicurezza API — BOLA	VAmPI	—
Sicurezza API — Bypass autenticazione	VAmPI	Juice Shop
Sicurezza API — Esposizione dati	VAmPI	httpbin
Difesa Bot — Brute force	DVWA	Juice Shop
Difesa Bot — Scraping	Juice Shop	—
Difesa lato client — DOM XSS	Juice Shop	—
Difesa lato client — XSS persistente	DVWA	Juice Shop
Difesa lato client — Card Skimmer	CSD Demo	—
Difesa lato client — Formjacker	CSD Demo	—
Difesa lato client — Keylogger	CSD Demo	—
Difesa lato client — Cryptominer	CSD Demo	—
Difesa lato client — DOM Hijack	CSD Demo	—
Sicurezza API — GraphQL injection	DVGA	—
Sicurezza API — GraphQL DoS	DVGA	—
Sicurezza API — OWASP API Top 10 2023	RESTaurant	crAPI
Sicurezza API — BFLA	RESTaurant	crAPI
Sicurezza API — Mass assignment	crAPI	RESTaurant
Sicurezza API — SSRF	crAPI	RESTaurant
Sicurezza API — Manipolazione JWT	crAPI	—
Sicurezza API — NoSQL injection	crAPI	—
Test di connettività di base	httpbin	—
Diagnostica delle richieste	whoami	httpbin
Verifica dell’iniezione di intestazioni	whoami	—