La Server-Side Request Forgery (SSRF) è una vulnerabilità che permette a un attaccante di indurre il server applicativo a effettuare richieste HTTP (o di altro protocollo) verso destinazioni arbitrarie — interne o esterne — scelte dall’attaccante. Il server diventa un proxy involontario: poiché le richieste partono dall’interno dell’infrastruttura, raggiungono risorse normalmente inaccessibili dall’esterno, come servizi interni, database, metadata endpoint cloud e sistemi protetti da firewall perimetrale.
Meccanismo
L’applicazione riceve un URL dall’utente e lo usa per effettuare una richiesta lato server:
# Funzionalità legittima: carica un'immagine da URL
GET /preview?url=https://esempio.com/immagine.jpg
# Input malevolo: accede al metadata service AWS
GET /preview?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/Il server effettua la richiesta verso 169.254.169.254 — l’endpoint di metadati AWS raggiungibile solo dall’interno dell’istanza EC2 — e restituisce le credenziali IAM temporanee dell’istanza all’attaccante.
Impatto in ambienti cloud
L’SSRF è particolarmente devastante in ambienti cloud per il metadata service: ogni istanza VM su AWS, Azure e GCP ha un endpoint di metadati interno non autenticato che espone le credenziali temporanee del ruolo IAM associato all’istanza. Con SSRF su un’applicazione cloud:
- L’attaccante recupera le credenziali IAM dal metadata service
- Usa le credenziali per autenticarsi all’API AWS/Azure/GCP dall’esterno
- Esegue operazioni con i permessi del ruolo dell’applicazione — potenzialmente leggere S3, accedere a RDS, elencare risorse
IMDSv2 (AWS Instance Metadata Service v2) mitiga questo vettore richiedendo una sessione pre-autenticata con un token, ottenibile solo tramite richiesta PUT iniziale — che le SSRF semplici (GET-only) non possono effettuare.
Capital One breach (2019): il più noto attacco SSRF documentato. Una SSRF nel WAF mal configurato di Capital One ha permesso di accedere al metadata service EC2, ottenere credenziali IAM con permessi eccessivi, e scaricare oltre 100 milioni di record da S3.
Varianti
SSRF verso servizi interni: accedere a servizi non esposti su Internet — Redis, Elasticsearch, MongoDB, Kubernetes API server — che girano su porte interne senza autenticazione perché “non raggiungibili dall’esterno”. Esempio: http://redis.interno:6379/ — Redis risponde a richieste HTTP con un errore che rivela la versione e i comandi supportati.
SSRF blind: l’applicazione non restituisce la risposta della richiesta interna, ma l’attaccante può inferire informazioni dall’esistenza della risposta (port scanning interno tramite differenze di timing o codici di errore).
SSRF con protocolli non-HTTP: alcuni parser URL supportano file://, dict://, gopher://, ftp:// — usabili per leggere file locali, inviare comandi arbitrari a servizi come Redis o SMTP.
Difese
Allowlist degli URL: se l’applicazione deve accedere solo a URL specifici, validarli contro una whitelist di domini e IP. Non usare blocklist di IP privati — troppo facile aggirare con reindirizzamenti, IPv6, encoding.
Blocco a livello di rete: i firewall interni o le security group cloud devono impedire alle istanze applicative di accedere ai metadata endpoint e ai servizi interni non necessari — difesa in profondità che limita l’impatto anche se la SSRF è sfruttata.
Risposta senza redirect: non seguire automaticamente i redirect HTTP nelle richieste server-side — i redirect possono portare da URL apparentemente validi a destinazioni interne.
IMDSv2 obbligatorio: nei deployment AWS, forzare IMDSv2 per bloccare la classe più impattante di SSRF cloud.