Un open redirect è una vulnerabilità in cui un'applicazione web prende un URL di destinazione da input utente non validato - di solito un parametro di query come ?next= o ?url= - e inoltra lì il browser senza controllarlo. Il link parte da un dominio di cui la vittima si fida, quindi supera l'ispezione, e poi la fa atterrare silenziosamente da un'altra parte. La correzione non è smettere di fare redirect. È smettere di lasciare che sia la richiesta a decidere dove va il redirect.
Quella distinzione conta perché i redirect sono ovunque e la maggior parte va benissimo. Accedere e tornare indietro alla pagina che volevi, passare a un fornitore di pagamenti, una callback OAuth - tutto normale, tutti redirect. Il bug, catalogato come CWE-601 e raggruppato sotto il broken access control nella OWASP Top 10, è nello specifico il caso in cui il bersaglio proviene da input controllato dall'utente e nulla lo valida prima. Un aggressore fornisce il proprio URL, il sito fidato vi inoltra, e la fiducia si trasferisce con il click.
Passo le mie giornate sul percorso del redirect, quindi questo è un argomento su cui ho delle opinioni. I link brevi sono redirect per definizione, il che rende "uno shortener è solo un open redirect?" una domanda legittima - e la risposta, fatto bene, è un netto no. Ci arriviamo più sotto. Se la meccanica dei redirect è nuova per te, tipi di redirect è l'introduzione, e come funzionano gli URL shortener copre le basi del tier di redirect.
Che cos'è davvero un open redirect
Riducilo al meccanismo. Una pagina accetta un parametro che nomina dove andare dopo, e lo usa in un redirect HTTP senza confermare che punti da qualche parte consentita.
https://trusted.example/login?next=https://evil.example/fake-login
La vittima vede trusted.example davanti e clicca. Dopo il login, l'app legge next ed emette un redirect verso evil.example. Il browser obbedisce, perché un redirect è solo un header Location e uno stato 3xx - la specifica HTTP definisce quel comportamento in modo chiaro e il browser non ha modo di sapere che questo particolare bersaglio è ostile. L'utente, che guarda la barra degli indirizzi cambiare dopo essersi già fidato del link, spesso non se ne accorge.
OWASP descrive il pericolo centrale senza giri di parole: il nome del server nel link modificato è identico a quello del sito originale, il che conferisce credibilità a un redirect malevolo. La vulnerabilità non è che il sito faccia redirect. È che un estraneo ha scelto la destinazione.
Perché un redirect "innocuo" è una minaccia reale
Il riflesso è alzare le spalle: e allora manda qualcuno a un altro sito, che male c'è. Il male è la fiducia presa in prestito, e scala.
Il phishing è l'uso principale. Un link che inizia con una banca, un login SaaS o un portale governativo scivola oltre il rapido controllo visivo che fa la maggior parte delle persone, e oltre un numero sorprendente di filtri automatici che ispezionano solo il dominio iniziale. La vittima arriva a una copia perfetta al pixel della pagina di login che si aspettava, su un dominio che sembrava giusto un passaggio fa, e digita la propria password. Nessun malware, nessun payload esotico - solo un redirect e un clone.
Peggiora quando i redirect si trovano vicino all'autenticazione. Un open redirect in un flusso OAuth può far trapelare un codice di autorizzazione o un token a un redirect_uri controllato dall'aggressore, il che fa salire di livello un bug "minore" fino alla piena compromissione dell'account. È per questo che gli open redirect sono un classico dei report di bug-bounty anziché una nota a piè di pagina. Lo stesso trucco ricicla anche la reputazione: spammer e operatori di malware adorano rimbalzare attraverso un dominio fidato perché fa passare il loro vero link oltre le blocklist. Copriamo la categoria più ampia nella checklist di sicurezza per URL shortener, e l'angolo della fiducia dal lato del visitatore in gli URL shortener sono sicuri.
Come prevenire gli open redirect
C'è una gerarchia di correzioni, e in cima c'è quella che davvero pone fine al problema. La cheat sheet di OWASP le classifica, e l'ordine vale la pena di essere seguito.
- Non prendere affatto un URL dalla richiesta. Fai inviare al client un nome breve, un ID o un token, e risolvilo nella destinazione completa lato server. OWASP la definisce il grado di protezione più alto, perché la richiesta in entrata non può più nominare un bersaglio arbitrario. Se questo schema ti suona familiare, dovrebbe: è il modo in cui funziona un URL shortener.
- Allowlist, non denylist. Quando devi accettare una destinazione, controllala rispetto a una lista di host fidati o a una regex rigorosa. La allow-list fallisce in modo chiuso - tutto ciò che non è esplicitamente permesso viene rifiutato. La deny-list fallisce in modo aperto, e gli aggressori sono pagati per trovare le voci che hai dimenticato.
- Esegui un parsing rigoroso. Rifiuta gli URL protocol-relative (
//evil.example), normalizza le backslash, decodifica prima di validare, e tratta l'host - non solo il prefisso della stringa - come la cosa da controllare. La maggior parte dei bypass dei filtri vive in un parsing pigro. - Mostra un interstiziale come ultima linea di difesa. Se un redirect verso un sito esterno è inevitabile, instradalo attraverso una pagina che nomina la destinazione e chiede all'utente di confermare. È attrito, ma converte un redirect silenzioso in uno informato.
Il tema ricorrente è che i redirect sicuri sono decisi dal server, a partire da dati di cui il server già si fida - mai da qualunque stringa sia arrivata nella query.
Se stai integrando redirect in un prodotto e preferiresti non possedere questa modalità di guasto, la piattaforma per sviluppatori di Elido mappa i codici alle destinazioni lato server per progettazione - inizia con il quickstart dell'API e non costruire più a mano un parametro ?url=.
Perché i link brevi sono la difesa, non il bug
Ecco la parte che sorprende le persone. Un URL shortener costruito correttamente è l'implementazione da manuale della correzione numero uno di OWASP contro l'open redirect.
Quando un link breve viene creato, la sua destinazione viene validata e memorizzata lato server, legata a un codice breve. Quando qualcuno lo visita, il tier di redirect cerca quel codice e inoltra al bersaglio memorizzato. La destinazione non proviene mai dalla richiesta in entrata - il visitatore non può aggiungere un ?url= e piegare il link altrove, perché non esiste un parametro del genere da piegare. Quella è esattamente la mappatura token-URL che OWASP raccomanda, in esecuzione in produzione milioni di volte al giorno. Architetturalmente questo vive nel nostro tier di edge redirect, e il budget di latenza che ciò comporta è l'argomento di raggiungere un p95 sotto i 15ms per i redirect.
L'avvertenza onesta: di uno shortener si può comunque abusare, solo non tramite open redirect. Se una piattaforma permette a chiunque di coniare link verso qualsiasi cosa senza scansione o moderazione, gli aggressori useranno la sua reputazione di dominio per mascherare le proprie destinazioni malevole - ed è per questo che gli shortener responsabili scansionano i bersagli e applicano policy anti-abuso. Questo è un problema di moderazione dei contenuti, distinto dalla falla di validazione dell'input di cui tratta questo articolo, e che vale la pena non confondere. La pratica correlata di nascondere deliberatamente una destinazione è coperta in link cloaking e URL masking spiegati, e il cugino di ingegneria sociale di tutto questo - i QR code ostili - in i QR code sono sicuri.
La conclusione in una riga
Se il tuo codice legge una destinazione dalla richiesta e vi fa redirect, hai un open redirect in attesa di essere trovato. Mappa invece un ID a un bersaglio lato server, metti in allowlist qualsiasi cosa tu non possa evitare di prendere dall'input, ed esegui il parsing come se ti aspettassi di essere attaccato. I redirect non sono il rischio. Lasciare che la richiesta scelga dove vanno lo è. La differenza tra un 301 e un 302 in redirect 301 vs 302 è una nota a piè di pagina accanto a quell'unica regola.
Correlati sul blog
Domande frequenti
Che cos'è una vulnerabilità di open redirect?
Un open redirect è una falla in cui un'applicazione web invia gli utenti a un URL di destinazione preso da input non validato, di solito un parametro di query come ?next= o ?url=. Poiché il link parte da un dominio fidato, il browser della vittima e qualsiasi filtro di scansione dei link lo trattano come sicuro, ma l'applicazione lo inoltra poi a qualunque sito il parametro nomini - incluso quello di un aggressore. È classificato come CWE-601 e ricade sotto il broken access control nella OWASP Top 10. Il bug è il controllo mancante, non il redirect in sé.
Perché gli open redirect sono pericolosi se ti mandano solo a un altro sito?
Perché il pericolo è la fiducia che il dominio di partenza presta. Un link di phishing che recita https://trusted-bank.example/login?next=evil.example supera il test a colpo d'occhio, sopravvive a molti filtri email e fa atterrare la vittima su una pagina di login fasulla ma convincente - il tutto sembrando provenire dalla vera banca. Gli open redirect si concatenano anche in attacchi più grandi: possono far trapelare codici di autorizzazione o token OAuth quando il bersaglio del redirect è controllato dall'aggressore, trasformando un bug a bassa gravità in una compromissione dell'account. Il redirect è il meccanismo di consegna, non l'intero exploit.
Gli URL shortener sono una vulnerabilità di open redirect?
No, non quando sono costruiti correttamente - e la distinzione è il punto. Un open redirect prende una destinazione arbitraria dall'input dell'utente al momento della richiesta e vi inoltra senza validazione. Un link breve mappa un codice fisso a una destinazione che è stata impostata e memorizzata lato server quando il link è stato creato; il bersaglio del redirect non proviene mai dalla richiesta in entrata. Quella mappatura lato server è esattamente la difesa che OWASP raccomanda contro gli open redirect. Uno shortener diventa un problema solo se permette a utenti non controllati di creare link verso qualsiasi cosa e presta loro una reputazione di dominio di cui possono abusare - il che è un problema di abuso e moderazione, non un bug di open redirect.
Come si prevengono le vulnerabilità di open redirect?
La correzione più solida è non accettare affatto un URL di destinazione dalla richiesta. Fai inviare al client un nome breve, un ID o un token, e mappalo al bersaglio completo lato server - lo stesso modello che usa un URL shortener. Quando devi davvero accettare un URL, validalo rispetto a una allowlist di host fidati anziché a una denylist di quelli cattivi, rifiuta qualsiasi cosa che non sia un percorso relativo o un dominio approvato, e sii rigoroso nel parsing in modo che trucchi come //evil.example o le backslash non passino. Come ultima risorsa, instrada il redirect attraverso una pagina interstiziale che mostra la destinazione prima di mandare avanti l'utente.
Come sfruttano gli aggressori un open redirect?
Trovano un endpoint che riflette un parametro URL in un redirect, poi creano un link sul dominio fidato con il proprio sito in quel parametro e lo distribuiscono via email, annuncio o messaggio. Le varianti includono la codifica URL del payload per aggirare filtri deboli, l'uso di URL protocol-relative come //attacker.example, lo sfruttamento della sola porzione host mantenendo un percorso dall'aria legittima, e l'abuso della gestione del redirect_uri di OAuth per catturare token. Il filo comune è che la vittima vede e si fida del primo dominio e non vede mai il secondo finché non è troppo tardi.
Un open redirect è una vulnerabilità ad alta o bassa gravità?
Da solo un open redirect è spesso valutato da basso a medio, perché non compromette direttamente il server - manda gli utenti altrove. Ma la gravità dipende da cosa concatena. Vicino a un flusso di autenticazione può far trapelare token OAuth e portare alla compromissione dell'account, il che è alta gravità; come aiuto al phishing può causare una perdita reale di credenziali che un punteggio CVSS non cattura. Trattalo in base all'impatto nel contesto, non in base all'etichetta di base, e correggilo comunque: la remediation costa poco e il potenziale di abuso no.
Prova Elido
Incolla un URL, ottieni un link breve
Senza registrazione. Il link vive 30 giorni. Iscriviti per conservarlo.
Gratis, nessuna registrazione richiesta · 2 al giorno