Buona risposta da parte di alexwen, anche se penso che la sua risposta sia più un problema di sanitizzazione di un parametro generico, non esattamente a cosa si riferisca OWASP. Penso che OWASP possa riferirsi a uno qualsiasi dei seguenti concetti.
Riconvalida dei dati dal reindirizzamento
OWASP sta parlando di un diverso tipo di schema in cui un URL esegue qualche elaborazione (cioè convalida), quindi reindirizza a un altro URL da completare. Ad esempio, immagina due URL, uno è / checkout e l'altro è / ship. L'URL / checkout controlla le informazioni sulla carta di credito, controlla che le parti siano disponibili, ecc. Quindi reindirizza a / spedisci. L'URL / ship crea effettivamente un ticket di lavoro per estrarre le parti e spedirle.
Se l'attaccante conosce questa configurazione, l'attaccante può semplicemente inviare i dati di spedizione pertinenti direttamente all'URL / nave, ignorando tutte le convalide eseguite nel primo URL e ottenendo alcuni prodotti gratuitamente.
Personalmente non ho mai visto uno schema di convalida così stupido, ma sembra che si riferisca a OWASP.
Post-Redirect-Get Pattern
Il pattern PRG indica il reindirizzamento a una richiesta GET dopo aver elaborato con successo un POST. Questo è usato per evitare l'orrendo problema di usabilità di un utente che fa clic sul pulsante Indietro in un browser e il browser chiede all'utente una oscura domanda sull'opportunità o meno di "ripubblicare i dati del modulo". (Ho visto questo viaggio su così tanti utenti che non è nemmeno divertente.)
Non l'ho mai visto usato in modo tale da essere vulnerabile agli attacchi, ma in teoria uno schema di autenticazione scadente potrebbe usare PRG per elaborare le credenziali di autenticazione, quindi reindirizzare a una pagina "solo membri" o qualcosa di stupido come quello. Ancora una volta, non ho mai visto personalmente questo in the wild, quindi non sono sicuro al 100% che sia di questo che parla OWASP.
Reindirizzamento cieco
Non sono sicuro che questo sia ciò di cui OWASP sta parlando, ma questa è in realtà una vulnerabilità comune. A differenza delle precedenti due vulnerabilità che ho descritto, ho visto questo in realtà molte volte. Questo errore comune è che l'URL per il reindirizzamento è specificato nella query URL originale e non è convalidato, ad esempio:
http://my.badsite.com/redirect.php?destination=http://google.com
Se redirect.php reindirizza incondizionatamente a qualunque URL viene passato (ad esempio in PHP, intestazione ("Posizione: $ posizione")), un utente malintenzionato può creare un URL che sembra sicuro ma che in realtà conduce a un sito pericoloso. Ad esempio, se lo script di reindirizzamento cieco è link , l'autore dell'attacco invia alla vittima un link come link e un utente ingenuo guarda il link e pensa che sta andando sul sito web del NYT. (A seconda della natura esatta dello script, l'autore dell'attacco potrebbe essere in grado di codificare l'URL parte o tutto l'URL di destinazione per poterlo offuscare ulteriormente.)
Uno script di reindirizzamento dovrebbe ispezionare l'URL di destinazione per assicurarti che sia appropriato, probabilmente attraverso una sorta di whitelist.