Attacchi alle Applicazioni Web: Guida Completa a Vulnerabilità ed Exploit

Questa guida copre le principali vulnerabilità web e tecniche di web exploitation utilizzate nel penetration testing moderno.

Ogni applicazione esposta su Internet è un bersaglio. Non è una questione di “se” verrà attaccata, ma di “quando” e “quanto in profondità” un attaccante riuscirà a penetrare. Nel pentesting moderno, la superficie web è di gran lunga la più estesa: non si tratta solo di form e pagine HTML, ma di API REST e GraphQL, endpoint di autenticazione, sistemi di upload, logiche di business multi-step, cache layer, object storage, microservizi interni e frontend JavaScript complessi che parlano con decine di backend diversi.

Questa guida è il punto di partenza per chi vuole comprendere davvero come funzionano gli attacchi alle applicazioni web — dalla teoria alla pratica, con la mentalità di chi fa assessment reali. Copriremo le vulnerabilità web più comuni, le tecniche di exploitation lato client e lato server, gli attacchi alla logica applicativa e le catene di exploit che trasformano un bug minore in una compromissione totale.

Se stai preparando l’OSCP, l’OSWE, fai CTF su HackTheBox o lavori come red teamer, qui trovi la mappa completa. Per ogni categoria di attacco, troverai link diretti alle guide verticali di HackIta — come quella sulla SQL Injection, sugli attacchi XSS, sulla Server-Side Request Forgery e sulle misconfigurazioni CORS — dove ogni tecnica viene sviscerata nel dettaglio con laboratori pratici.

Cos’è la Web Exploitation (in breve) #

La web exploitation è l’insieme delle tecniche usate per sfruttare vulnerabilità nelle applicazioni web al fine di ottenere accesso non autorizzato, eseguire codice o manipolare dati. Include attacchi come SQL Injection, XSS, SSRF, IDOR e vulnerabilità di business logic. Si applica a qualsiasi target esposto via HTTP: siti web, API, SPA, applicazioni mobile-backend e microservizi.

Cos’è un Attacco a una Web Application #

Un web application attack è qualsiasi azione deliberata che sfrutta una debolezza nel funzionamento di un’applicazione web per ottenere un risultato non previsto dallo sviluppatore: accesso non autorizzato a dati, esecuzione di codice, escalation di privilegi, denial of service o manipolazione della logica di business.

È importante distinguere tre concetti che spesso vengono confusi.

Una vulnerabilità è una debolezza nel codice, nella configurazione o nel design. Un exploit è la tecnica concreta che sfrutta quella vulnerabilità per produrre un effetto. Una misconfiguration è un errore nella configurazione dell’ambiente — server, framework, cloud — che apre la strada a un attacco anche senza bug nel codice applicativo. C’è poi un quarto elemento, spesso sottovalutato: l’abuse of logic, ovvero lo sfruttamento di flussi applicativi che funzionano esattamente come progettati ma che, combinati o usati fuori contesto, producono risultati pericolosi.

Un’altra distinzione fondamentale riguarda il punto in cui il bug si manifesta. I bug lato client colpiscono il browser dell’utente: il server non viene compromesso direttamente, ma l’attaccante manipola ciò che l’utente vede o fa (XSS, CSRF, open redirect, clickjacking). I bug lato server colpiscono il backend: il server esegue operazioni non previste, legge file che non dovrebbe, interroga servizi interni, esegue codice arbitrario (SQLi, SSRF, SSTI, command injection, XXE). I bug di business logic non rientrano in nessuna delle due categorie tradizionali: non c’è un payload maligno, ma una sequenza di azioni legittime che produce un risultato illegittimo.

Vulnerabilità Web: le più sfruttate nel Pentesting #

Prima di entrare nel dettaglio, ecco una mappa sintetica delle principali categorie di attacchi alle applicazioni web, con impatto e riferimenti.

Come Si Classificano gli Attacchi Web #

Non esiste una tassonomia universale, ma nella pratica del penetration testing web i macro-gruppi che contano sono questi.

Injection Attacks #

Il principio è semplice: dati forniti dall’utente finiscono in un contesto dove vengono interpretati come istruzioni. Se il backend costruisce una query SQL concatenando input non sanitizzato, il risultato è una iniezione SQL — una delle vulnerabilità più distruttive nella storia del web. Ma lo stesso principio si applica a template engine (SSTI), parser XML (XXE), shell di sistema (command injection), query LDAP e header di e-mail.

L’impatto di un’injection va dalla lettura completa del database all’esecuzione di comandi remoti sul server. In ambienti cloud, un’injection può essere il primo passo per raggiungere il metadata endpoint e ottenere credenziali IAM.

Client-Side Attacks #

In questa categoria, l’attaccante non colpisce direttamente il server ma usa l’applicazione come veicolo per attaccare gli utenti. Il Cross-Site Scripting è l’esempio classico: codice JavaScript iniettato nell’applicazione viene eseguito nel browser della vittima, permettendo furto di sessione, keylogging, phishing mirato e redirezioni malevole. Approfondisci le varianti nella guida dedicata al Cross-Site Scripting.

