Server Side Request Forgery (SSRF): un’analisi tecnica

Il Server Side Request Forgery (SSRF) è una vulnerabilità critica che consente ad un aggressore di manipolare un server, inducendolo a eseguire richieste non autorizzate verso risorse sia interne che esterne. In pratica, l’attaccante costringe il server a agire come un intermediario, potenzialmente bypassando restrizioni di rete e accedendo a informazioni sensibili.

In questo articolo, ci addentreremo nella natura dell’SSRF, esplorando le sue potenziali implicazioni e discutendo le strategie per contrastarlo.

Procedo. Ecco l’HTML unico, completo e pronto da incollare nel blocco HTML di Fusion Builder.
html

Indice dei contenuti

1. Cos’è l’SSRF e perché non va confuso con il CSRF
2. Come funziona un attacco SSRF
3. I tipi di SSRF: basic, blind e semi-blind
4. SSRF e ambienti cloud: il bersaglio dei metadati
5. Le conseguenze di un attacco SSRF
6. L’SSRF nella OWASP Top 10 2025
7. Come prevenire l’SSRF
8. Conclusione

Cos’è l’SSRF e perché non va confuso con il CSRF

Il Server Side Request Forgery (SSRF), tradotto letteralmente, significa “falsificazione di richiesta dal lato server”. Con questa vulnerabilità un attaccante riesce a sfruttare un’applicazione web per costringerla a effettuare richieste di rete che non erano previste. In altre parole, non è l’attaccante a contattare direttamente la risorsa bersaglio: è il server vulnerabile a farlo per suo conto, prestandogli la propria posizione di fiducia all’interno dell’infrastruttura.

Questo dettaglio è la chiave per capire la pericolosità dell’SSRF. Un server applicativo, di norma, gode di privilegi di rete che un utente esterno non ha: può raggiungere servizi interni, database, endpoint di amministrazione e risorse cloud che il firewall perimetrale nasconde al mondo esterno. Quando l’attaccante riesce a dirottare le richieste del server, eredita di fatto quella stessa visibilità privilegiata.

Vale la pena chiarire subito una confusione molto frequente, perché i due acronimi si somigliano ma descrivono attacchi opposti. Nel CSRF (Cross-Site Request Forgery) è l’utente — più precisamente il suo browser — a essere indotto con l’inganno a inviare una richiesta verso un’applicazione presso cui è autenticato. Nell’SSRF, invece, è il server a essere manipolato per inviare richieste. Nel primo caso l’attacco parte dal lato client, nel secondo dal lato server: per questo l’SSRF apre scenari di compromissione dell’infrastruttura ben più profondi.

Come funziona un attacco SSRF

L’SSRF sfrutta generalmente input non validati provenienti dall’utente, che l’applicazione utilizza per costruire una richiesta HTTP. Se l’applicazione non verifica adeguatamente l’input, un attaccante può fornire un URL malevolo o un endpoint per indurre il server a interagire con servizi interni o con risorse esterne non previste.

Lo scenario più classico riguarda le funzionalità che accettano un URL come parametro. Si pensi a un’applicazione che permette di importare un’immagine da un indirizzo fornito dall’utente, di generare l’anteprima di un link, di validare un webhook o di recuperare un documento remoto. In tutti questi casi il server riceve un URL e va a “prenderlo” per conto dell’utente. È esattamente il comportamento che l’attaccante vuole dirottare.

Per capire la dinamica, immaginiamo una catena d’attacco descritta a parole. Un’applicazione offre una funzione di anteprima che, dato un indirizzo, ne scarica il contenuto e lo mostra. L’attaccante, invece di un sito legittimo, inserisce l’indirizzo di un servizio raggiungibile solo dall’interno della rete aziendale: un pannello di amministrazione, un’API non esposta su Internet o l’endpoint che custodisce le configurazioni dell’ambiente. Il server, fidandosi dell’input, esegue la richiesta e restituisce all’attaccante una risposta che non avrebbe mai dovuto vedere. Da lì, la superficie di attacco si allarga: mappatura dei servizi interni, accesso a interfacce di management, esfiltrazione di dati riservati.

