Vulnerabilità delle Applicazioni Web: Mappatura delle Categorie di Attacco DVWA | Fondamenti di Test di Sicurezza Etico con Python: Una Guida Pratica per Principianti

Debolezze delle Applicazioni Web: Mappatura delle Categorie di Attacco DVWA

Il server DVWA del Lab Wintermute all'indirizzo 192.0.2.30 è il luogo in cui i concetti astratti delle pagine precedenti diventano tangibili. Dopo aver costruito la nostra base Python e aver configurato la rete isolata, esaminiamo ora come il codice deliberatamente vulnerabile insegna il pensiero difensivo. DVWA—verificare l'ultima release sul repository GitHub di digininja—offre quattro livelli di sicurezza che fungono da impalcatura didattica: Low (nessuna protezione), Medium (difese naive), High (barriere più sofisticate) e Impossible (come appare effettivamente un'implementazione sicura). Li tratto come lenti progressive, non come impostazioni di difficoltà. Uno studente che si affretta a sfruttare Low senza studiare Impossible impara a rompere le cose, non a costruirle o difenderle.

SQL Injection: Quando l'Input Diventa Codice

La vulnerabilità che si rifiuta di morire. L'SQL injection (injection di Structured Query Language, in cui l'input controllato dall'attaccante altera le query del database) rimane comune perché gli sviluppatori continuano a concatenare stringhe invece di separare il codice dai dati.

Nel livello di sicurezza Low di DVWA, il campo "User ID" nella pagina SQL Injection accetta input grezzo direttamente in una query. Concettualmente: l'applicazione costruisce SELECT first_name, last_name FROM users WHERE user_id = '$id' inserendo il tuo input nello slot $id. Invia 1 e ottieni un nome. Invia 1' OR '1'='1 e la query diventa ...WHERE user_id = '1' OR '1'='1'—sempre vera, restituendo tutte le righe. Il database non può distinguere tra codice e dati perché lo sviluppatore non ha distinto lui per primo.

È qui che il nostro lavoro con Python porta i suoi frutti. Dalla workstation Kali all'indirizzo 192.0.2.10, automatizziamo il rilevamento con requests, basandoci sui pattern sintattici stabiliti nelle Pagine 1-2:

#!/usr/bin/env python3
# sqli_probe.py — conceptual probe for DVWA SQLi at Low security
# Run only against authorized lab targets. Snapshot before testing. import requests TARGET = "http://192.0.2.30/dvwa/vulnerabilities/sqli/"
# DVWA requires authentication; session cookie from browser login
COOKIES = {"PHPSESSID": "your_session_here", "security": "low"} # Probe: classic tautology test that should return extra rows
# if input is concatenated unsafely into the query
payload = {"id": "1' OR '1'='1", "Submit": "Submit"} r = requests.get(TARGET, params=payload, cookies=COOKIES)
print(f"Status: {r.status_code}")
print(f"Length: {len(r.text)}")
# illustrative output — verify on your target
# Length: 3847 (vs ~1200 for benign '1' query suggests data leak)

Perché questo è importante: La differenza di lunghezza è il tuo primo segnale. Una query benigna restituisce un record; la tautologia ne restituisce molteplici. Questa è ricognizione, non sfruttamento—mappiamo l'esistenza della vulnerabilità senza estrarre dati sensibili. Il confine etico risiede in ciò che fai con l'accesso confermato, non nella conferma stessa.

Il livello Medium aggiunge mysql_real_escape_string() o simili, che gli studenti spesso aggirano con input numerici dove non sono necessarie le virgolette: 1 OR 1=1. Il livello High può usare preg_replace per rimuovere le keyword—un approccio fragile che fallisce contro varianti codificate. Il livello Impossible dimostra le query parametrizzate (prepared statements con binding delle variabili), la difesa primaria raccomandata contro l'SQL injection. Lo sviluppatore definisce prima tutta la logica SQL: SELECT first_name, last_name FROM users WHERE user_id = ?, poi lega il parametro separatamente. Il database tratta l'input esclusivamente come dati, mai come codice eseguibile. Le stored procedure possono aiutare ma richiedono un'implementazione altrettanto sicura; non sono automaticamente protettive.

Cross-Site Scripting: Fidarsi Troppo del Browser

XSS (Cross-Site Scripting, in cui script dell'attaccante si eseguono nel browser della vittima nel contesto del sito target) sfrutta l'incapacità del browser di distinguere il codice legittimo della pagina dal markup iniettato. DVWA dimostra due varianti.

XSS Riflesso: input malevolo appare nella risposta immediata. Nel livello Low, il campo "Name" in XSS (Reflected) rispecchia il tuo input direttamente nella pagina. Invia <script>alert('xss')</script> e il browser lo esegue. Lo script "rimbalza" sul server una sola volta. Pericoloso per il phishing: un attaccante crea un link con il payload codificato, lo invia a una vittima e raccoglie i cookie di sessione se il sito manca di header protettivi.

XSS Persistente: il payload persiste nel database e si esegue per ogni visitatore. La pagina XSS (Stored) di DVWA—un input in stile guestbook—accetta lo stesso tag script. Ora l'attacco sopravvive alla sessione originale, colpendo gli amministratori che in seguito rivedono le voci. Il rischio di hijacking della sessione emerge perché i browser inviano i cookie automaticamente; uno script che legge document.cookie e lo esfiltra verso un server controllato dall'attaccante compromette i token di autenticazione.

Qui contano gli strati di difesa. La validazione degli input aiuta ma la codifica sensibile al contesto è essenziale—il contesto JavaScript richiede escaping diverso dall'HTML. L'header di risposta Content-Security-Policy, consegnato al browser per imporre una CSP, imposta direttive come default-src e img-src per controllare le fonti valide per le risorse. Una distribuzione di base: Content-Security-Policy: default-src 'self'; script-src 'self'. Questo impedisce completamente l'esecuzione di script inline, neutralizzando sia le varianti riflesse che quelle persistenti. La variante Content-Security-Policy-Report-Only supporta il monitoraggio delle violazioni senza bloccare—utile durante i test di distribuzione, con report-to preferito rispetto al deprecato report-uri per la segnalazione delle violazioni.

⚠️ Solo uso autorizzato e difensivo.

# Verify CSP presence on a target (lab only)
curl -I http://192.0.2.30/dvwa/ 2>/dev/null | grep -i content-security
# illustrative output — verify on your target
# Content-Security-Policy: default-src 'self'

In termini semplici: CSP dice al browser "esegui solo script da questi indirizzi approvati," quindi anche se un attaccante inietta tag script, il browser rifiuta di eseguirli.

Command Injection: Il Collasso del Confine del SO

La command injection si verifica quando l'input dell'applicazione raggiunge la shell del sistema operativo. La pagina Command Injection di DVWA nel livello Low passa il campo "IP address" direttamente a ping. Inserisci 192.0.2.1 e il server esegue ping -c 4 192.0.2.1. Inserisci 192.0.2.1; cat /etc/passwd e il punto e virgola termina il comando ping, avviandone un secondo. L'applicazione intendeva diagnostica di rete; l'attaccante ha ottenuto l'esecuzione arbitraria di comandi.

Il meccanismo è ancora la concatenazione—input incollato al codice. Il livello Medium filtra && e ; ma spesso manca il pipe | o i backtick. Il livello High usa filtraggio più esteso, ancora vulnerabile a aggiramenti creativi. Il livello Impossible usa ip_check() con validazione rigorosa o, meglio ancora, evita del tutto l'invocazione della shell—chiamando le funzioni di rete interne di PHP o il subprocess di Python con liste di argomenti che impediscono l'interpretazione della shell.

Perché questo è importante: Il punto e virgola non è magico. La shell lo interpreta come terminazione del comando perché l'applicazione ha passato l'input dell'utente a un interprete shell. La soluzione non è "filtrare i punti e virgola" ma "non passare mai l'input dell'utente a una shell." L'allowlist—permettendo solo caratteri attesi (cifre, punti per gli indirizzi IP)—fornisce difesa in profondità quando la separazione architetturale non è immediatamente realizzabile.

File Inclusion: Quando i Percorsi Vagano

Le vulnerabilità di file inclusion permettono agli attaccanti di manipolare i percorsi dei file per accedere a risorse non previste. Le pagine File Inclusion di DVWA dimostrano questo attraverso parametri di pagina come ?page=include.php. Nel livello Low, sostituire ?page=/etc/passwd ha successo se l'applicazione concatena o utilizza direttamente il parametro senza restrizioni di percorso.

Il path traversal (directory traversal, usando sequenze ../ per sfuggire alle directory previste) estende questo: ?page=../../../etc/passwd risale il filesystem. La meccanica dipende dalla canonizzazione insufficiente del percorso—il server risolve i percorsi relativi rispetto all'input dell'attaccante anziché imporre una directory base.

I livelli Medium e High aggiungono filtri naive: rimuovendo ../, che ....// aggira; o richiedendo prefissi file://, che non limitano la posizione. Il livello Impossible usa una canonizzazione rigorosa del percorso (risolvendo in percorsi assoluti e verificando che rimangano entro una directory base consentita) o, più robustamente, mappando i file consentiti attraverso un allowlist esplicito piuttosto che una costruzione dinamica del percorso.

Brute Force dell'Autenticazione: La Pazienza come Attacco

La pagina Brute Force di DVWA presenta un modulo di login vulnerabile al guessing automatizzato nel livello Low. Il valore pedagogico risiede nella comprensione degli attacchi basati sulla frequenza e delle loro contromisure, non nella raccolta delle credenziali.

Dalla nostra workstation Kali, potremmo integrare Hydra per il testing sistematico contro il target autorizzato del lab:

# Hydra against DVWA login — LAB AUTHORIZED TARGET ONLY
# -l single username, -P password list, http-post-form module
# syntax: path:postdata:success/failure condition string hydra -l admin -P /usr/share/wordlists/rockyou.txt \ 192.0.2.30 http-post-form \ "/dvwa/vulnerabilities/brute/:username=^USER^&password=^PASS^&Login=Login:Username and/or password incorrect."

⚠️ Solo uso autorizzato e difensivo.

Il livello Medium aggiunge un ritardo sleep(2)—naive, aggirabile con pazienza. Il livello High può introdurre CAPTCHA o tracciare i tentativi per sessione. Il livello Impossible implementa il blocco dell'account dopo un numero definito di fallimenti e, criticamente, l'autenticazione a più fattori (MFA, richiedendo un secondo fattore di verifica oltre alla password). Anche con credenziali corrette, l'attaccante manca del secondo fattore generato in base al tempo o hardware.

La progressione difensiva conta più dell'attacco: il blocco impedisce il guessing automatizzato; l'MFA impedisce completamente il riutilizzo delle credenziali. In produzione, implementa entrambi—blocco con attenzione per evitare denial-of-service contro utenti legittimi, MFA con meccanismi di recupero che non diventino percorsi di attacco alternativi.

Documentazione per il Rapporto di Apprendimento

L'obiettivo dell'engagement del Lab Wintermute è la comprensione, non il compromesso. Per ogni categoria DVWA all'indirizzo 192.0.2.30, il tuo rapporto dovrebbe catturare: il livello di sicurezza testato, il meccanismo concettuale della vulnerabilità, il tuo approccio di rilevamento basato su Python o strumenti, il controllo difensivo dimostrato al livello Impossible, e perché quel controllo ha successo dove le varianti più deboli falliscono. Il rollback delle snapshot tra le categorie garantisce uno stato pulito; l'isolamento della rete a livello NAT di VirtualBox garantisce nessuna raggiungibilità esterna accidentale.

Le tecniche di questa pagina—ricognizione di rete con Python, mappatura delle vulnerabilità web, analisi dei controlli difensivi—alimentano direttamente la simulazione consolidata trattata successivamente. I pattern che tracci sul codice deliberatamente rotto di DVWA sono gli stessi pattern che riconoscerai nelle code review di produzione, nei programmi bug bounty e nell'incident response. La differenza è l'autorizzazione, lo scope e l'intento.