Anche il CSRF rientra qui: l’attaccante forza il browser della vittima a eseguire azioni autenticate su un’altra applicazione sfruttando i cookie inviati automaticamente. L’open redirect e il clickjacking completano il quadro degli attacchi lato client.

Server-Side Attacks #

Qui l’attaccante interagisce direttamente col backend per ottenere risultati non previsti. Le SSRF permettono di forzare il server a fare richieste HTTP verso risorse interne — spesso il primo passo per mappare la rete interna o raggiungere servizi cloud non esposti. La guida HackIta sulla SSRF copre scenari reali incluso l’accesso al metadata endpoint AWS.

File upload non sicuri, path traversal, deserializzazione insicura e SSTI sono tutti attacchi dove il server elabora input malevolo con conseguenze che vanno dalla lettura di file arbitrari all’esecuzione di codice remoto.

Access Control and Authorization Flaws #

I problemi di controllo degli accessi sono tra le vulnerabilità web più diffuse e meno tecnicamente sofisticate. Un IDOR (Insecure Direct Object Reference) si verifica quando l’applicazione usa un identificatore prevedibile — un ID numerico, un UUID debole — per accedere a risorse e non verifica che l’utente corrente sia autorizzato a vederle. Basta modificare un parametro nella richiesta per accedere ai dati di un altro utente.

Il broken access control è la prima categoria dell’OWASP Top 10 per un motivo: è ovunque. Ruoli non controllati a livello di API, endpoint amministrativi accessibili senza autenticazione, escalation orizzontale e verticale di privilegi.

Authentication and Session Attacks #

Tutto ciò che riguarda “chi sei” e “come lo dimostri”: brute force su login, credential stuffing, session fixation, token prevedibili, password reset abusabili, JWT mal configurati, assenza di rate limiting su OTP. Un bug nell’autenticazione ha spesso impatto critico perché rende irrilevante qualsiasi altro controllo di sicurezza delle applicazioni web.

Logic Flaws and Race Conditions #

I bug di logica non hanno un payload. Non c’è un <script>, non c’è un ' OR 1=1. Sono flussi applicativi che, se percorsi in un ordine specifico o in condizioni particolari, producono risultati non previsti: applicazione doppia di coupon, bypass della verifica di pagamento, manipolazione del prezzo nel carrello, skip di step in un workflow multi-fase.

Le race condition sono un caso specifico: quando due o più richieste concorrenti accedono alla stessa risorsa, e l’applicazione non gestisce l’atomicità, si possono ottenere risultati come doppio prelievo, doppia applicazione di crediti o bypass di limiti.

API-Specific Attacks #

Le API moderne — REST, GraphQL, gRPC — sono il backend reale delle applicazioni web, delle SPA e delle app mobile. Ogni vulnerabilità classica si applica alle API, ma ci sono pattern specifici: Broken Object Level Authorization (BOLA), mass assignment, mancanza di rate limiting, endpoint non documentati ma raggiungibili, SQL Injection su API REST tramite parametri JSON.

Misconfiguration-Driven Attacks #

A volte il codice è perfetto ma l’ambiente è configurato male. Header di sicurezza mancanti, CORS troppo permissivi, directory listing abilitato, debug mode in produzione, secret key di default, TLS debole, endpoint di management esposti. Una misconfigurazione CORS può trasformare un’applicazione altrimenti sicura in un bersaglio per il furto di dati cross-origin.

Gli Attacchi Web Più Importanti da Conoscere #

Questa sezione è il cuore della guida. Per ogni attacco: cos’è, perché è pericoloso, l’impatto tipico, come si sfrutta in pratica, cosa cerca un pentester e gli errori più comuni degli sviluppatori. È la base per qualsiasi attività di web security testing seria.

SQL Injection #

L’iniezione SQL avviene quando input dell’utente viene inserito direttamente in una query SQL senza sanitizzazione. Il risultato può andare dalla lettura dell’intero database all’esecuzione di comandi sul sistema operativo tramite funzioni come xp_cmdshell o INTO OUTFILE.

Perché è pericolosa: una SQLi può bypassare completamente l’autenticazione, esfiltrare dati sensibili, modificare record e, nei casi peggiori, portare a RCE. L’impatto è quasi sempre critico.

Scenario realistico: un form di login che costruisce la query con concatenazione di stringhe. L’attaccante inserisce admin' -- nel campo username e bypassa il controllo password. In scenari più avanzati, una blind SQL injection su un parametro di ricerca permette di estrarre l’intero schema del database una riga alla volta.

Cosa cerca un pentester: parametri che generano errori SQL cambiando tipo di input, differenze di comportamento con payload booleani (AND 1=1 vs AND 1=2), time-based delay con SLEEP() o pg_sleep(), punti di injection nei parametri GET/POST ma anche in header come Cookie, Referer e User-Agent.

