Open Redirect
Cosa sono, dove trovarli e rimedi.
OWASP
Parameter-Based Open Redirects
I siti spesso usano parametri URL per reindirizzare gli utenti ad un URL prestabilito, senza richiedere l'intervento dell'utente.
Questo può essere utile, ma può anche causare open redirects, che si hanno quando un utente malintezionato è capace di modificare il valore di questo parametro per reindirizzare l'utente fuori dal sito di partenza.
Per esempio, un utente non loggato prova ad accedere alla sua dashboard nel sito hayden.com. Siccome non è loggato, il sito prima manda l'utente nella pagina di login, ma ha anche bisogno di ricordare la pagina a cui l'utente voleva accedere dall'inizio, viene quindi usato un parametro URL, e il link potrebbe essere qualcosa come: hayden.com/login?redirect=hayden.com/dashboard.
Durante un attacco di open redirect, un utente malintenzionato può ingannare un altro utente nel visitare un sito esterno fornendo un URL che parte dal sito legittimo, ma che lo reindirizza su un altro sito, per esempio con: hayden.com/login?redirect=hacker.com.
In questo modo, l'utente viene ingannato perché crede di trovarsi sul sito legittimo e vi inserisce le sue credenziali, tuttavia il sito hacker.com potrebbe essere un sito "spoofed" (ossia un sito simile o uguale ad un altro, che però non è l'originale), dando così le sue informazioni all'utente malintenzionato.
Nel mondo della sicurezza informatica questo tipo di attacco viene definito phishing, ed è un tipo di attacco che si basa sul social engineering, quindi un attacco che si basa sull'inganno di una persona più che un exploit tecnico.
Referer-Based Open Redirect
Un altro comune tipo di attacco è il referer-based open redirect.
Il referer è un header della richiesta HTTP che i browser includono automaticamente e comunica al server da dove si è originata la richiesta.
Questo header è un modo comune di determinare la posizione originale dell'utente, visto che contiene l'URL che ha portato alla pagina corrente.
Alcuni siti reindirizzano alla pagina del referer automaticamente dopo alcuni azioni dell'utente, come login o logout.
In questo caso, un utente malintenzionato può hostare un sito che collega al sito vittima per impostare il referer della richiesta, usando HTML nel modo seguente:
<html>
<a href="https://hayden.com/login">Clicca qui per loggare su hayden.com</a>
</html>
Questa pagina contiene l'elemento <a>, che rende il testo "Clicca qui per loggare su hayden.com" un link per il sito, appunto, hayden.com.
Quando un utente clicca sul link, verrà reindirizzato sul sito specificato dall'attributo href dell'elemento HTML <a>.
Se hayden.com usa un sistema di reindirizzamento basato sul referer, il browser reindirizzerebbe al sito dell'utente malintenzionato dopo aver visitato hayden.com, perché il browser ha visitato hayden.com tramite la pagina dell'utente malintenzionato.
Prevenzione
Il server deve assicurarsi che non reindirizzi gli utenti in "posti pericolosi".
Spesso i siti usano dei convalidatori URL per assicurarsi che l'URL di reindirizzamento punti ad una locazione legittima. Questi convalidatori possono usare una lista nera (una lista che specifica quali URL NON sono legittimi) o una lista bianca (una lista che specifica quali URL sono legittimi).
Quando un convalidatore implementa una lista nera, controlla se L'URL contiene alcuni indicatori di un reindirizzamento "maligno" e quindi blocca quella richiesta.
Per esempio, un sito potrebbe usare una lista nera in cui sono contenuti hostnames maligni o caratteri URL speciali usati spesso in attacchi di open-redirect.
Quando convalidatore implementa una lista bianca, controlla se la porzione dell'hostname dell'URL si trova nella lista degli hostname permessi.
Sembra quindi che il problema sia risolto, ma in realtà è molto complicato fare un parsing e/o una decodifica esatta di URL.
I convalidatori faticano ad identificare la parte hostname di un URL.
Questo fa sì che gli open redirects siano tra le più comuni vulnerabilità nelle applicazioni moderne.