Vulnerabilità web: SQL Injection, XSS, CSRF, DDoS, MITM e zero-day spiegati semplice

Quando usiamo un sito web, spesso vediamo soltanto la parte più semplice: una pagina che si apre, un modulo di login, un pulsante da premere, un carrello, un’area riservata, una barra di ricerca.

Dietro quella semplicità, però, c’è un’applicazione che riceve dati, li elabora, parla con un database, mantiene sessioni utente, espone URL, gestisce richieste HTTP, comunica con altri servizi e mostra contenuti dinamici nel browser.

Ed è proprio in questi passaggi che possono nascere le vulnerabilità web.

La sicurezza delle applicazioni web non riguarda solo chi sviluppa software. Riguarda anche aziende, amministratori di sistema, professionisti IT e utenti finali, perché molte delle attività quotidiane passano ormai da servizi online: home banking, e-commerce, posta elettronica, gestionali, piattaforme cloud, social network, servizi della pubblica amministrazione e applicazioni aziendali.

In questo articolo mettiamo ordine tra alcune delle minacce più importanti: SQL Injection, Cross-Site Scripting, Cross-Site Request Forgery, Man-in-the-Middle, DDoS e vulnerabilità zero-day. Sono attacchi diversi tra loro, ma hanno un punto in comune: sfruttano una fiducia mal gestita.

Un’applicazione si fida troppo dell’input dell’utente. Un browser si fida troppo del contenuto che riceve. Un server si fida troppo di una richiesta autenticata. Un utente si fida troppo della rete a cui è collegato. Un’infrastruttura si fida troppo della propria capacità di reggere il traffico. Un’organizzazione si fida troppo del fatto che ciò che non conosce non possa colpirla.

La sicurezza web serve proprio a ridurre questa fiducia implicita e a sostituirla con controlli, verifiche, isolamento, monitoraggio e aggiornamenti continui.

Perché le vulnerabilità web sono così importanti

Le applicazioni web sono diventate il punto di accesso principale a dati, servizi e processi aziendali. Un tempo molti sistemi erano usati solo all’interno di una rete locale. Oggi, invece, moltissime applicazioni sono esposte su Internet o comunque accessibili da browser, API, app mobili e servizi cloud.

Questo rende il web un bersaglio naturale.

Una vulnerabilità web può permettere a un attaccante di leggere dati riservati, modificare informazioni, rubare sessioni, eseguire azioni a nome di un utente, intercettare comunicazioni, rendere un servizio indisponibile o sfruttare una falla ancora sconosciuta.

Il problema non è solo tecnico. Una violazione può causare perdita di fiducia, danni economici, interruzioni operative, obblighi di notifica, sanzioni e danni reputazionali. Se un sito gestisce dati personali, pagamenti, credenziali o informazioni aziendali, la sicurezza non è un dettaglio: è parte essenziale del servizio.

Per questo la sicurezza web deve essere considerata fin dall’inizio del progetto, non come una verifica da fare solo alla fine.

SQL Injection: quando l’input diventa comando

La SQL Injection è una delle vulnerabilità web più note e pericolose. Nasce quando un’applicazione usa dati inseriti dall’utente per costruire una query SQL senza separarli correttamente dal comando.

In termini semplici, l’utente dovrebbe poter fornire solo dati: un nome, una password, un termine di ricerca, un identificativo. Se però l’applicazione concatena direttamente quell’input dentro una query, un attaccante può provare a inserire frammenti di SQL per modificare il comportamento della richiesta.

Il problema fondamentale è questo: il dato non viene più trattato come dato, ma viene interpretato come parte del comando.

Immaginiamo un modulo di login. L’applicazione riceve username e password e li usa per interrogare il database. Se il codice è scritto male, un attaccante può inserire un valore costruito appositamente per alterare la logica della query e tentare di bypassare il controllo.

Le conseguenze possono essere molto gravi. Una SQL Injection può permettere di leggere dati sensibili, estrarre tabelle, modificare informazioni, eliminare record o in alcuni casi ottenere un controllo più ampio sul sistema.

La difesa principale è nota da tempo: usare query preparate e parametrizzate. In questo modo il comando SQL e i dati dell’utente restano separati. L’input non può cambiare la struttura della query, perché viene trattato come valore e non come codice.

A questo si aggiungono altre buone pratiche: validazione dell’input, uso corretto degli ORM, gestione dei privilegi minimi sul database, logging, monitoraggio e test di sicurezza periodici. La SQL Injection è famosa, ma proprio per questo non dovrebbe più essere presente in applicazioni moderne progettate con attenzione.

