Ti è mai capitato di cliccare su un link che sembrava appartenere a un sito affidabile e ritrovarti improvvisamente su una pagina completamente diversa?
A volte è un comportamento normale.
I siti web utilizzano continuamente i reindirizzamenti per accompagnare gli utenti dopo un login, spostarli verso una nuova pagina oppure gestire collegamenti che non esistono più.
Il problema nasce quando un'applicazione permette a chiunque di decidere liberamente dove inviare il visitatore.
Questa situazione può dare origine a una vulnerabilità chiamata Open Redirect.
Non è necessariamente un problema che consente di compromettere direttamente un server, ma può rendere molto più credibili campagne di phishing e altri attacchi.
Che cos'è un Open Redirect?
Un Open Redirect, o reindirizzamento aperto, è una vulnerabilità che si verifica quando un'applicazione accetta una destinazione di reindirizzamento non attendibile senza verificarla adeguatamente.
Immaginiamo che un sito utilizzi questo indirizzo:
https://example.com/redirect?url=/dashboard
L'applicazione legge il parametro url e reindirizza il visitatore alla pagina richiesta.
Fin qui non c'è necessariamente nulla di sbagliato.
Il problema nasce se il sistema accetta anche un indirizzo esterno arbitrario:
https://example.com/redirect?url=https://sito-esterno.example
Se il server esegue il reindirizzamento senza controlli, il visitatore parte da un dominio apparentemente affidabile e viene trasferito verso una destinazione scelta da chi ha creato il link.
Perché un Open Redirect può essere pericoloso?
Il rischio principale riguarda la fiducia che gli utenti ripongono nei domini conosciuti.
Un attaccante potrebbe costruire un link che inizia con il dominio di un servizio legittimo.
La persona che riceve il collegamento potrebbe riconoscere il nome del sito e considerarlo sicuro.
Dopo il clic, però, il browser viene reindirizzato verso una pagina fraudolenta.
Questa tecnica può essere utilizzata per rendere più convincenti tentativi di phishing.
Per esempio, un utente potrebbe ricevere un messaggio che sembra provenire da un servizio che utilizza abitualmente.
Il collegamento contiene effettivamente il dominio originale, ma sfrutta un parametro di reindirizzamento per condurre a una pagina controllata dall'attaccante.
Il risultato è un passaggio apparentemente innocuo che può aumentare la credibilità dell'inganno.
Come funziona tecnicamente un reindirizzamento HTTP?
I server web possono utilizzare risposte HTTP con codici di stato della famiglia 3xx per indicare al browser che una risorsa si trova altrove.
Un esempio semplificato:
HTTP/1.1 302 Found
Location: https://example.com/dashboard
Il browser riceve la risposta e segue la destinazione indicata nell'header Location.
Il meccanismo è legittimo e fondamentale per il funzionamento del web.
La vulnerabilità non dipende quindi dal codice HTTP 302 in sé.
Dipende dal fatto che l'applicazione possa inserire nell'header Location una destinazione controllata da un soggetto non attendibile.
Un esempio di Open Redirect in PHP
Consideriamo questo codice:
<?php
$destination = $_GET['next'] ?? '/';
header('Location: ' . $destination);
exit;
Il parametro next viene letto direttamente dalla richiesta e utilizzato per generare il reindirizzamento.
Un utente potrebbe richiamare:
https://example.com/login?next=https://sito-esterno.example
Se l'applicazione raggiunge quel codice, potrebbe reindirizzare il browser verso il dominio esterno.
Il problema è l'assenza di una verifica sulla destinazione.
Dove si trovano più spesso gli Open Redirect?
I reindirizzamenti dinamici vengono utilizzati in numerose funzionalità.
Pagine di login
Dopo l'autenticazione, un sito può riportare l'utente alla pagina che stava visitando.
Per esempio:
/login?next=/area-riservata
Se il parametro next non viene verificato, potrebbe essere manipolato.
Logout
Alcune applicazioni consentono di specificare una pagina verso cui indirizzare l'utente dopo la disconnessione.
Anche questa funzionalità richiede controlli.
Link di tracciamento
Piattaforme di marketing e sistemi di analisi utilizzano talvolta URL intermedi per registrare un clic prima di trasferire il visitatore alla destinazione finale.
Sistemi di autenticazione federata
Nei flussi OAuth e OpenID Connect, gli URI di reindirizzamento rivestono un ruolo particolarmente delicato.
La loro validazione deve rispettare le regole del protocollo e le configurazioni del provider.
Un controllo troppo permissivo può contribuire a problemi di sicurezza più gravi rispetto a un semplice reindirizzamento indesiderato.
Open Redirect e phishing: qual è il collegamento?
Immaginiamo che un utente riceva questa comunicazione:
Per continuare a utilizzare il tuo account, verifica le impostazioni di sicurezza attraverso il collegamento indicato.
Il link inizia con il dominio di una piattaforma realmente conosciuta.
L'utente lo apre, ma il browser viene immediatamente trasferito verso una pagina che imita quella originale.
La pagina fraudolenta potrebbe richiedere credenziali, codici temporanei o altre informazioni.
L'Open Redirect non ruba direttamente questi dati: facilita il passaggio verso un sito malevolo sfruttando la reputazione di quello legittimo.
È questa distinzione che rende importante valutare il contesto.
Come prevenire gli Open Redirect
La soluzione più robusta è evitare, quando possibile, che l'utente possa specificare un URL arbitrario.
Utilizzare destinazioni predefinite
Se dopo il login sono previste soltanto alcune pagine, puoi rappresentarle attraverso identificatori interni.
Per esempio:
<?php
$destinations = [
'home' => '/dashboard',
'profile' => '/account/profile',
'orders' => '/account/orders',
];
$key = $_GET['next'] ?? 'home';
$destination = $destinations[$key]
?? $destinations['home'];
header('Location: ' . $destination, true, 302);
exit;
In questo caso, il parametro non contiene direttamente un URL.
L'applicazione sceglie la destinazione tra quelle autorizzate.
È un approccio semplice e particolarmente efficace quando le pagine possibili sono note.
Consentire soltanto percorsi interni validati
Se è necessario gestire percorsi dinamici, bisogna verificare che appartengano realmente all'applicazione.
Non basta controllare che una stringa inizi con /, perché alcune forme di URL, come quelle che iniziano con //, possono essere interpretate dal browser come destinazioni esterne.
Occorre anche considerare codifiche, normalizzazione e modalità con cui il browser interpreta gli indirizzi.
Per applicazioni complesse, è preferibile utilizzare funzionalità di validazione già disponibili nel framework adottato.
Usare una allowlist per i domini esterni
Se l'applicazione deve reindirizzare verso servizi esterni specifici, può utilizzare un elenco esplicito di destinazioni consentite.
Per esempio:
accounts.example.com
support.example.com
Il controllo dovrebbe confrontare l'hostname effettivamente interpretato da un parser URL affidabile, oltre a verificare schema e altre proprietà necessarie.
Una semplice ricerca testuale del nome del dominio non è sufficiente.
Perché controllare soltanto la presenza del dominio non basta?
Immaginiamo di voler consentire i reindirizzamenti verso:
example.com
Un controllo ingenuo potrebbe verificare soltanto che la stringa contenga example.com.
Ma questo indirizzo è diverso:
https://example.com.sito-esterno.example
Il dominio effettivo non è example.com.
Il nome compare soltanto all'interno di un hostname più lungo.
Per questo motivo, la validazione deve interpretare correttamente l'URL e confrontare il dominio reale, non limitarsi a cercare una sequenza di caratteri.
Come verificare se un sito presenta un Open Redirect?
Se gestisci un'applicazione, puoi iniziare identificando le funzionalità che effettuano reindirizzamenti.
Cerca parametri come:
nextreturnreturnUrlredirectredirect_uridestination
Questi nomi non indicano automaticamente una vulnerabilità, ma possono aiutarti a individuare i punti da controllare.
In un ambiente di test autorizzato, verifica se l'applicazione accetta destinazioni esterne non previste.
Controlla sia gli header HTTP restituiti dal server sia il comportamento effettivo del browser.
Alcuni reindirizzamenti vengono infatti eseguiti lato client attraverso JavaScript.
È importante testare anche URL codificati e varianti sintattiche, perché i controlli superficiali possono essere aggirati attraverso differenze di interpretazione.
Tutti i reindirizzamenti esterni sono vulnerabilità?
No.
Molte applicazioni hanno motivi legittimi per inviare gli utenti verso altri domini.
Pensiamo ai sistemi di pagamento, ai provider di autenticazione o ai servizi di assistenza esterni.
Il problema non è il reindirizzamento verso un altro sito, ma la possibilità di manipolare liberamente la destinazione quando non dovrebbe essere consentito.
Un'applicazione può gestire reindirizzamenti esterni in modo sicuro attraverso destinazioni predefinite, allowlist e controlli coerenti con il proprio flusso.
Quanto è grave un Open Redirect?
La gravità dipende dal contesto.
Un reindirizzamento aperto isolato potrebbe avere un impatto limitato.
In altri scenari, però, può essere utilizzato per rendere più credibili campagne di phishing oppure contribuire a vulnerabilità che coinvolgono flussi di autenticazione.
È quindi importante non assegnare automaticamente la stessa priorità a tutti i casi.
Bisogna considerare dove si trova il reindirizzamento, come viene utilizzato e quali altri meccanismi dell'applicazione potrebbero essere coinvolti.
Conclusione
Gli Open Redirect dimostrano che anche una funzionalità apparentemente semplice può creare problemi quando i dati forniti dall'utente vengono considerati affidabili senza verifiche.
Un reindirizzamento non dovrebbe mai permettere destinazioni arbitrarie se l'applicazione non ne ha realmente bisogno.
La soluzione migliore consiste nel limitare le destinazioni consentite e validare gli URL in modo rigoroso, evitando controlli basati su semplici confronti testuali.
Con MiHakero puoi affiancare alla revisione del codice un monitoraggio delle esposizioni esterne e dei problemi rilevabili sui tuoi servizi pubblici. Per verificare vulnerabilità applicative come gli Open Redirect, resta importante eseguire test specifici e autorizzati sui flussi interessati.