TLDR

  • DVWA e OWASP Juice Shop sono due applicazioni web volutamente vulnerabili: la palestra giusta per imparare gli attacchi web con i comandi, senza toccare siti di altri.
  • La SQL injection resta la madre di tutti i bug web: un input non filtrato che finisce dentro una query e ti fa parlare direttamente col database.
  • L'upload di file è l'altro grande classico: se il server accetta qualsiasi file senza controllarlo, un attaccante carica codice ed esegue comandi.
  • Ogni tecnica si chiude con la difesa: query parametrizzate contro la SQL injection, validazione rigida contro gli upload. Sono le stesse contromisure che servono su un e-commerce reale.

Perché conta ora

Dopo aver bucato una macchina intera, il web sembra più innocuo. Non lo è: è dove avvengono la maggior parte degli attacchi reali, perché è l'unica porta che ogni azienda tiene aperta per forza.

Per imparare gli attacchi web servono bersagli che ti autorizzano. Ce ne sono due che sono lo standard:

  • DVWA (Damn Vulnerable Web Application): una web app volutamente vulnerabile, con un interruttore di sicurezza a livelli. Puoi attaccare lo stesso bug in modalità "low" e poi vedere perché in "high" non funziona più. È la palestra didattica per eccellenza.
  • OWASP Juice Shop: un finto e-commerce moderno, pieno di sfide, costruito da OWASP. Più vicino a un'applicazione reale di oggi.

Le installi nel laboratorio isolato (anche in un container, come visto nella guida al lab) e le attacchi quanto vuoi. Promemoria che vale per tutto l'articolo: questi bersagli sono tuoi e fatti apposta. Gli stessi comandi su un sito di terzi, senza permesso scritto, sono reato.

Attacco 1: SQL injection, parlare col database

La SQL injection nasce da un errore preciso: un input dell'utente finisce dentro una query SQL senza essere separato dai comandi. Il database non distingue più i tuoi dati dalle istruzioni, e tu puoi fargli dire cose che non dovrebbe.

Su DVWA, nella pagina "SQL Injection" a livello low, c'è un campo che chiede un ID utente. Dietro le quinte il codice costruisce una query concatenando quello che scrivi. Provi un input che non è un ID ma un pezzo di logica:

1' OR '1'='1

La query diventa sempre vera e l'applicazione, invece di un utente, te li restituisce tutti. Questo è il segnale che l'input finisce grezzo nella query: da qui, allungando la tecnica, si arriva a estrarre nomi di tabelle, colonne e contenuti.

In laboratorio puoi lasciare che sia sqlmap a percorrere tutta la strada. Preso l'URL vulnerabile e il cookie di sessione da DVWA:

sqlmap -u "http://TARGET/vulnerabilities/sqli/?id=1&Submit=Submit" \
  --cookie="PHPSESSID=...; security=low" --batch

sqlmap conferma l'iniezione e, se glielo chiedi, enumera database, tabelle e dati. Vederlo lavorare è il modo migliore per capire quanto in profondità arriva un singolo campo lasciato scoperto.

Ora alza il livello di DVWA a high e riprova: lo stesso input non funziona più. Guardando il codice scopri perché — la query è scritta in modo diverso, con i parametri separati dai dati. È la differenza tra codice vulnerabile e codice sano, mostrata dal vivo.

Attacco 2: upload, far eseguire il tuo codice

Il secondo grande classico è l'upload di file. L'idea: se un sito ti lascia caricare un file e poi lo salva in un punto da cui il server può eseguirlo, e non controlla cosa c'è dentro, quel file diventa codice che gira sul server.

Su DVWA, nella pagina "File Upload" a livello low, puoi caricare praticamente qualsiasi cosa. Un piccolo file di script lato server, una volta caricato, è raggiungibile come una normale pagina: aprendolo, viene eseguito dal server invece di essere mostrato. Da lì un attaccante arriva a lanciare comandi sulla macchina.

Il punto didattico è cosa cambia salendo di livello:

  • a livello medium, DVWA controlla il tipo dichiarato del file — aggirabile, ma già un ostacolo;
  • a livello high, controlla l'estensione reale e il contenuto, e l'attacco banale non passa più.