XSS: quando il browser esegue codice malevolo

Il Cross-Site Scripting, spesso abbreviato in XSS, è una vulnerabilità che permette a un attaccante di inserire codice malevolo in una pagina web, facendo in modo che venga eseguito nel browser dell’utente.

Qui il bersaglio non è direttamente il database, ma il rapporto tra applicazione, contenuto e browser.

Un’applicazione web moderna mostra spesso dati dinamici: commenti, messaggi, profili, risultati di ricerca, notifiche, post, descrizioni, contenuti generati dagli utenti. Se questi dati non vengono gestiti correttamente, un attaccante può provare a inserire codice JavaScript che verrà poi interpretato dal browser come parte legittima della pagina.

Le conseguenze possono essere diverse: furto di cookie di sessione, manipolazione della pagina, esecuzione di azioni a nome dell’utente, reindirizzamenti verso siti malevoli o raccolta di informazioni sensibili.

Esistono varie forme di XSS. Nel Reflected XSS, il codice malevolo viene inserito in una richiesta e riflesso immediatamente nella risposta. Nel Stored XSS, il codice viene memorizzato sul server, per esempio in un commento o in un campo del profilo, e colpisce tutti gli utenti che visualizzano quella pagina. Nel DOM-based XSS, la vulnerabilità nasce nel modo in cui il codice lato client modifica dinamicamente la pagina nel browser.

La difesa passa da concetti fondamentali: escaping dell’output, sanitizzazione dei contenuti, validazione degli input e uso di una Content Security Policy ben configurata. L’idea è impedire che dati non affidabili vengano interpretati come codice eseguibile.

XSS è un buon esempio di una regola generale della sicurezza web: non basta controllare cosa entra nell’applicazione. Bisogna controllare anche come quel dato viene mostrato.

CSRF: quando una sessione autenticata viene sfruttata

Il Cross-Site Request Forgery, o CSRF, è un attacco meno intuitivo rispetto a SQL Injection e XSS, ma molto importante.

In un attacco CSRF, l’attaccante non cerca necessariamente di rubare la password dell’utente. Cerca invece di sfruttare il fatto che l’utente è già autenticato su un sito.

Immaginiamo un utente collegato al proprio account su un’applicazione web. Il browser conserva cookie di sessione che permettono al server di riconoscerlo. Se l’applicazione non verifica correttamente l’origine e la legittimità delle richieste, un attaccante può indurre il browser dell’utente a inviare una richiesta indesiderata.

L’utente potrebbe cliccare un link, aprire una pagina o visualizzare un contenuto che genera una richiesta verso il sito su cui è già autenticato. Dal punto di vista del server, la richiesta sembra provenire dall’utente legittimo, perché include i suoi cookie di sessione. Ma in realtà l’azione è stata forzata dall’esterno.

Il rischio è particolarmente grave quando la richiesta modifica dati: cambio email, cambio password, modifica impostazioni, esecuzione di operazioni sensibili o trasferimenti.

La difesa classica è l’uso di token anti-CSRF, valori unici e non prevedibili associati alla sessione o alla singola richiesta. Il server accetta l’operazione solo se il token è presente e corretto. A questo si aggiungono attributi di sicurezza dei cookie, controlli su metodo HTTP, verifica dell’origine e uso di framework moderni che integrano protezioni predefinite.

CSRF ci ricorda un punto essenziale: una richiesta autenticata non è automaticamente una richiesta voluta dall’utente.

La difesa delle applicazioni web

SQL Injection, XSS e CSRF sono attacchi diversi, ma indicano tutti la stessa direzione: un’applicazione sicura deve controllare con attenzione ciò che riceve, ciò che elabora, ciò che mostra e ciò che accetta come richiesta valida.

La prima difesa è la validazione dell’input. Ogni dato proveniente dall’esterno deve essere controllato rispetto a ciò che ci aspettiamo. Se un campo deve contenere un numero, non dovrebbe accettare testo libero. Se un campo deve contenere un indirizzo email, deve rispettare un formato coerente. Se un parametro deve appartenere a un insieme limitato di valori, tutto il resto va rifiutato.

La seconda difesa è la corretta gestione dell’output. I dati mostrati nel browser devono essere codificati in modo sicuro, così da non diventare codice eseguibile.

