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 #

Come Si Classificano gli Attacchi Web #

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, manipolazione del flusso OAuth. 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 business logic 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 #

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.

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(), injection in header come Cookie, Referer e User-Agent.

La guida completa sulla SQL Injection copre Union-based, Error-based, Blind Boolean, Blind Time-based. Per API, la guida dedicata alla SQLi su API REST.

Cross-Site Scripting (XSS) #

Il Cross-Site Scripting permette di iniettare codice JavaScript eseguito nel browser di altri utenti nel contesto dell’applicazione vulnerabile.

Varianti principali:

Il Reflected XSS si attiva quando la vittima clicca un link malevolo. L’XSS Stored è più pericoloso: il payload viene salvato nel database e si attiva per ogni utente che visualizza il contenuto infetto. Il DOM-based XSS si verifica quando il JavaScript lato client processa input non sicuro. Il Blind XSS si attiva in contesti non visibili all’attaccante — pannelli admin, log viewer, sistemi di ticketing.

Cosa cerca un pentester: punti dove l’input viene riflesso nella risposta HTML, filtri di sanitizzazione aggirabili, sink DOM-based (innerHTML, document.write, eval).

Server-Side Request Forgery (SSRF) #

La SSRF si verifica quando un’applicazione effettua richieste HTTP basandosi su input dell’utente senza validazione adeguata. In ambienti cloud, una SSRF può raggiungere il metadata endpoint (169.254.169.254) e ottenere credenziali IAM temporanee.

