Come e perché evitare reindirizzamenti e inoltri non convalidati?

25/03/20 CoreTech Blog

I reindirizzamenti e gli inoltri non convalidati non possono danneggiare il tuo sito Web o l'applicazione Web, ma possono danneggiare la tua reputazione aiutando gli aggressori ad attirare gli utenti su siti di malware. Se consenti reindirizzamenti e inoltri non convalidati, molto probabilmente il tuo sito Web o applicazione Web verrà utilizzato nelle truffe di phishing. Pertanto, è molto importante utilizzare reindirizzamenti e forward responsabilmente.

Mentre i reindirizzamenti non convalidati e inoltri non siano stati inseriti nella OWASP Top 10 nel 2017, erano presenti nell'elenco nel 2013 (A10 reindirizzamenti e forward non validi).

Cosa sono i reindirizzamenti e i forward

Un reindirizzamento è una situazione in cui il tuo sito Web o la tua applicazione web induce il browser dell'utente ad aprire un altro URL (esterno). Un inoltro è una situazione in cui invece di un URL esterno, il tuo sito Web o applicazione web fa sì che il browser passi a diverse parti del sito. I reindirizzamenti e i forward sono tecnicamente identici, l'unica differenza è il tipo di destinazione: URL esterni e pagine interne.

Dal punto di vista tecnico, il modo più comune per creare reindirizzamenti e forward è che il server Web invii un codice di stato 3xx al client (ad esempio, 302 Found). Questa operazione viene eseguita utilizzando tecnologie back-end, sia nei programmi lato server che nella configurazione del server Web. Tuttavia, è anche possibile creare reindirizzamenti e inoltri direttamente in HTML utilizzando i tag META (meta http-equiv="Refresh") o utilizzando JavaScript lato client.

Che cosa sono i reindirizzamenti e i forward non convalidati

Un reindirizzamento o inoltro non convalidato si verifica se l'applicazione utilizza un URL o un nome di pagina fornito direttamente da input non attendibile. Ciò consente a un utente malintenzionato di reindirizzare il browser a un sito dannoso e utilizzare il nome di dominio per ottenere la fiducia della vittima. Ad esempio, se il dominio è example.com, l'utente malintenzionato potrebbe creare il seguente URL:

http://www.example.com/redirect.php?url=http://evil.com

L'aggressore può quindi inviare questo URL come parte di un tentativo di phishing sperando che example.com all'inizio avrà un aspetto affidabile, guadagnare la fiducia dell'utente, e farli cadere per la truffa di phishing.

Si noti che può accadere esattamente lo stesso se lo scopo dell'applicazione è quello di inoltrare gli utenti a pagine diverse all'interno del sito. Se i parametri di input dell'utente non sono convalidati, è possibile utilizzare un meccanismo di inoltro per creare un reindirizzamento.

Un esempio di reindirizzamento non convalidato

Se per qualche motivo l'applicazione deve reindirizzare l'utente a un altro URL, alcuni sviluppatori potrebbero utilizzare il seguente semplice costrutto (esempio in PHP):

$new_url = $_GET['url']; 

header("Location: " . $new_url);

Si tratta di un reindirizzamento non convalidato (in questo caso, un reindirizzamento completamente aperto) perché l'utente malintenzionato potrebbe fornire un URL dannoso nel parametro url della richiesta GET e questo URL di destinazione verrà utilizzato nell'intestazione Location:

Conseguenze di reindirizzamenti e inoltri non convalidati

Oltre alle truffe di phishing, reindirizzamenti non convalidati e inoltri possono facilitare altri tipi di attacchi:

• Cross-site Scripting (XSS): se il reindirizzamento può utilizzare dati: o javascript: i protocolli e il browser dell'utente supportano tali protocolli nei reindirizzamenti, potrebbe essere introdotta una vulnerabilità XSS.
• Bypass dei criteri di sicurezza del contenuto: se CSP viene utilizzato per proteggere da XSS e un dominio autorizzato ha un problema di reindirizzamento aperto, può essere utilizzato per bypassare CSP.
• Server-Side Request Forgery (SSRF):I reindirizzamenti aperti possono essere utilizzati per eludere i filtri SSRF.
• Iniezione CRLF: se il parametro di destinazione include interruzioni di riga, potrebbe essere possibile un attacco di inserimento CRLF (divisione dell'intestazione della risposta).

Come impedire reindirizzamenti e inoltri non convalidati

La soluzione migliore per mantenere la sicurezza delle applicazioni web è di non utilizzare alcun reindirizzamento o inoltro. Tuttavia, se il sito web o l'applicazione web non può funzionare correttamente senza reindirizzamenti o inoltri, ci sono diversi modi per un uso sicuro.

• Se si dispone di un elenco limitato di pagine di destinazione da reindirizzare o inoltrare, archiviare gli URL completi nel database, fornire loro gli identificatori e utilizzare gli identificatori come parametri di richiesta, reindirizzando all'URL effettivo rappresentato da un identificatore. Con tale approccio, gli aggressori non saranno in grado di reindirizzare o inoltrare a pagine non autorizzate.
• Se non è possibile utilizzare un elenco di pagine e/o URL di destinazione, filtrare l'input di URL non attendibili, preferibilmente sulla base di una whitelist e non di una blacklist. Prestare attenzione quando si verifica la presenza di stringhe parziali, ad esempio, si noti che http://example.com.evil.com è un URL valido. Inoltre, consentire solo i protocolli HTTP e HTTPS. Si noti che questa soluzione è rischiosa perché gli errori nel filtro possono rendere possibili determinati vettori di attacco.