Nella SSRF l'attaccante convince il server a fare una richiesta HTTP per suo conto verso una destinazione a sua scelta – tipicamente interna e altrimenti irraggiungibile. Il classico: una funzione "importa immagine da URL" a cui passi non un'immagine ma http://169.254.169.254/..., l'endpoint dei metadati cloud, da cui si estraggono le credenziali IAM dell'istanza. È il vettore del breach Capital One (2019).
Perché è insidiosa: il server è "dentro", oltre il firewall, e parla con servizi che si fidano della rete interna – database, API amministrative, l'endpoint metadati. La SSRF trasforma una feature innocua in un grimaldello verso il cuore dell'infrastruttura.
Le difese, a livello di codice e di rete:
- allowlist delle destinazioni permesse (non blocklist – gli attaccanti aggirano le blocklist con redirect, IP in decimale, DNS rebinding)
- blocca gli indirizzi interni: 169.254.169.254, IP privati (RFC 1918), localhost – e rifai la validazione dopo aver risolto il DNS
- IMDSv2 sui cloud (l'endpoint metadati che richiede un token, non più raggiungibile con una GET cieca)
- egress ristretto dal server, e un WAF come rete di sicurezza per i pattern noti
È salita nella OWASP Top 10 proprio per l'era cloud: dove tutto è un'API interna, far fare al server la richiesta sbagliata vale oro.