Il Server-Side Request Forgery è una tecnica di exploit che permette a un attaccante di spingere un server a effettuare richieste HTTP verso destinazioni arbitrarie. Cosa significa in pratica? In sostanza, si verifica quando un'applicazione web recupera una risorsa remota senza verificare e validare l'URL fornito dall'utente.
L'SSRF è stato il punto di ingresso per alcune delle violazioni più gravi degli ultimi anni, inclusa la violazione di Capital One che ha esposto oltre 100 milioni di record.

Come funziona

Quando un'applicazione web accetta un URL dall'utente e lo recupera lato server, si creano le condizioni per l'SSRF. Esempi comuni:

  • Importazione di immagini da un URL
  • Webhook e callback configurabili
  • Parser di feed RSS/XML
  • Generatori di PDF che caricano risorse esterne
  • Proxy e abbreviatori di URL

Il server, fidandosi dell'input, esegue la richiesta. Se l'attaccante fornisce un URL che punta a risorse interne, il server diventa un proxy involontario verso l'infrastruttura protetta.

Legitimate request:
POST /api/fetch-image
{"url": "https://example.com/logo.png"}

Malicious request:
POST /api/fetch-image
{"url": "http://169.254.169.254/latest/meta-data/"}

Perché 169.254.169.254 è pericoloso

Quell'indirizzo IP è il servizio di metadati dei provider cloud (AWS, GCP, Azure). Da un'istanza EC2 è raggiungibile solo internamente e restituisce informazioni sensibili: credenziali IAM temporanee, chiavi API, token di sessione.

Un SSRF che raggiunge il servizio di metadati può estrarre credenziali altamente privilegiate. Da lì, l'attaccante può accedere a bucket S3, database RDS, secret manager. Il perimetro di rete crolla.

AWS ha introdotto IMDSv2, che richiede un token per accedere ai metadati, ma molte istanze utilizzano ancora la v1 o hanno la v2 configurata come opzionale.

Bypass dei filtri

Il primo istinto degli sviluppatori è filtrare gli URL. Bloccare localhost, 127.0.0.1, indirizzi privati. Funziona? Raramente.

DNS Rebinding: l'attaccante controlla un dominio che inizialmente risolve a un IP pubblico (superando il filtro) e poi cambia la sua risoluzione a un IP interno. Il server ha già validato l'URL e la richiesta viene inviata all'indirizzo interno.

Codifica e rappresentazioni alternative:

  • 127.0.0.1 diventa 2130706433 (decimale)
  • 127.0.0.1 diventa 0x7f000001 (esadecimale)
  • localhost diventa localtest.me (un dominio pubblico che risolve a 127.0.0.1)
  • IPv6: [::] è equivalente a 0.0.0.0

Catena di redirect: l'URL punta a un server controllato dall'attaccante che risponde con un redirect 302 verso la destinazione interna. Il filtro valida solo l'URL iniziale.

Incoerenze del parser URL: differenze tra il modo in cui il filtro analizza l'URL e il modo in cui la libreria HTTP lo interpreta. Caratteri come @, # e molteplici livelli di codifica possono confondere la validazione.

http://attacker.com#@internal-server/admin
http://internal-server:[email protected]/
http://attacker.com/?url=http://internal-server/

Da SSRF a RCE

L'SSRF diventa critico quando raggiunge servizi interni senza autenticazione:

Redis (porta 6379): molte installazioni non richiedono una password. Con il protocollo RESP, è possibile iniettare comandi attraverso una richiesta HTTP malformata. Scrivere una chiave con un cron job o una chiave SSH porta a RCE.

Memcached (porta 11211): stesso principio. Iniezione di dati serializzati che l'applicazione deserializzerà in seguito.

Docker API (porta 2375): se esposta senza TLS, permette di creare container privilegiati, montare il filesystem dell'host ed eseguire comandi come root.

Consul, etcd, Kubernetes API: i servizi di orchestrazione sono spesso raggiungibili senza autenticazione dalla rete interna. Lettura di segreti, configurazioni e possibilità di deployment malevoli.

Elasticsearch (porta 9200): lettura e scrittura di indici, potenziale accesso a log e dati sensibili.

Testing

Per esaminare in modo controllato le richieste che contengono URL modificabili dall’utente, un proxy HTTP consente di osservare parametri, redirect e risposte. Il confronto tra Burp Suite e OWASP ZAP aiuta a scegliere uno strumento per questa attività.

L'identificazione di SSRF richiede un server per ricevere i callback. Burp Collaborator svolge questo compito: genera URL univoci e ti notifica quando ricevono richieste.

Alternative gratuite:

  • interactsh (ProjectDiscovery)
  • webhook.site
  • requestbin.com

Parametri degni di test:

  • Qualsiasi campo che accetti un URL
  • Header come X-Forwarded-For, Referer (in alcuni casi elaborati lato server)
  • Parametri nascosti scoperti tramite fuzzing

Payload iniziali:

http://collaborator-url/
http://169.254.169.254/latest/meta-data/
http://[::]:22/
http://127.0.0.1:6379/

Mitigazione

Whitelist, non blacklist: a livello di firewall è necessario imporre policy deny-all o ACL molto restrittive per bloccare tutto il traffico non essenziale.

Validazione post-risoluzione DNS: controlla l'IP di destinazione dopo la risoluzione DNS, non solo l'URL di input. Blocca i range privati (10.x, 172.16-31.x, 192.168.x, 169.254.x, 127.x).

Disabilita i redirect: se non necessari, impedisci alla libreria HTTP di seguire automaticamente i redirect.

Segmentazione di rete: isola i server applicativi dai servizi interni critici. Il servizio di metadata dovrebbe essere raggiungibile solo dalle istanze che ne hanno effettivamente bisogno.

IMDSv2 su AWS: imposta l'accesso basato su token ai metadati. Non lasciare la v1 come fallback.

Timeout e rate limiting: limita il numero di richieste in uscita e il tempo di attesa. Questo rallenta lo sfruttamento e rende più visibili i tentativi di scansione.

Riferimenti