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#
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