Il punto critico è sempre lo stesso: l’applicazione tratta un input controllato dall’utente come una destinazione affidabile, senza distinguere tra ciò che è lecito raggiungere e ciò che dovrebbe restare inaccessibile.

I tipi di SSRF: basic, blind e semi-blind

Non tutti gli attacchi SSRF sono uguali. La differenza principale sta in quanto l’attaccante riesce a “vedere” del risultato della richiesta che ha forzato, e questo cambia radicalmente sia la tecnica offensiva sia la difficoltà di individuazione.

Si parla di SSRF basic (o in-band) quando la risposta della richiesta forzata torna direttamente all’attaccante, all’interno della risposta dell’applicazione. È la forma più immediata da sfruttare: l’attaccante chiede al server di raggiungere una risorsa interna e ne riceve il contenuto in chiaro. È anche la più facile da diagnosticare, perché l’effetto è visibile.

L’SSRF blind (cieco) si verifica quando il server esegue effettivamente la richiesta, ma non restituisce alcuna risposta utile all’attaccante. Non vedendo il risultato, l’attaccante deve dedurre cosa è accaduto attraverso canali indiretti: i tempi di risposta, i messaggi di errore, oppure facendo puntare il server verso un sistema sotto il proprio controllo per registrare se e quando la connessione arriva. È più subdolo da sfruttare e nettamente più difficile da rilevare in fase di test.

Esiste infine una forma intermedia, talvolta indicata come semi-blind, in cui l’attaccante non riceve il contenuto completo della risposta ma ottiene comunque qualche indizio parziale — uno stato, un frammento, una differenza di comportamento — sufficiente a confermare la vulnerabilità e a orientare i passi successivi. Comprendere queste varianti è essenziale durante un Vulnerability Assessment, perché le forme cieche richiedono metodologie di verifica più sofisticate rispetto a quelle in-band.

SSRF e ambienti cloud: il bersaglio dei metadati

È negli ambienti cloud che l’SSRF ha raggiunto la sua massima pericolosità, al punto da diventare il vettore protagonista di alcune fra le violazioni più discusse degli ultimi anni.

Le piattaforme cloud mettono a disposizione delle istanze un servizio di metadati interno: un endpoint raggiungibile esclusivamente dall’interno dell’istanza stessa, pensato per fornire informazioni di configurazione e, soprattutto, le credenziali temporanee con cui l’istanza accede agli altri servizi dell’ambiente. Quel servizio è normalmente invisibile e inattaccabile dall’esterno, perché risponde solo a chi si trova “dentro”.

Qui entra in gioco l’SSRF. Se un’applicazione ospitata sull’istanza è vulnerabile, l’attaccante può indurre il server a interrogare proprio quell’endpoint di metadati interno. Il server, che ha tutto il diritto di farlo, restituisce le informazioni e potenzialmente le credenziali associate al proprio ruolo. A quel punto l’attaccante non sta più solo leggendo dati: ha in mano chiavi valide con cui muoversi lateralmente nell’infrastruttura cloud, accedere a storage, database e altri servizi. È la trasformazione di una vulnerabilità applicativa in una compromissione dell’intero ambiente. Proprio per questo le difese specifiche per il livello cloud, che vedremo più avanti, non sono un optional ma una necessità.

Le conseguenze di un attacco SSRF

Un attacco SSRF portato a termine con successo può avere conseguenze di gravità molto diversa, che spesso si concatenano una con l’altra.

La prima è il bypass delle restrizioni di rete: l’attaccante raggiunge servizi che il perimetro di sicurezza, firewall inclusi, considerava protetti perché non esposti su Internet. Sfruttando il server come trampolino, quei servizi tornano improvvisamente a portata.

La seconda, già descritta, è l’esposizione di metadati e credenziali negli ambienti cloud, con il rischio concreto di un’escalation che parte da una singola applicazione e arriva all’intera infrastruttura.

A queste si aggiungono la possibilità di effettuare una scansione e mappatura della rete interna, individuando host e servizi attivi che dovrebbero restare nascosti, e — negli scenari più gravi, quando l’SSRF si combina con altre debolezze — l’esecuzione di comandi o l’interazione con servizi interni in modo da compromettere ulteriormente i sistemi. La caratteristica più insidiosa dell’SSRF è proprio questa: raramente è il punto di arrivo di un attacco, molto più spesso ne è il punto di partenza.

