Un open redirect è qualsiasi pagina del Suo sito che invia il browser del visitatore a un URL preso dall'input dell'utente senza verificarlo. Sembra un problema minore. In pratica permette a un attaccante di inviare un link di phishing che mostra il Suo dominio reale e, in un contesto OAuth, può far trapelare authorization code e access token.
Perché un redirect è più di un bug estetico
CWE-601 descrive la debolezza come un'applicazione web che accetta un input controllato dall'utente, il quale specifica un link a un sito esterno, e poi usa quel link in un redirect. La vittima segue un link verso il Suo sito attendibile e finisce su una pagina controllata dall'attaccante. La cheat sheet di OWASP ne mostra la forma:
http://example.com/example.php?url=http://malicious.example.comIl nome del server nel link modificato è identico a quello del sito originale, quindi il tentativo di phishing appare più credibile. Per il lato utente della questione, veda il nostro controllo dei link.
Con OAuth lo stesso difetto ha conseguenze più ampie. RFC 9700 stabilisce che client e authorization server NON DEVONO esporre URL che inoltrano il browser a URI arbitrari presi da un parametro di query, perché gli open redirector possono consentire l'esfiltrazione di authorization code e access token.
Anche i forward sono un caso affine. Se l'input dell'utente sceglie una destinazione interna, come in function.jsp?fwd=admin.jsp, un URL costruito ad arte può superare il controllo di accesso e raggiungere una funzione amministrativa. L'applicazione deve verificare che l'utente sia autorizzato ad accedere alla destinazione.
Trovare i parametri
I nomi variano: url, fwd e returnUrl compaiono negli esempi OWASP, e nel Suo codice ce ne saranno altri. Cerchi il pattern, non il nome.
| Stack | Pattern pericoloso |
|---|---|
| Java | response.sendRedirect(request.getParameter("url")) |
| PHP | header("Location: " . $redirect_url) con $_GET['url'] |
| C# .NET | Response.Redirect(url) con request.QueryString["url"] |
| Rails | redirect_to params[:url] |
| Java forward | getRequestDispatcher(fwd).forward(...) |
Una prima passata con grep Le fornisce un elenco da leggere. Adatti il percorso e i tipi di file al Suo repository.
grep -rnE 'sendRedirect\(|Redirect\(|redirect_to params|header::LOCATION' src/
grep -rn -A3 'header(.Location' src/Il secondo comando riguarda PHP. Legga le righe successive a ogni risultato: senza un exit dopo header("Location..., il resto dello script continua a essere eseguito. Un browser configurato per ignorare il redirect può quindi mostrare il resto della pagina.
I team .NET dovrebbero guardare per prima cosa le azioni di login. Secondo la cheat sheet, i siti ASP.NET MVC 1 e 2 sono particolarmente vulnerabili, e il suo esempio LogOn di MVC 2 reindirizza a returnUrl senza alcuna validazione. La correzione indicata è passare a MVC 3.
La maggior parte dei risultati sarà innocua. Per ogni redirect il cui argomento non sia un letterale stringa o una ricerca lato server, ponga una sola domanda: da dove proviene il valore? Contano i cookie, i campi nascosti dei form, gli header e i contenuti del database. Molti open redirect esistono perché lo sviluppatore ha dato per scontato che un cookie o un campo nascosto non potesse essere modificato.
Per confermare un riscontro, non si fermi a un semplice indirizzo esterno. Invii ciascuno dei seguenti valori nel parametro e osservi l'header Location:
http://malicious.example.comhttps://yoursite.example@malicious.example(userinfo:yoursite.examplediventa un nome utente)https://yoursite.example.malicious.example(un hostname che inizia con il Suo)https://malicious-yoursite.example(un hostname che termina con il Suo)
La cheat sheet indica userinfo e hostname fuorvianti come modi per aggirare i controlli su prefisso e suffisso. Se uno di questi valori passa dove l'URL semplice era stato bloccato, il controllo è probabilmente una semplice corrispondenza tra stringhe. È un'inferenza, non una prova, ma sostituisca comunque il controllo.
Gli scanner ne individueranno alcuni. L'OWASP Web Security Testing Guide afferma che questi strumenti sono generici e privi del contesto specifico dell'applicazione, quindi verifichi a mano ogni riscontro.
Correggerli, in ordine di preferenza
- Non effettuare redirect basati sull'input dell'utente. Se la destinazione è fissata nel codice, un attaccante non può modificarla.
- Mappare gli ID alle destinazioni lato server. L'utente fornisce un nome breve o un ID e il server cerca l'URL completo, rifiutando tutto il resto. Si assicuri che gli ID non possano essere scorsi in sequenza, altrimenti un visitatore può enumerare tutte le destinazioni.
- Usare l'helper del framework per i ritorni locali. In ASP.NET Core significa
LocalRedirectoIsLocalUrl, che rifiutano le destinazioni non locali. - Applicare una allowlist alle destinazioni esterne. Usi un parser di URL mantenuto e confronti schema, host canonico e porta effettiva, dopo il parsing, con un elenco esplicito. Limiti il percorso se sono ammessi solo endpoint specifici.
- Facoltativamente, richiedere un nonce. CWE descrive un nonce imprevedibile, generato dall'applicazione, per ogni richiesta di redirect, con rifiuto delle richieste che ne sono prive. L'XSS può aggirarlo, quindi completa una correzione ma non la sostituisce.
Regole per il controllo con allowlist:
- Rifiutare userinfo e input ambigui.
- Reindirizzare usando l'URL validato, non una versione che viene trasformata in seguito.
- Non usare mai una corrispondenza grezza su prefisso o suffisso. La cheat sheet cita GitLab come caso in cui userinfo e hostname fuorvianti hanno vanificato questi controlli.
Una denylist di valori non validi è una difesa primaria debole, anche se CWE la ammette per rilevare gli attacchi. Usi invece l'approccio "accettare solo ciò che è noto come valido".
Se le persone devono poter lasciare il Suo sito, una pagina intermedia che indichi la destinazione e richieda un clic aggiunge un ulteriore livello di protezione. Eviti l'XSS nella costruzione di quella pagina.
Il lato OAuth
RFC 9700 impone agli authorization server di confrontare gli URI di reindirizzamento del client con quelli preregistrati tramite corrispondenza esatta tra stringhe, ad eccezione dei numeri di porta negli URI di reindirizzamento localhost delle app native. La mia lettura, non testo dell'RFC: la corrispondenza esatta dimostra che il callback è quello registrato, quindi se quell'host registrato espone anche un open redirector, il codice può proseguire altrove. L'RFC rimanda alla propria Sezione 4.11 per i dettagli. La legga prima di fare affidamento sul mio riassunto.
Da dove iniziare
- Esegua i pattern grep indicati sopra sul Suo codice ed elenchi ogni redirect e forward la cui destinazione provenga da una richiesta, da un cookie o da un valore memorizzato. Controlli per primi gli handler di login e di callback OAuth.
- Verifichi nei risultati PHP l'assenza di
exite, nei progetti .NET, le azioni di login di MVC 1 o 2. - Testi ogni risultato con i quattro input indicati sopra, compresa la forma con userinfo, e annoti quali inviano il browser fuori dal Suo dominio.
- Sostituisca gli URL forniti dall'utente con la mappatura degli ID lato server dove possibile, con helper del framework solo locali per gli indirizzi di ritorno e con una allowlist basata su URL analizzato (parsed) per le poche destinazioni esterne necessarie.
- Riveda le registrazioni dei client OAuth per verificare che gli URI di reindirizzamento siano esatti e confermi che nessuno dei Suoi host esponga un open redirector.
- Aggiunga un test sui redirect alla code review e al perimetro del Suo penetration test, in modo che il bug non si ripresenti.
