Quando un'applicazione web deve recuperare un'immagine da un URL, leggere informazioni da un servizio esterno o interrogare un'altra API, spesso effettua una richiesta HTTP direttamente dal proprio server.
È una funzionalità comune e, nella maggior parte dei casi, perfettamente legittima. Il problema nasce quando l'applicazione permette a un utente di influenzare la destinazione di quella richiesta senza controllare adeguatamente dove il server può collegarsi.
In queste circostanze può verificarsi una vulnerabilità chiamata SSRF (Server-Side Request Forgery), ovvero falsificazione delle richieste lato server.
Si tratta di un problema importante perché il server potrebbe raggiungere risorse che non sono accessibili direttamente da Internet, come servizi interni, interfacce amministrative o endpoint utilizzati dall'infrastruttura cloud.
Vediamo come funziona una SSRF, quali rischi comporta e come ridurre la probabilità che un'applicazione diventi un punto d'ingresso verso sistemi interni.
Che cos'è una vulnerabilità SSRF?
Una SSRF si verifica quando un attaccante riesce a influenzare una richiesta generata dal server dell'applicazione, inducendolo a contattare una destinazione non prevista o non autorizzata.
Immaginiamo un servizio che consenta di inserire l'URL di un'immagine per importarla automaticamente nel proprio profilo.
L'applicazione riceve l'indirizzo, lo interpreta e scarica il contenuto dal server remoto. Se non controlla adeguatamente la destinazione, potrebbe essere indotta a effettuare richieste verso altri sistemi.
Il punto fondamentale è che la richiesta parte dall'infrastruttura dell'applicazione, non necessariamente dal browser dell'utente.
Questo cambia le possibilità di accesso: il server potrebbe trovarsi su una rete che gli consente di raggiungere indirizzi e servizi non disponibili al pubblico.
Un esempio pratico di SSRF
Consideriamo un endpoint che permette di recuperare un'immagine:
POST /api/import-image
Content-Type: application/json
{
"url": "https://example.com/image.jpg"
}
L'applicazione prende il valore di url ed esegue una richiesta HTTP per scaricare il file.
In un'implementazione vulnerabile, il server potrebbe accettare qualsiasi destinazione raggiungibile, anche quando l'URL fornito dall'utente punta a un servizio interno.
Il difetto non consiste semplicemente nel permettere di scaricare un'immagine da Internet. Consiste nel delegare all'utente la scelta della destinazione di rete senza applicare restrizioni sufficienti.
Un controllo basato esclusivamente sul fatto che l'input inizi con https:// non è adeguato: anche una destinazione interna potrebbe essere raggiunta utilizzando HTTPS.
Quali rischi comporta una SSRF?
L'impatto dipende dai privilegi di rete del server, dalle funzionalità raggiungibili e da ciò che l'applicazione restituisce all'utente.
1. Accesso a servizi interni
Molte infrastrutture dispongono di servizi non pubblici, accessibili soltanto dalla rete interna o da determinati server.
Se l'applicazione vulnerabile può raggiungerli, potrebbe essere utilizzata per inviare richieste che normalmente un utente esterno non potrebbe effettuare direttamente.
La presenza di una SSRF non implica automaticamente che questi servizi siano compromessi: l'esito dipende anche dai controlli di autenticazione, dalla segmentazione della rete e dai permessi disponibili.
2. Accesso a informazioni riservate nel cloud
Alcuni ambienti cloud espongono servizi interni che forniscono informazioni sull'identità dell'istanza o credenziali temporanee per l'accesso ad altre risorse.
Se un'applicazione vulnerabile può raggiungere tali endpoint e non esistono protezioni adeguate, una SSRF potrebbe contribuire all'esposizione di informazioni sensibili o all'abuso dei privilegi assegnati all'istanza.
Per questo è importante limitare sia la possibilità di effettuare richieste arbitrarie sia i privilegi concessi al server.
3. Interrogazione di pannelli e API non pubbliche
Un'applicazione potrebbe essere in grado di contattare dashboard amministrative, sistemi di monitoraggio o API interne.
Anche quando queste risorse richiedono autenticazione, la possibilità di raggiungerle attraverso un server vulnerabile può ampliare la superficie d'attacco.
4. Esposizione di informazioni
In alcune situazioni, il contenuto recuperato viene restituito direttamente all'utente. In altre, l'applicazione mostra soltanto un messaggio di errore, ma può comunque rivelare informazioni attraverso i tempi di risposta o altri comportamenti osservabili.
Le SSRF vengono spesso distinte in base a quanto l'attaccante riesce a osservare. Le forme in-band restituiscono informazioni attraverso la risposta dell'applicazione; quelle blind non mostrano direttamente il contenuto recuperato, ma possono essere rilevate attraverso effetti indiretti.
Una SSRF blind non è necessariamente innocua: l'impatto dipende dalle richieste che il server può eseguire e dagli effetti che queste possono produrre.
Perché i controlli superficiali non bastano
Uno degli errori più comuni è controllare soltanto la forma dell'URL.
Per esempio, un'applicazione potrebbe consentire qualsiasi indirizzo che utilizzi HTTPS oppure bloccare alcuni nomi di host conosciuti, senza verificare in modo completo la destinazione effettiva della connessione.
Questo approccio può fallire in presenza di:
- indirizzi IP interni o riservati;
- nomi DNS che risolvono verso indirizzi non consentiti;
- cambiamenti della risoluzione DNS tra la verifica e la connessione;
- redirect verso destinazioni differenti;
- formati dell'URL interpretati in modo inatteso;
- differenze tra il componente che valida l'URL e quello che effettua la richiesta.
Per esempio, un dominio inizialmente associato a un indirizzo pubblico potrebbe risolvere successivamente verso un indirizzo interno. Questo tipo di situazione viene spesso associato a problemi di DNS rebinding o a verifiche DNS non sufficientemente robuste.
Non significa che ogni URL inserito dall'utente sia pericoloso, ma che la destinazione deve essere verificata in modo coerente con il modo in cui la richiesta verrà effettivamente eseguita.
Come prevenire una vulnerabilità SSRF
La difesa più efficace consiste nel ridurre al minimo le destinazioni che l'applicazione può raggiungere e nel verificare ogni richiesta in modo coerente.
1. Preferire una allowlist di destinazioni
Se la funzionalità deve recuperare dati da un insieme limitato di servizi, è preferibile autorizzare esplicitamente quei domini o endpoint.
Per esempio, un servizio che importa contenuti da una piattaforma specifica non dovrebbe necessariamente accettare qualsiasi URL Internet.
Una allowlist ben progettata riduce il numero di destinazioni potenzialmente pericolose, ma deve considerare anche sottodomini, risoluzione DNS, redirect e modalità effettive di connessione.
2. Validare indirizzi e destinazioni
Quando non è possibile usare una allowlist ristretta, l'applicazione deve verificare attentamente la destinazione e impedire le connessioni verso reti o indirizzi non consentiti.
La verifica deve comprendere gli indirizzi IPv4 e IPv6, oltre alle modalità con cui vengono interpretati i nomi host.
È importante evitare controlli improvvisati basati soltanto su confronti testuali.
3. Gestire i redirect con attenzione
Una destinazione iniziale consentita potrebbe rispondere con un redirect verso un altro indirizzo.
Se l'applicazione segue automaticamente ogni redirect, un controllo iniziale potrebbe essere aggirato.
Una soluzione è disabilitare i redirect quando non sono necessari oppure verificare nuovamente ogni destinazione prima di seguirla.
4. Limitare il traffico in uscita
La difesa non dovrebbe dipendere esclusivamente dal codice applicativo.
Firewall, regole di rete e controlli sull'egress possono impedire al server di raggiungere servizi interni o destinazioni non necessarie.
Per esempio, un servizio che deve scaricare immagini pubbliche potrebbe non avere alcun motivo per collegarsi alle interfacce amministrative o ai database interni.
La segmentazione della rete limita l'impatto di eventuali errori nell'applicazione.
5. Ridurre i privilegi del server
Un'applicazione dovrebbe disporre soltanto dei permessi necessari al proprio funzionamento.
In ambienti cloud, questo significa anche evitare ruoli troppo ampi e utilizzare credenziali temporanee e limitate alle risorse effettivamente necessarie.
In questo modo, anche se una vulnerabilità consente di raggiungere un servizio interno, le possibilità di sfruttamento possono essere ridotte.
6. Applicare limiti alle richieste
Timeout, limiti sulle dimensioni delle risposte, restrizioni sui protocolli e controlli sul numero di redirect aiutano a ridurre ulteriori rischi.
Queste misure non sostituiscono la validazione della destinazione, ma rendono la funzionalità di recupero remoto più controllabile.
Come verificare se un'applicazione è esposta a SSRF
La verifica deve partire dalle funzionalità che effettuano richieste verso URL forniti dall'utente o verso destinazioni determinate da dati esterni.
Tra gli esempi da esaminare ci sono:
- importazione di immagini e documenti;
- anteprime automatiche di link;
- webhook configurabili;
- generatori di PDF che recuperano pagine web;
- integrazioni con API di terze parti;
- strumenti di diagnostica che interrogano indirizzi;
- servizi che recuperano feed, contenuti o metadati.
Durante un test autorizzato, è utile verificare che l'applicazione accetti soltanto destinazioni previste, che gestisca correttamente i redirect e che non possa raggiungere servizi interni non autorizzati.
È preferibile utilizzare endpoint di test controllati e ambienti isolati, evitando di interrogare sistemi interni o infrastrutture di terzi senza autorizzazione.
Una semplice scansione esterna può individuare alcuni segnali, ma non è sempre sufficiente a confermare o escludere una SSRF: spesso è necessario esaminare il comportamento dell'applicazione e la logica che effettua le richieste.
SSRF e sicurezza dell'architettura
La SSRF dimostra perché la sicurezza non dipende soltanto da ciò che è visibile su Internet.
Un'applicazione pubblica può diventare un ponte verso risorse che, prese singolarmente, non sono raggiungibili dall'esterno. Per questo motivo è importante valutare insieme codice applicativo, permessi, segmentazione della rete e configurazione dei servizi.
Conclusione
La SSRF è una vulnerabilità che può trasformare una normale funzionalità di recupero remoto in un punto di accesso verso risorse non previste. Le difese più importanti sono la validazione rigorosa delle destinazioni, le restrizioni sul traffico in uscita e la riduzione dei privilegi del server.
Con MiHakero puoi analizzare la superficie esposta dei tuoi domini, delle applicazioni web, delle API e dei servizi pubblici, individuando configurazioni e problemi rilevabili dall'esterno. Per verificare in modo completo una possibile SSRF, l'analisi va integrata con test autorizzati della logica applicativa e delle connessioni che il server può effettuare.