L’SSRF nella OWASP Top 10 2025

L’SSRF ha avuto un percorso significativo all’interno della classifica di riferimento per la sicurezza applicativa. Nell’edizione 2021 era entrato come categoria autonoma, segno del peso crescente che aveva assunto soprattutto con la diffusione del cloud.

Nell’edizione 2025, invece, è stato ricondotto all’interno della più ampia categoria Broken Access Control, di cui condivide la natura di fondo: in entrambi i casi il problema è che un sistema esegue un’azione, o accede a una risorsa, che non avrebbe dovuto consentire. Questa riorganizzazione non significa che l’SSRF sia meno rilevante — al contrario, riflette una lettura più matura del fenomeno come problema di controllo degli accessi. Per il quadro completo delle categorie e di cosa è cambiato rispetto al passato, abbiamo dedicato un’analisi approfondita alla OWASP Top 10 2025.

Come prevenire l’SSRF

La protezione dall’SSRF non si affida a un’unica contromisura, ma a una difesa stratificata che agisce sull’applicazione, sulla rete e sui privilegi. Di seguito le pratiche più efficaci.

La validazione rigorosa degli input è il primo presidio: ogni URL o destinazione fornita dall’utente va controllata rispetto a una whitelist di risorse esplicitamente consentite, anziché limitarsi a una blacklist di ciò che è vietato. Le blacklist sono fragili perché un attaccante può aggirarle con codifiche alternative, notazioni IP poco comuni o nomi a dominio costruiti ad arte.

Proprio per questo va considerato il rischio di DNS rebinding e dei redirect. Una whitelist che valida solo l’indirizzo iniziale può essere ingannata: l’attaccante fa risolvere il dominio in un indirizzo legittimo al momento del controllo, salvo poi farlo puntare a una risorsa interna al momento della richiesta effettiva. La difesa consiste nel validare l’indirizzo IP realmente contattato e nel non seguire automaticamente i redirect verso destinazioni non verificate.

La limitazione delle funzionalità riduce la superficie esposta: se non è strettamente necessario permettere all’utente di fornire URL arbitrari, è meglio evitarlo del tutto o vincolarlo a opzioni predefinite.

Sul fronte infrastrutturale, la segmentazione della rete è decisiva. I servizi sensibili — a partire dagli endpoint di metadati cloud e dalle interfacce di amministrazione — vanno isolati in modo che l’applicazione web non abbia alcun motivo, né alcuna possibilità, di raggiungerli. Applicare il principio del minimo privilegio significa concedere al server applicativo solo gli accessi di rete che gli servono davvero, e nulla di più.

Infine, restano fondamentali gli aggiornamenti e il patching costanti di applicazioni, librerie e dipendenze, dato che molte vulnerabilità SSRF emergono in componenti di terze parti e vengono corrette nelle versioni successive. La verifica sistematica di tutti questi aspetti è esattamente ciò che un Vulnerability Assessment condotto da specialisti è in grado di portare alla luce prima che lo faccia un attaccante.

Conclusione

L’SSRF rappresenta una minaccia significativa per la sicurezza delle applicazioni web, e la sua evoluzione — dall’ingresso autonomo nella classifica del 2021 alla riconduzione sotto Broken Access Control nel 2025 — racconta una vulnerabilità che è cresciuta di pari passo con l’adozione del cloud. La sua pericolosità non sta tanto nel singolo accesso non autorizzato, quanto nella capacità di trasformarsi nel primo anello di una catena che può arrivare a compromettere un’intera infrastruttura.

Con una comprensione approfondita del meccanismo e l’adozione di pratiche solide di sicurezza — validazione rigorosa degli input, segmentazione della rete, minimo privilegio e patching costante — il rischio associato può essere ridotto in modo concreto. La chiave sta nell’essere proattivi: conoscere le vulnerabilità, verificarle prima che lo facciano gli attaccanti e mettere in atto misure di protezione efficaci.s