La terza difesa è l’uso di meccanismi robusti offerti da framework e librerie mature: ORM, query parametrizzate, sistemi di template con escaping automatico, gestione sicura delle sessioni, middleware anti-CSRF.

La quarta difesa è il principio del privilegio minimo. L’applicazione, il database, gli utenti e i servizi dovrebbero avere solo i permessi necessari. Se qualcosa viene compromesso, il danno deve essere contenuto.

Infine ci sono logging, monitoraggio, test automatici, analisi di vulnerabilità, penetration test, code review e strumenti come i Web Application Firewall. Un WAF non sostituisce il codice sicuro, ma può aiutare a filtrare richieste sospette e ridurre il rischio.

La sicurezza web non è un singolo controllo. È un insieme di pratiche coerenti.

Man-in-the-Middle: quando il problema è la comunicazione

Finora abbiamo parlato soprattutto dell’applicazione. Ma un’applicazione web comunica attraverso la rete. I dati viaggiano tra browser e server passando per router, DNS, Wi-Fi, proxy, infrastrutture cloud e provider.

Un attacco Man-in-the-Middle, o MITM, avviene quando un attaccante riesce a inserirsi nel mezzo della comunicazione tra due soggetti che credono di comunicare direttamente.

L’attaccante può limitarsi ad ascoltare il traffico, raccogliendo dati sensibili, oppure può manipolarlo attivamente. In questo secondo caso può alterare risposte, reindirizzare l’utente verso siti falsi, modificare contenuti o tentare di degradare una connessione sicura.

Gli scenari più comuni riguardano reti Wi-Fi pubbliche non sicure, hotspot falsi, ARP spoofing nelle reti locali, DNS spoofing e attacchi che cercano di forzare l’uso di HTTP al posto di HTTPS.

La difesa passa prima di tutto da HTTPS e dai certificati TLS. Quando una connessione è correttamente cifrata e autenticata, intercettare o modificare i dati diventa molto più difficile. Ma HTTPS deve essere implementato bene: certificati validi, redirect corretti, HSTS, configurazioni aggiornate e assenza di contenuti misti.

Su reti non affidabili può essere utile una VPN, soprattutto quando si lavora da luoghi pubblici. Anche la protezione del DNS è importante, perché un DNS manipolato può portare l’utente verso destinazioni sbagliate. Tecnologie come DNSSEC e resolver affidabili aiutano a ridurre questo rischio.

MITM ci ricorda che non basta proteggere il codice dell’applicazione. Bisogna proteggere anche il canale di comunicazione.

DDoS: quando l’obiettivo è mandare offline il servizio

Non tutti gli attacchi puntano a rubare dati o a manipolare richieste. Alcuni hanno un obiettivo più diretto: rendere un servizio indisponibile.

Gli attacchi DDoS, cioè Distributed Denial of Service, cercano di sommergere un sito o un servizio online con una quantità enorme di traffico, fino a renderlo lento, instabile o completamente irraggiungibile.

La differenza rispetto a un attacco DoS tradizionale sta nella distribuzione. In un DDoS il traffico arriva da molte sorgenti diverse, spesso dispositivi compromessi che fanno parte di una botnet. Computer, server, router, telecamere IP e dispositivi IoT possono essere infettati e usati per generare traffico verso un bersaglio.

Gli attacchi DDoS possono essere volumetrici, quando cercano di saturare la banda; possono puntare all’esaurimento delle risorse, come connessioni, memoria o CPU; oppure possono colpire il livello applicativo, simulando richieste apparentemente legittime ma in quantità insostenibile.

La difesa richiede preparazione. Durante un attacco, distinguere il traffico legittimo da quello malevolo può essere complesso. Per questo servono CDN, servizi di mitigazione DDoS, bilanciamento del carico, rate limiting, CAPTCHA, filtri sul traffico, WAF e monitoraggio.

La disponibilità è parte della sicurezza. Un sistema può essere integro e riservato, ma se non è raggiungibile quando serve, non sta garantendo il servizio per cui è stato progettato.

Zero-day: la vulnerabilità che ancora non conosciamo

Le vulnerabilità zero-day sono tra le minacce più difficili da gestire. Una zero-day è una falla sconosciuta al produttore o non ancora corretta nel momento in cui viene scoperta o sfruttata.

Il termine indica proprio questo: ci sono “zero giorni” disponibili per intervenire, perché non esiste ancora una patch pubblica.