Errori frequenti dei developer: uso di concatenazione di stringhe invece di prepared statement, fidarsi di ORM senza capirne i limiti, sanitizzare solo lato frontend, usare blacklist di caratteri invece di parametrizzazione.

La guida completa di HackIta sulla SQL Injection copre Union-based, Error-based, Blind Boolean, Blind Time-based e le varianti su database diversi. Per scenari specifici su endpoint API, c’è la guida dedicata alla SQLi su API REST.

Cross-Site Scripting (XSS) #

Il Cross-Site Scripting permette a un attaccante di iniettare codice JavaScript che viene eseguito nel browser di altri utenti nel contesto dell’applicazione vulnerabile. Il browser della vittima tratta lo script iniettato come codice legittimo dell’applicazione, concedendogli accesso completo a cookie, DOM, sessione e qualsiasi azione l’utente possa compiere.

Perché è pericoloso: un XSS su un’applicazione con sessioni basate su cookie può portare al furto immediato della sessione. Su applicazioni con token, permette keylogging, phishing mirato, modifica del DOM per ingannare l’utente, e in catena con altri bug può portare a takeover completo dell’account.

Varianti principali:

L’XSS Reflected si attiva quando la vittima clicca un link malevolo: il payload viene riflesso nella risposta senza essere salvato. L’XSS Stored è più pericoloso: il payload viene salvato nel database e si attiva per ogni utente che visualizza il contenuto infetto — un commento, un profilo, un messaggio. Il DOM-based XSS si verifica quando il JavaScript lato client processa input non sicuro senza passare dal server.

Cosa cerca un pentester: punti dove l’input viene riflesso nella risposta HTML, contesti di injection (dentro un tag, un attributo, un blocco JavaScript, un commento HTML), filtri di sanitizzazione aggirabili, sink DOM-based (innerHTML, document.write, eval).

Errori frequenti dei developer: sanitizzare solo <script>, non fare output encoding contestuale (HTML vs attributo vs JavaScript vs URL), fidarsi di Content-Type senza CSP, blacklist di tag invece di whitelist.

Server-Side Request Forgery (SSRF) #

La SSRF si verifica quando un’applicazione web effettua richieste HTTP basandosi su input dell’utente senza validazione adeguata. L’attaccante può forzare il server a comunicare con risorse interne, servizi cloud non esposti, oppure usarlo come proxy per attaccare altri sistemi.

Perché è pericolosa: in ambienti cloud, una SSRF può raggiungere il metadata endpoint (169.254.169.254) e ottenere credenziali IAM temporanee. In ambienti on-premise, permette di mappare la rete interna, accedere a servizi come Redis, Elasticsearch o database non esposti su Internet.

Scenario realistico: un’applicazione che genera preview di URL forniti dall’utente. L’attaccante inserisce http://169.254.169.254/latest/meta-data/iam/security-credentials/ e il server restituisce le credenziali AWS del ruolo associato all’istanza.

