Immagina questo scenario: la tua applicazione fa una richiesta HTTP a un'API con un header Authorization. L'API risponde con un 301 redirect verso un altro dominio. La tua libreria HTTP segue il redirect automaticamente. Domanda: l'header Authorization viene inviato anche al nuovo dominio?
Se hai risposto "no, ovviamente viene rimosso" - hai ragione in teoria. L'RFC 7235 e chiaro: le credenziali non dovrebbero essere inviate a domini diversi da quello originale. Ma nella pratica, molte librerie HTTP tra le piu usate al mondo non implementano questo comportamento correttamente. E questo e esattamente il pattern che ho scoperto nella mia campagna di vulnerability research.
L'anatomia del bug
Il problema e sottile. La maggior parte delle librerie gestisce correttamente il caso base - un redirect cross-domain rimuove gli header sensibili. Ma cosa succede con un redirect da HTTPS a HTTP sullo stesso dominio? O un redirect che passa attraverso un intermediario? O un redirect con un path specificatamente costruito? Le edge case sono dove i bug si nascondono.
In alcuni casi, ho trovato che header custom di autenticazione (non lo standard Authorization, ma header proprietari come X-API-Key o X-Auth-Token) venivano preservati durante tutti i redirect senza alcun controllo. Uno sviluppatore potrebbe pensare di essere al sicuro perche usa un header custom, ma la libreria non sa che quell'header e sensibile.
L'impatto pratico: se un attaccante controlla un endpoint che puo rispondere con un redirect, potrebbe raccogliere credenziali da qualsiasi applicazione che usa quella libreria per fare richieste autenticate. In contesti cloud, dove i redirect tra servizi sono comuni, questo pattern diventa particolarmente pericoloso.
Se vuoi approfondire questo argomento o ti serve una consulenza specializzata, parliamone.
Parliamone →