Cosa cerca un pentester: funzionalità che accettano URL (importazione, preview, webhook), parametri che contengono hostname o IP, protocolli alternativi (file://, gopher://, dict://).

Misconfigurazione CORS #

Una misconfigurazione CORS — come riflettere dinamicamente qualsiasi Origin con Allow-Credentials: true — permette a un sito malevolo di leggere risposte autenticate dell’applicazione vittima.

Errori frequenti: usare regex deboli per validare l’Origin, copiare l’Origin in ACAO senza whitelist.

Cross-Site Request Forgery (CSRF) #

Il CSRF sfrutta il fatto che il browser invia automaticamente i cookie con ogni richiesta verso un dominio. Se un’applicazione non verifica che un’azione sia stata iniziata intenzionalmente dall’utente, un attaccante può eseguire azioni autenticate a sua insaputa.

Cosa cerca un pentester: assenza di token anti-CSRF, token prevedibili o non validati, SameSite cookie non configurato, bypass tramite sottodomain.

IDOR e Broken Access Control #

Un IDOR — (Insecure Direct Object Reference) si verifica quando l’applicazione usa un riferimento diretto a un oggetto senza verificare che l’utente corrente sia autorizzato ad accedervi. Basta incrementare ?id=1001 a ?id=1002 per accedere ai dati di un altro utente.

Perché è pericoloso: un singolo IDOR su un endpoint API può esporre i dati di tutti gli utenti del sistema.

File Upload Vulnerabilities #

Un upload non sicuro può portare a RCE se l’attaccante riesce a caricare ed eseguire un web shell. L’applicazione controlla solo l’estensione ma non il contenuto: l’attaccante carica avatar.php.jpg o manipola il Content-Type.

Server-Side Template Injection (SSTI) #

La SSTI si verifica quando input dell’utente viene inserito in un template engine lato server (Jinja2, Twig, Freemarker) e interpretato come codice. Se {{7*7}} restituisce 49, il template engine sta interpretando l’input. Il percorso verso RCE è spesso breve.

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ò puntare a un file locale (file:///etc/passwd) o a un URL interno. Impatto: lettura file arbitrari, SSRF, blind exfiltration out-of-band.

Command Injection #

Quando l’applicazione passa input dell’utente a una shell di sistema senza sanitizzazione, l’attaccante può concatenare comandi arbitrari usando ;, |, &&, o $(). Impatto immediato: RCE con i privilegi del processo web server.

Race Condition #

Una race condition web si verifica quando due o più richieste concorrenti operano sulla stessa risorsa senza atomicità. Un codice sconto monouso diventa multiuso, un prelievo unico diventa duplice.

Open Redirect #

Un open redirect si verifica quando l’applicazione reindirizza a un URL fornito come parametro senza validazione. Permette link di phishing che partono dal dominio legittimo, bypass di filtri URL in SSRF, token theft in combinazione con altri bug.

Deserialization Vulnerabilities #

La deserializzazione insicura si verifica quando un’applicazione converte dati serializzati (Java ObjectInputStream, Python pickle, PHP unserialize) in oggetti senza validare il contenuto. Un payload costruito ad hoc porta quasi sempre a RCE.

Authentication Bypass e Session Abuse #

Pattern comuni: password reset prevedibile, OTP senza rate limiting, session token sequenziali, JWT con algorithm confusion, manipolazione del flusso OAuth, session fixation.

API Abuse e BOLA #

BOLA è la versione API dell’IDOR —: l’endpoint /api/v1/users/123/orders restituisce gli ordini dell’utente 123, cambiando l’ID si accede agli ordini di chiunque. GraphQL exploitation tramite introspection abilitata in produzione rivela l’intero schema.

Business Logic Flaw #

I bug di business logic non hanno un CVE, non vengono trovati da scanner automatici, non hanno un payload standard. Richiedono comprensione del flusso applicativo: applicazione doppia di coupon, bypass della verifica di pagamento, skip di step in workflow multi-fase, manipolazione del prezzo nel carrello.

OWASP Top 10 e Attacchi Reali #

Attacchi Web Lato API #

Le API moderne — REST, GraphQL, gRPC — sono il backend reale di tutto. BOLA è il re delle vulnerabilità API. Mass assignment entra in gioco quando l’API accetta più campi di quelli mostrati nel frontend. Rate limiting assente su endpoint di autenticazione permette brute force. Endpoint di versioni precedenti lasciati attivi senza protezioni aggiornate.

La guida sulla SQL Injection nelle API REST mostra concretamente le differenze rispetto alle injection su form tradizionali. Anche le vulnerabilità di file upload nelle API vanno testate con attenzione.

Attacchi Web Lato Business Logic #

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.

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

Catena di Exploit #

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, ottiene accesso all’account target.

File Upload → Web Shell → RCE. Un upload non validato permette di caricare un file PHP. L’attaccante accede al web shell e ha esecuzione interattiva.

SSRF → Internal Service → Cloud Metadata. Una SSRF raggiunge il metadata endpoint cloud. L’attaccante ottiene credenziali IAM temporanee, enumera i bucket S3.

XSS Stored → Session Hijack → Privilege Escalation. Un XSS stored cattura il cookie di sessione di un admin. L’attaccante modifica i permessi del proprio account.

SQLi → Credential Dump → Admin Takeover. Una blind SQL injection estrae hash delle password. Un hash debole viene crackato, l’attaccante accede come admin.

CSRF → Account Takeover. Un CSRF su cambio email permette all’attaccante di associare la propria email all’account 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 con credenziali del database.

Metodologia Pratica #

Fase 1 — Reconnaissance. Sottodomini, tecnologie, versioni, endpoint, parametri.

Fase 2 — Mapping superficie. Proxy attivo su tutta la navigazione. Ogni funzionalità documentata.

Fase 3 — Input discovery. Parametri GET/POST, header HTTP, cookie, file upload, WebSocket, JSON body.

Fase 4 — Autenticazione e sessione. Cookie, JWT, token custom. Password reset sicuro? Session fixation possibile?

Fase 5 — Access control testing. Ogni endpoint con ruoli diversi. Controlli applicati lato server?

Fase 6 — Workflow business logic. Flussi multi-step. Saltare step. Ripetere step. Concorrenza su operazioni critiche.

Fase 7 — Payload testing. SQLi, XSS, SSTI, command injection, XXE —, path traversal in ogni input.

Fase 8 — Chaining. Information disclosure + IDOR — = data breach. XSS + CSRF = account takeover.

Errori Più Comuni #

Validazione solo lato client. Ogni controllo nel browser è bypassabile con un proxy.

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

Controlli di accesso solo nel frontend. Il pulsante “Admin” non visibile, ma l’endpoint /api/admin/users raggiungibile direttamente.

Serializzazione insicura. Usare pickle, unserialize(), ObjectInputStream su dati forniti dall’utente.

Controllo insufficiente su file upload. Solo estensione, o solo Content-Type, o solo magic byte — mai tutti e tre.

Race unsafe workflow. Operazioni critiche senza lock o atomicità.

Come Difendersi #

Validazione server-side rigorosa. Whitelist quando possibile, regex restrittive quando necessario.

Output encoding contestuale. HTML entity encoding nel body, attribute encoding negli attributi, JavaScript encoding nei blocchi JS.

Prepared statement. L’unica difesa reale contro SQL Injection. Mai concatenare input nelle query.

Object-level authorization. Ogni endpoint verifica che l’utente corrente sia autorizzato su quella specifica risorsa.

Gestione sicura file upload. Tipo MIME + magic byte + estensione. Nome randomizzato. Fuori dalla webroot.

Defense in depth. WAF + CSP + input validation + output encoding + parameterized queries + access control + monitoring.

Checklist Rapida #

• Reconnaissance: sottodomini, tecnologie, versioni
• Superficie mappata con proxy: ogni endpoint, parametro, funzionalità
• Input catalogati: GET, POST, header, cookie, JSON body, file upload
• Autenticazione analizzata: token, password reset, session management, JWT
• Access control testato con ruoli diversi su ogni endpoint
• Injection testate: 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

Approfondimenti Correlati su HackIta #

SQL Injection #

1. SQL Injection: dalla detection all’exploitation completa
2. SQL Injection classica: union-based ed error-based
3. Blind SQL Injection: boolean e time-based
4. Time-Based SQL Injection
5. SQL Injection su API REST
6. SQL Injection su ORM

Cross-Site Scripting #

1. XSS: guida completa
2. Reflected XSS
3. XSS Stored
4. DOM XSS
5. Blind XSS
6. XSS Filter Bypass
7. XSS WAF Bypass
8. XSS CSP Bypass
9. XSS Payload List

Server-Side Attacks #

1. SSRF
2. SSTI: Server-Side Template Injection
3. LFI: Local File Inclusion
4. RFI: Remote File Inclusion
5. Path Traversal
6. File Upload Vulnerabilities
7. Arbitrary File Read
8. Web Shell
9. Source Code Disclosure
10. Zip Slip

Injection & Command Execution #

1. Command Injection
2. OS Command Injection
3. LDAP Injection
4. XPath Injection
5. Expression Language Injection
6. Log Injection
7. HTTP Header Injection
8. CRLF Injection
9. XXE —

Access Control & Authentication #

1. CORS Misconfiguration
2. CSRF
3. Session Hijacking
4. OAuth Attack
5. JWT abuse
6. Brute Force
7. Clickjacking
8. Open Redirect
9. Backup Exposure
10. Business Logic Flaw
11. IDOR —

Logic Flaws & Advanced #

1. Race Condition
2. HTTP Request Smuggling
3. WebSocket Hijacking
4. Subdomain Takeover
5. Privilege Escalation Web

API #

1. GraphQL Exploitation
2. API Rate Limit Bypass
3. API Versioning Attack
4. API Modern Web Attacks: guida completa

Guide pillar correlate #

1. Auth & Access Control: guida completa
2. File Path Attacks: guida completa
3. Misc Infra Attacks: guida completa

Hub correlati #

Per penetration test professionali su infrastrutture reali, scopri i servizi di HackIta.