SSRF Spiegato: Cos'è il Server-Side Request Forgery e Come Difendersi

L'SSRF (Server-Side Request Forgery) è una delle vulnerabilità più pericolose nei moderni ambienti cloud. OWASP la include nel Top 10 2021 con una categoria dedicata, riconoscendo la sua crescente rilevanza con la diffusione delle architetture cloud e microservizi.

Come funziona

L'SSRF sfrutta una funzionalità comune nelle applicazioni web: la capacità di fare richieste HTTP verso URL esterne (per recuperare immagini, feed RSS, webhook, dati da API esterne, ecc.).

L'attaccante manipola questa funzionalità per far puntare il server verso URL che non dovrebbero essere accessibili:

Scenario base: Un'applicazione ha una funzione "anteprima URL":

POST /preview
{"url": "https://example.com/image.jpg"}

L'attaccante invia:

POST /preview
{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}

In un ambiente AWS, questo URL è il servizio di metadati dell'istanza EC2. Risponde con le credenziali IAM dell'istanza — permettendo all'attaccante di assumere l'identità del ruolo AWS e accedere a tutti i servizi che quel ruolo può usare.

Perché è particolarmente pericoloso nel cloud

Nei deployment cloud (AWS, Azure, GCP), ogni istanza ha accesso a un endpoint di metadati che espone:

• Credenziali IAM temporanee
• Token di accesso
• Configurazioni dell'istanza

L'attacco SSRF verso questi endpoint è una delle tecniche più comuni per la compromise iniziale in ambienti cloud. Da lì, un attaccante può scalare i privilegi e muoversi lateralmente nell'infrastruttura.

AWS: http://169.254.169.254/latest/meta-data/ GCP: http://metadata.google.internal/computeMetadata/v1/ Azure: http://169.254.169.254/metadata/instance

Varianti dell'attacco

SSRF verso servizi interni

Il server fa da proxy per accedere a servizi interni non esposti pubblicamente:

• Database (MySQL, Redis, Elasticsearch sulla porta default)
• Pannelli di amministrazione
• Microservizi interni
• Server di sviluppo

SSRF cieco (Blind SSRF)

Il server non mostra la risposta all'attaccante, ma esegue comunque la richiesta. L'attaccante può comunque:

• Enumerare gli host interni (se il server risponde diversamente per host raggiungibili vs. non raggiungibili)
• Inviare dati a sistemi controllati dall'attaccante per confermare la vulnerabilità
• Triggerare azioni su servizi interni (es. webhook)

SSRF con redirect

L'URL fornita dall'attaccante reindirizza verso un'URL interna. Se l'applicazione segue i redirect, la difesa basata sulla validazione dell'URL originale viene bypassata.

Come si difende

Validazione delle URL

Non fidarti dell'URL fornita dall'utente. Prima di fare una richiesta, verifica:

• Il dominio è nella allowlist?
• L'IP risultante è in un range privato? (127.0.0.1, 10.x.x.x, 172.16-31.x.x, 192.168.x.x, 169.254.x.x)
• Il protocollo è HTTP/HTTPS? (blocca file://, gopher://, dict://)

Risoluzione DNS e verifica

Risolvi il dominio in indirizzo IP e verifica DOPO la risoluzione che l'IP non sia interno. Attenzione alla DNS rebinding attack.

Segmentazione di rete

Il server che fa richieste esterne non dovrebbe avere accesso ai servizi interni di database o ai servizi cloud interni. Una corretta segmentazione di rete limita drasticamente il danno.

IMDSv2 in AWS

Usa IMDSv2 (Instance Metadata Service v2) che richiede un token di sessione, rendendo gli attacchi SSRF verso i metadati EC2 molto più difficili.

Blocco a livello di firewall

Configura regole di firewall per bloccare le richieste in uscita dal server verso indirizzi RFC 1918 (privati) e i range di link-local.

L'SSRF è una vulnerabilità spesso sottovalutata perché sembra un problema "secondario" rispetto a SQL injection o XSS. Ma nei moderni ambienti cloud, può essere il punto di partenza per una compromissione completa dell'infrastruttura.