È la stessa scala che ritrovi nel mondo reale: un upload senza controlli è una porta spalancata, un upload validato bene è chiuso.

Burp Suite: vedere cosa viaggia

Per molti attacchi web il tuo strumento principale non è uno scanner, è un proxy. Burp Suite, già dentro Kali, si mette tra il browser e l'applicazione e ti fa vedere e modificare ogni richiesta.

Configuri il browser per passare da Burp, e all'improvviso vedi la richiesta grezza che parte quando premi "invia": i parametri, i cookie, gli header. Puoi fermarla, cambiarla e inoltrarla. Metà degli attacchi web si capiscono solo quando smetti di guardare la pagina e inizi a guardare la richiesta. Juice Shop, con le sue sfide, è il posto giusto per prenderci la mano.

La lettura difensiva

Hai attaccato due bug che, non per caso, sono gli stessi che colpiscono gli e-commerce veri. Ecco come si chiudono — ed è la parte che conta di più se un sito lo gestisci davvero:

Contro la SQL injection:

  • query parametrizzate ovunque: i dati dell'utente viaggiano separati dai comandi SQL, e il database non li confonde mai. È la differenza che hai visto tra DVWA low e high.
  • validazione e normalizzazione degli input, come secondo strato.
  • privilegi minimi per l'utente del database: anche se qualcuno inietta, trova poco.

Contro gli upload malevoli:

  • salva i file caricati fuori dalla web root, in un punto da cui il server non li esegue;
  • controlla tipo reale ed estensione, non quello che dichiara l'utente;
  • rinomina i file e non fidarti mai del nome originale.

Come rete di sicurezza: un Web Application Firewall davanti all'applicazione e il monitoraggio delle richieste anomale. Non sostituiscono il codice scritto bene, ma fermano gli attacchi più rumorosi.

Chi gestisce un e-commerce su WordPress, PrestaShop o un gestionale custom ritrova esattamente questi due rischi. Averli visti funzionare in palestra è il modo migliore per non lasciarli aperti in produzione.

La cosa da ricordare

SQL injection e upload non controllati sono vecchi di vent'anni e continuano a mandare offline siti veri, perché basta un punto del codice scritto male. In palestra li impari attaccandoli; in produzione li eviti scrivendo il codice nel modo che hai visto chiudere il bug a livello "high".

Se vuoi la metodologia completa di un pentest, dalla ricognizione al report, continua con Metasploitable 2: dalla scansione al primo root. Per il lato CSP e difese del browser, CSP senza rompere il sito mostra l'altra metà del lavoro.

FAQ

Che differenza c'è tra DVWA e Juice Shop?

DVWA è una web app PHP classica, con livelli di sicurezza regolabili (low, medium, high): perfetta per vedere come la stessa vulnerabilità si chiude passo dopo passo. Juice Shop è moderna, in JavaScript, costruita come una serie di sfide: ottima per allenarsi su bug più attuali.

Posso usare sqlmap su DVWA?

Sì, in laboratorio è l'ideale: DVWA è tua e pensata per essere attaccata. sqlmap automatizza la SQL injection e ti fa vedere fin dove può arrivare. Lanciarlo su un sito di terzi senza autorizzazione, invece, è un reato.

La SQL injection non è un problema vecchio?

È vecchia e risolta da vent'anni, eppure continua a comparire perché basta un punto del codice che concatena un input in una query. Impararla in palestra è il modo migliore per riconoscerla, e per non scriverla, nel codice vero.

Perché l'upload di file è pericoloso?

Perché se il server salva un file caricato in una cartella da cui può essere eseguito, e non controlla cosa contiene, quel file diventa codice che gira sul server. Da lì all'esecuzione di comandi il passo è breve.

Come proteggo un e-commerce reale da questi attacchi?

Query parametrizzate ovunque, validazione e normalizzazione di ogni input, upload salvati fuori dalla web root e controllati per tipo e contenuto, e un Web Application Firewall come rete di sicurezza. Il paragrafo finale entra nel dettaglio.

Fonti