Cosa cerca un pentester: funzionalità che accettano URL (importazione, preview, webhook, integrazione con servizi esterni), parametri che contengono hostname o IP, redirect che il server segue lato backend, protocolli alternativi (file://, gopher://, dict://).

Errori frequenti dei developer: validare solo il protocollo senza controllare l’IP di destinazione, non bloccare IP privati, permettere redirect che portano a risorse interne, non considerare encoding alternativi dell’IP (decimale, esadecimale, IPv6).

Misconfigurazione CORS (Cross-Origin Resource Sharing) #

Il CORS è un meccanismo che controlla quali domini possono accedere alle risorse di un’applicazione web tramite richieste cross-origin dal browser. Una misconfigurazione — come riflettere dinamicamente qualsiasi Origin nell’header Access-Control-Allow-Origin con Allow-Credentials: true — permette a un sito malevolo di leggere risposte autenticate dell’applicazione vittima.

Perché è pericolosa: un CORS mal configurato trasforma qualsiasi XSS su qualsiasi dominio in un vettore per esfiltrare dati dall’applicazione vulnerabile. Anche senza XSS, un sito controllato dall’attaccante può fare richieste autenticate e leggerne le risposte.

Cosa cerca un pentester: header Access-Control-Allow-Origin che riflettono l’Origin della richiesta, trust di sottodomini che potrebbero essere compromessi, wildcard con credenziali, pre-flight bypassabili.

Errori frequenti dei developer: usare regex deboli per validare l’Origin (es. endsWith('example.com') che matcha anche evilexample.com), copiare l’Origin in ACAO senza whitelist, non capire la differenza tra richieste simple e pre-flighted.

Approfondisci nella guida dedicata all’abuso delle configurazioni CORS.

Cross-Site Request Forgery (CSRF) #

Il CSRF sfrutta il fatto che il browser invia automaticamente i cookie con ogni richiesta verso un dominio, anche se la richiesta è originata da un altro sito. Se un’applicazione non verifica che un’azione sia stata iniziata intenzionalmente dall’utente, un attaccante può creare una pagina che, quando visitata dalla vittima, esegue azioni autenticate sull’applicazione target.

Perché è pericoloso: cambio password, cambio email, trasferimento fondi, modifica impostazioni — qualsiasi azione che l’utente può fare può essere eseguita a sua insaputa. L’impatto dipende dalle funzionalità disponibili.

Cosa cerca un pentester: assenza di token anti-CSRF nelle form, token CSRF prevedibili o non validati, SameSite cookie non configurato, endpoint che accettano cambio di Content-Type (da form-urlencoded a JSON e viceversa), bypass tramite sottodomain.

Errori frequenti dei developer: non implementare token anti-CSRF su azioni sensibili, validare il token solo in GET ma non in POST, non associare il token alla sessione specifica, affidarsi solo al Referer header.

IDOR e Broken Access Control #

L’IDOR si verifica quando l’applicazione usa un riferimento diretto a un oggetto — un ID numerico, un filename, un UUID — e non verifica che l’utente corrente sia autorizzato ad accedere a quell’oggetto. Basta incrementare un parametro ?id=1001 a ?id=1002 per accedere ai dati di un altro utente.

Il broken access control è il concetto più ampio: include IDOR ma anche escalation verticale (utente normale accede a funzioni admin), bypass di controlli basati solo sul frontend, endpoint API non protetti.

Perché è pericoloso: l’impatto è spesso data breach massivo. Un singolo IDOR su un endpoint API che restituisce profili utente può esporre i dati di tutti gli utenti del sistema.

Cosa cerca un pentester: ID sequenziali o prevedibili, endpoint che restituiscono dati diversi cambiando un parametro, differenze di comportamento tra utenti con ruoli diversi, funzionalità admin accessibili senza check di ruolo, endpoint non documentati trovati via fuzzing.

File Upload Vulnerabilities #

Quando un’applicazione permette di caricare file, ogni aspetto del processo può essere vulnerabile: tipo di file, contenuto, nome, path di destinazione, elaborazione post-upload. Un upload non sicuro può portare a RCE se l’attaccante riesce a caricare ed eseguire un web shell.

Scenario realistico: l’applicazione controlla solo l’estensione ma non il contenuto. L’attaccante carica un file avatar.php.jpg o manipola il Content-Type. Se il server è configurato per interpretare PHP nella directory di upload, il web shell viene eseguito.

Cosa cerca un pentester: validazione solo lato client del tipo file, controllo dell’estensione ma non del magic byte, directory di upload servita dal web server senza restrizioni, path traversal nel filename, assenza di randomizzazione del nome file.

Server-Side Template Injection (SSTI) #

La SSTI si verifica quando input dell’utente viene inserito in un template engine lato server (Jinja2, Twig, Freemarker, Velocity) e viene interpretato come codice del template. Il risultato è spesso RCE diretto.

Scenario realistico: un’applicazione che personalizza messaggi usando un template engine. Se l’input {{7*7}} restituisce 49, il template engine sta interpretando l’input. Da lì, il percorso verso os.system() o equivalente è spesso breve.

Cosa cerca un pentester: punti dove l’input viene renderizzato dinamicamente, differenze nel comportamento con payload di detection specifici per ogni engine (${7*7}, {{7*7}}, <%= 7*7 %>), messaggi di errore che rivelano il template engine.

XML External Entity (XXE) #

L’XXE sfrutta la capacità dei parser XML di risolvere entità esterne. Se il parser è configurato in modo permissivo, un attaccante può definire un’entità che punta a un file locale (file:///etc/passwd) o a un URL interno, e il parser includerà il contenuto nella risposta.

Perché è pericoloso: lettura di file arbitrari sul server, SSRF tramite entità che fanno richieste HTTP, denial of service tramite entity expansion (Billion Laughs), in alcuni casi blind exfiltration via out-of-band.

Cosa cerca un pentester: endpoint che accettano XML (API SOAP, upload SVG, import di file Office, feed RSS), risposte che riflettono contenuto delle entità, errori di parsing che rivelano informazioni.

Command Injection #

Quando l’applicazione passa input dell’utente a una shell di sistema — tramite system(), exec(), backtick in Perl, os.system() in Python — senza sanitizzazione, l’attaccante può concatenare comandi arbitrari usando separatori come ;, |, &&, ` o $().

Perché è pericoloso: impatto immediato è RCE con i privilegi del processo web server. Da lì, persistenza, lateral movement, data exfiltration.

Cosa cerca un pentester: funzionalità che interagiscono con il sistema (ping, DNS lookup, conversione file, generazione PDF, invio email), ritardi inseribili tramite sleep, output di comandi visibile nella risposta, blind injection via DNS o HTTP out-of-band.

Race Condition #

Una race condition web si verifica quando due o più richieste concorrenti operano sulla stessa risorsa e l’applicazione non garantisce atomicità. L’esempio classico: un codice sconto monouso viene applicato più volte inviando richieste parallele prima che la prima completi l’aggiornamento dello stato.

Perché è pericolosa: bypass di limiti, doppia applicazione di crediti, creazione di dati inconsistenti, bypass di check di unicità. In contesti finanziari, l’impatto è immediato e misurabile.

Cosa cerca un pentester: operazioni di lettura-modifica-scrittura non atomiche, endpoint con side effect su risorse condivise, pattern TOCTOU (Time Of Check, Time Of Use), funzionalità con limiti di utilizzo (coupon, vote, like, transfer).

Open Redirect #

Un open redirect si verifica quando l’applicazione reindirizza l’utente a un URL fornito come parametro senza validazione. Sembra innocuo, ma è un vettore potente: permette di creare link di phishing che partono dal dominio legittimo dell’applicazione, bypassare filtri di URL in altre vulnerabilità (SSRF, OAuth flow), e in combinazione con altri bug può portare a token theft.

Cosa cerca un pentester: parametri come ?redirect=, ?url=, ?next=, ?return=, ?dest=, risposte 301/302 con Location controllabile, bypass di validazione con encoding, doppi slash, o domain confusion.

Deserialization Vulnerabilities #

La deserializzazione insicura si verifica quando un’applicazione converte dati serializzati (Java ObjectInputStream, Python pickle, PHP unserialize, .NET BinaryFormatter) in oggetti senza validare il contenuto. Un attaccante può costruire un payload serializzato che, al momento della deserializzazione, esegue codice arbitrario.

Perché è pericolosa: l’impatto è quasi sempre RCE. In Java, le gadget chain (ysoserial) permettono di sfruttare librerie presenti nel classpath per eseguire comandi. L’exploitation è spesso “fire and forget”: un singolo payload, esecuzione immediata.

Cosa cerca un pentester: header Content-Type che indicano serializzazione (Java: application/x-java-serialized-object; PHP: parametri con pattern O:4:"User"...), cookie o parametri con dati base64 che decodificati mostrano strutture serializzate, ViewState in ASP.NET.

Authentication Bypass e Session Abuse #

L’autenticazione è il gate di ingresso. Se è aggirabile, tutto il resto diventa irrilevante. Pattern comuni: password reset prevedibile, OTP senza rate limiting che permette brute force, session token sequenziali, JWT con algorithm confusion (none, HS256 al posto di RS256), manipolazione del flusso OAuth, cookie di sessione non HttpOnly o non Secure.

Cosa cerca un pentester: entropia dei token di sessione, comportamento del password reset (token prevedibile? token riusabile? rate limit?), configurazione JWT (algoritmo, validazione della firma, claim exp, aud), possibilità di session fixation, endpoint di registrazione che permettono self-enrollment in ruoli privilegiati.

API Abuse e BOLA #

Le API moderne sono il backend reale di tutto. BOLA (Broken Object Level Authorization) è la versione API dell’IDOR: l’endpoint /api/v1/users/123/orders restituisce gli ordini dell’utente 123, e cambiando l’ID si accede agli ordini di chiunque.

Altri pattern specifici: mass assignment (l’API accetta più campi di quelli esposti nel frontend, permettendo di modificare il proprio ruolo), rate limiting assente su endpoint sensibili, versionamento API che lascia endpoint legacy non protetti, GraphQL introspection che rivela lo schema completo.

OWASP Top 10 e Attacchi Reali #

L’OWASP Top 10 è il framework di riferimento per classificare i rischi di sicurezza delle applicazioni web. È un punto di partenza eccellente, ma non esaurisce il panorama reale. Molte vulnerabilità critiche nei programmi di bug bounty e negli assessment professionali non rientrano pulitamente in nessuna categoria OWASP: race condition, business logic abuse, cache poisoning, prototype pollution, HTTP request smuggling.

Detto questo, il mapping tra categorie OWASP e pratica concreta è utile per orientarsi.

L’OWASP è utile come checklist mentale, ma il pentester esperto pensa in termini di superficie d’attacco e catene di exploit, non di categorie statiche.

Attacchi Web Lato API #

Le API meritano una sezione dedicata perché oggi la maggior parte del traffico web passa attraverso endpoint API, non attraverso form HTML tradizionali. Le SPA (Single Page Application) comunicano con il backend tramite API REST o GraphQL. Le applicazioni mobile fanno lo stesso. I microservizi parlano tra loro tramite API interne.

Questo significa che molte vulnerabilità “classiche” si manifestano in modo diverso sulle API. Una SQL Injection non arriva da un form ma da un parametro JSON nel body di una richiesta POST. Un IDOR non si trova cambiando un parametro nell’URL ma manipolando un campo nell’oggetto JSON inviato all’endpoint. La guida HackIta sulla SQL Injection nelle API REST mostra concretamente queste differenze.

Pattern di attacco specifici per API:

BOLA è il re delle vulnerabilità API: se l’endpoint non verifica che l’utente autenticato sia il proprietario della risorsa richiesta, è game over. Mass assignment entra in gioco quando l’API accetta più campi di quelli mostrati nel frontend: l’attaccante aggiunge "role": "admin" nel JSON e l’API lo processa. Rate limiting assente su endpoint di autenticazione permette brute force. Endpoint di versioni precedenti (/api/v1/) lasciati attivi senza le protezioni aggiunte in /api/v2/. GraphQL introspection abilitata in produzione rivela l’intero schema, inclusi tipi e campi che il frontend non usa.

Webhook e funzionalità di import rappresentano superfici SSRF particolarmente insidiose: l’applicazione deve fare richieste a URL forniti dall’utente per integrazioni con servizi esterni, e limitare questa funzionalità senza romperla è complesso. Anche le vulnerabilità di file upload nelle API vanno testate con attenzione: spesso gli endpoint di upload accettano multipart/form-data con controlli minimi sul contenuto.

Attacchi Web Lato Business Logic #

Questa è la sezione che separa i pentester mediocri da quelli bravi. I bug di business logic non hanno CVE, non vengono trovati da scanner automatici, non hanno un payload standard. Richiedono comprensione del flusso applicativo, creatività e pazienza.

Esempi concreti:

Un e-commerce applica un codice sconto nel carrello. Il flusso prevede: aggiungi prodotti → applica codice → procedi al pagamento. Ma cosa succede se dopo aver applicato il codice, aggiungi altri prodotti? Lo sconto si riapplica al totale aggiornato? E se rimuovi i prodotti originali, lo sconto resta?

Un sistema di prenotazione ha un timeout di 15 minuti: se non completi il pagamento, la prenotazione viene rilasciata. Ma il timer è gestito lato client e il server non lo verifica. L’utente blocca una risorsa indefinitamente.

Un’applicazione bancaria permette trasferimenti con un limite giornaliero di 10.000€. Ma il check è: if (importo_transazione > 10000) { reject }. Facendo 100 trasferimenti da 9.999€ non si supera mai il check singolo.

Un workflow di approvazione multi-step: passo 1 → passo 2 → passo 3. Ma se invii direttamente la richiesta del passo 3, il server la processa senza verificare che i passi precedenti siano stati completati.

Le race condition applicative rientrano in questa categoria: sfruttano una finestra temporale tra il check e l’uso di una risorsa per ottenere risultati non previsti. Un coupon monouso diventa multiuso, un voto singolo diventa doppio, un prelievo unico diventa duplice.

Catena di Exploit: Come gli Attacchi Web Si Combinano #

Il pentesting reale non è “trovo una SQLi, game over”. Le vulnerabilità critiche spesso emergono dalla combinazione di bug minori che, presi singolarmente, sarebbero classificati come low o medium. La capacità di costruire catene è ciò che distingue un web security testing di livello da un vulnerability scan automatizzato.

Catene classiche:

IDOR → Data Leak → Password Reset Abuse. Un IDOR su un endpoint API rivela le email degli utenti. L’attaccante usa le email per attivare il flusso di password reset, scopre che il token è prevedibile (basato su timestamp), e ottiene accesso all’account target.

File Upload → Web Shell → RCE. Un upload non validato permette di caricare un file PHP. La directory di upload è servita dal web server. L’attaccante accede al file caricato ed ha una shell interattiva. Dalla shell, escalation locale o pivot in rete.

SSRF → Internal Service Discovery → Cloud Metadata Access. Una SSRF in una funzionalità di preview URL permette di raggiungere il metadata endpoint cloud. L’attaccante ottiene credenziali IAM temporanee, enumera i bucket S3, trova dati sensibili.

XSS Stored → Session Hijack → Privilege Escalation. Un XSS stored nel profilo utente cattura il cookie di sessione di un admin che visualizza la lista utenti. L’attaccante impersona l’admin e modifica i permessi del proprio account.

SQLi → Credential Dump → Admin Takeover. Una blind SQL injection su un parametro di ricerca permette di estrarre la tabella utenti con hash delle password. Un hash debole viene crackato, l’attaccante accede come admin.

CSRF → Account Takeover. Un CSRF su un endpoint di cambio email permette all’attaccante di associare la propria email all’account della vittima. Da lì, password reset e accesso completo.

XXE → File Read → Credential Exfiltration. Un’XXE su un endpoint di import XML legge il file di configurazione del server contenente credenziali del database. L’attaccante accede al DB direttamente.

La capacità di costruire catene di exploit è ciò che rende un pentester efficace. Ogni vulnerabilità trovata non è solo un finding: è un possibile punto di partenza per una catena più lunga.

Metodologia Pratica per Analizzare una Web App in Ottica Offensiva #

Questa è la metodologia che un pentester applica sul campo, non una checklist accademica. È il framework operativo per qualsiasi penetration testing web.

Fase 1 — Reconnaissance. Mappare tutto ciò che è raggiungibile: sottodomini, tecnologie, versioni, endpoint, parametri. Strumenti come Burp Suite, ffuf, subfinder, httpx. Obiettivo: capire la superficie d’attacco prima di toccare qualsiasi parametro.

Fase 2 — Mapping della superficie. Navigare l’applicazione con proxy attivo. Identificare ogni funzionalità: login, registrazione, ricerca, profilo, upload, API, admin panel, integrazioni esterne. Registrare ogni richiesta, ogni parametro, ogni header custom.

Fase 3 — Input discovery. Catalogare tutti i punti di input: parametri GET e POST, header HTTP, cookie, file upload, WebSocket message, JSON body, parametri di URL path. Ogni input è un potenziale vettore di injection.

Fase 4 — Analisi HTTP. Metodi supportati per ogni endpoint (GET, POST, PUT, DELETE, PATCH, OPTIONS). Comportamento con Content-Type diversi. Risposte a metodi non previsti. Header di sicurezza presenti e assenti.

Fase 5 — Autenticazione e sessione. Come funziona il login? Cookie, JWT, token custom? Come viene gestito il logout? Il token scade? È possibile session fixation? Il password reset è sicuro? C’è MFA e si può bypassare?

Fase 6 — Access control testing. Testare ogni endpoint con ruoli diversi. Utente A accede alle risorse di utente B? Un utente normale raggiunge endpoint admin? I controlli sono applicati lato server o solo lato frontend?

Fase 7 — Analisi dei workflow di business. Capire i flussi multi-step. Provare a saltare step. Provare a ripetere step. Provare a invertire l’ordine. Provare con valori ai limiti. Provare concorrenza su operazioni critiche.

Fase 8 — Payload testing. Injection classiche: SQLi, XSS, SSTI, command injection, XXE, path traversal. Testare in ogni punto di input identificato. Variare i payload in base al contesto (HTML, JavaScript, SQL, template, XML, shell).

Fase 9 — Chaining. Collegare i finding. Un information disclosure combinato con un IDOR diventa un data breach. Un XSS combinato con un CSRF diventa un account takeover. Pensare sempre: “questo bug, combinato con cosa, dove mi porta?”

Errori Più Comuni che Rendono Vulnerabile una Web Application #

Gli stessi errori si ripetono in modo prevedibile da vent’anni. Riconoscerli è il primo passo per sfruttarli in un assessment e per evitarli nello sviluppo.

Validazione solo lato client. Il frontend controlla che il file sia un’immagine, ma il backend accetta qualsiasi cosa. Il frontend limita la lunghezza dell’input, ma il backend non verifica. Ogni controllo solo nel browser è bypassabile con un proxy.

Fiducia nell’header Origin/Referer. Usati come unico meccanismo anti-CSRF o per controllo degli accessi. Sono header controllabili dall’attaccante in molti scenari.

Filtri basati su blacklist. Bloccare <script> non protegge da XSS. Bloccare SELECT non protegge da SQLi. Bloccare 127.0.0.1 non protegge da SSRF. Le blacklist sono sempre incomplete.

Controlli di accesso solo nel frontend. Il pulsante “Admin” non è visibile a un utente normale, ma l’endpoint /api/admin/users è raggiungibile direttamente. I controlli di autorizzazione devono essere nel backend, su ogni endpoint.

Parser inconsistency. Il WAF interpreta la richiesta in un modo, il backend in un altro. Il frontend sanitizza in un modo, il backend processa in un altro. Le inconsistenze tra componenti sono terra fertile per bypass.

Serializzazione insicura. Usare pickle, unserialize(), ObjectInputStream su dati forniti dall’utente senza validazione. Mai deserializzare input non fidato con formati che permettono esecuzione di codice.

Controllo insufficiente su file upload. Controllare solo l’estensione, o solo il Content-Type, o solo il magic byte — ma non tutti e tre. Non randomizzare il nome. Servire i file dalla stessa directory del web server.

Trust eccessiva in servizi interni. “Questa API è interna, non serve autenticazione.” Poi una SSRF permette a un attaccante esterno di raggiungerla. Zero trust non è solo marketing: i servizi interni devono autenticare e autorizzare ogni richiesta.

Race unsafe workflow. Operazioni critiche (pagamento, applicazione coupon, voto, trasferimento) senza lock o gestione dell’atomicità. Se due richieste parallele possono leggere lo stesso stato prima che l’altra lo modifichi, il bug è servito.

Come Difendersi dagli Attacchi Web #

Questa sezione è scritta con la mentalità di chi attacca ma conosce anche la difesa. Ogni contromisura è pensata come risposta diretta alle tecniche descritte sopra.

Validazione server-side rigorosa. Ogni input deve essere validato nel backend. Tipo, lunghezza, formato, range. Whitelist quando possibile, regex restrittive quando necessario. Mai fidarsi del frontend.

Output encoding contestuale. L’encoding corretto dipende dal contesto: HTML entity encoding nel body HTML, attribute encoding negli attributi, JavaScript encoding nei blocchi JS, URL encoding nei parametri URL. Non esiste un encoding universale.

Prepared statement e query parametrizzate. L’unica difesa reale contro la SQL Injection. Non concatenare mai input dell’utente nelle query. Usare i meccanismi di parametrizzazione nativi del linguaggio e del driver del database.

Principio del minimo privilegio. Il processo web server non deve girare come root. L’utente del database non deve avere permessi di DBA. Le credenziali dei servizi devono avere solo i permessi strettamente necessari.

Object-level authorization. Ogni endpoint che restituisce o modifica una risorsa deve verificare che l’utente corrente sia autorizzato ad operare su quella specifica risorsa. Non basta verificare che sia autenticato.

Gestione sicura del file upload. Validare tipo MIME, magic byte ed estensione. Randomizzare il nome. Salvare fuori dalla webroot. Servire tramite endpoint dedicato con Content-Disposition e Content-Type corretti. Non permettere esecuzione nella directory di upload.

Gestione sicura delle sessioni. Token con entropia sufficiente, HttpOnly, Secure, SameSite. Scadenza ragionevole. Invalidazione effettiva al logout. Rotazione dopo il login. Rate limiting sui tentativi di autenticazione.

Defense in depth. Non affidarsi a un singolo layer di protezione. WAF, CSP, input validation, output encoding, parameterized queries, access control, monitoring: ogni layer cattura ciò che il precedente ha mancato.

Testing continuo. SAST, DAST, penetration test periodici, bug bounty program. Le vulnerabilità si introducono a ogni commit. La sicurezza non è uno stato, è un processo.

Checklist Rapida per Pentester e Studenti #

Questa checklist è pensata per essere usata durante un assessment o un laboratorio come traccia operativa.

• Reconnaissance completata: sottodomini, tecnologie, versioni
• Superficie mappata con proxy: ogni endpoint, parametro, funzionalità
• Tutti i punti di input catalogati: GET, POST, header, cookie, JSON body, file upload
• Autenticazione analizzata: entropia token, password reset, session management, JWT
• Access control testato con ruoli diversi su ogni endpoint
• Injection testate in ogni input: SQLi, XSS, SSTI, command injection, XXE
• SSRF testata su ogni funzionalità che accetta URL
• CORS verificate: policy permissive, Origin riflesso, credentials
• CSRF verificato su azioni state-changing sensibili
• File upload testato: bypass estensione, tipo, path traversal nel filename
• Business logic analizzata: workflow multi-step, race condition, limiti bypassabili
• Catene di exploit costruite: ogni bug minore collegato ad altri finding
• Report con impatto reale: non solo “XSS trovato” ma “XSS → session hijack → admin takeover”

Approfondimenti Correlati su HackIta #

Per andare in profondità su ogni tecnica citata in questa guida, ecco i verticali più importanti:

1. SQL Injection: dalla detection all’exploitation completa
2. Cross-Site Scripting (XSS): guida pratica
3. XSS Reflected: attacco e scenari reali
4. XSS Stored: il payload che persiste
5. SSRF: Server-Side Request Forgery dall’interno
6. SQL Injection su API REST
7. Race Condition nelle applicazioni web
8. CORS Misconfiguration: come si sfrutta
9. CSRF: Cross-Site Request Forgery
10. IDOR: Insecure Direct Object Reference
11. File Upload Vulnerabilities
12. SSTI: Server-Side Template Injection
13. XXE: XML External Entity

Conclusione #

La web exploitation moderna non è una lista di payload da copiare e incollare. È comprensione del contesto, analisi dei flussi, combinazione creativa di vulnerabilità minori in catene devastanti. Un’applicazione web è un sistema complesso fatto di frontend, backend, API, servizi interni, configurazioni cloud e logiche di business — e ogni componente introduce superficie d’attacco per la sicurezza di applicazioni web e web security testing

I singoli attacchi che abbiamo coperto — injection, XSS, SSRF, CSRF, IDOR, file upload, SSTI, XXE, broken access control, race condition, business logic abuse — sono i mattoni. La capacità di riconoscerli, combinarli e sfruttarli in contesti reali è ciò che rende un pentester efficace.

Se capisci davvero queste tecniche, sei già sopra il 90% dei developer e davanti alla maggior parte dei pentester junior.

Se stai studiando per l’OSCP, l’OSWE, fai CTF o lavori in red team, questa guida è il tuo punto di partenza. Ogni verticale linkato in questo articolo scende nel dettaglio tecnico con laboratori e scenari pratici. La web security è un campo dove la profondità e la pratica costante fanno la differenza — e HackIta è qui per questo.

Disclaimer: Contenuti a scopo didattico e per attività autorizzate di sicurezza offensiva. Non usare queste tecniche su sistemi senza permesso esplicito.

Approfondimenti: - OWASP Top 10

• PortSwigger Web Security Academy
• OWASP Cheat Sheet Series