Una vulnerabilità tradizionale, una volta nota, può essere corretta con un aggiornamento. Il problema diventa installare rapidamente la patch e ridurre la finestra di esposizione. Con una zero-day, invece, il difensore parte in svantaggio. Non sa ancora esattamente cosa cercare e spesso scopre il problema solo dopo che è stato sfruttato.

Le zero-day possono essere scoperte da ricercatori indipendenti, programmi di bug bounty, analisi del codice, reverse engineering o anche da attaccanti che decidono di venderle o utilizzarle. Possono essere usate in attacchi mirati contro aziende, governi, giornalisti, attivisti o infrastrutture critiche, ma anche in campagne più ampie.

La difesa contro una zero-day non può basarsi solo sulla firma di una minaccia già nota. Serve un approccio più ampio: aggiornamenti rapidi, riduzione della superficie di attacco, segmentazione della rete, privilegi minimi, EDR, sandboxing, monitoraggio dei comportamenti anomali, threat intelligence e procedure di risposta agli incidenti.

Non possiamo conoscere in anticipo ogni vulnerabilità. Ma possiamo progettare sistemi più resilienti e capaci di rilevare comportamenti sospetti.

Ogni vulnerabilità nasce da una fiducia mal gestita

Guardando insieme questi attacchi, emerge un filo comune.

La SQL Injection nasce quando ci si fida troppo dell’input usato nelle query. XSS nasce quando ci si fida troppo del contenuto mostrato nel browser. CSRF nasce quando ci si fida troppo di una richiesta solo perché arriva da una sessione autenticata. MITM nasce quando la comunicazione non è protetta abbastanza. DDoS sfrutta la fiducia nella capacità del servizio di gestire traffico e richieste. Le zero-day ci ricordano che non possiamo fidarci nemmeno del fatto che tutte le vulnerabilità siano già note.

La sicurezza informatica, in fondo, è un modo per gestire meglio la fiducia.

Non significa bloccare tutto. Significa verificare. Limitare. Separare. Monitorare. Aggiornare. Rendere espliciti i controlli che altrimenti rimarrebbero impliciti.

Un’applicazione sicura non assume che l’utente inserisca sempre dati corretti. Non assume che una richiesta autenticata sia sempre legittima. Non assume che la rete sia sempre affidabile. Non assume che il traffico sia sempre umano. Non assume che il software sia privo di falle sconosciute.

Questo approccio può sembrare più complesso, ma è ciò che permette di costruire servizi affidabili.

La sicurezza web è un processo continuo

Uno degli errori più comuni è considerare la sicurezza come un controllo finale: sviluppo l’applicazione, la metto online e poi, magari, faccio un test.

In realtà la sicurezza dovrebbe entrare in ogni fase.

Durante la progettazione bisogna ragionare sui dati trattati, sugli utenti, sui ruoli, sulle autorizzazioni e sugli scenari di abuso. Durante lo sviluppo bisogna usare framework sicuri, query parametrizzate, validazione degli input, escaping, gestione corretta delle sessioni e controlli sugli accessi. Durante il rilascio bisogna configurare correttamente server, TLS, header di sicurezza, logging e monitoraggio. Dopo il rilascio bisogna aggiornare, osservare, correggere, testare e reagire.

La sicurezza web non è un prodotto. È manutenzione continua.

Questo vale per chi sviluppa software, ma anche per chi gestisce infrastrutture, sistemi, domini, DNS, cloud, backup, firewall, CDN e servizi esterni. Ogni componente può diventare parte della superficie di attacco.

Conclusione

Le vulnerabilità web sono un tema centrale della sicurezza informatica moderna.

SQL Injection, XSS, CSRF, Man-in-the-Middle, DDoS e zero-day sono attacchi molto diversi tra loro, ma raccontano tutti la stessa cosa: il web è un ecosistema complesso, in cui applicazioni, browser, database, reti e utenti interagiscono continuamente.

Proteggere questo ecosistema richiede metodo.

Serve scrivere codice più sicuro, validare gli input, usare query preparate, proteggere le sessioni, cifrare le comunicazioni, limitare i privilegi, monitorare gli accessi, filtrare il traffico, aggiornare i sistemi e prepararsi anche a vulnerabilità non ancora note.

Non esiste la sicurezza assoluta, ma esiste una sicurezza più matura: quella che non si affida alla fortuna, ma alla progettazione, alla verifica e al miglioramento continuo.

Il messaggio finale è semplice: la sicurezza web non si aggiunge alla fine.

Si progetta dall’inizio, si testa durante lo sviluppo, si monitora in produzione e si mantiene nel tempo.