L'esempio OWASP per Reindirizzati e inoltro non convalidati dice che:
The application has a page called “redirect.jsp” which takes a single parameter named “url”. The attacker crafts a malicious URL that redirects users to a malicious site that performs phishing and installs malware.
In che modo un utente malintenzionato crea un URL dannoso e lo forza sulla vittima? Se si va a foo.bar , riempie un modulo e lo inoltra, come si può essere reindirizzati al sito amalicious?
Diciamo che c'è un url chiamato www.example.com/redirect.jsp?url=www.example.com/login che viene usato per reindirizzare alla pagina di login. Realizzo un link a www.example.com/redirect.jsp?url=www.myphishingsite.com/login che reindirizza al mio sito di phishing. Le persone guardano il nome di dominio e pensano che sia legittimo. Può anche essere usato per DOS qualcosa e nascondere la tua identità dalla destinazione.
Non c'è forma in questione.
@joe ha ragione sulla natura dell'attacco (+1), ma c'è ancora qualcosa in più. Vale a dire, di chi è il problema e perché il problema si verifica.
Utilizzando lo stesso esempio, diciamo che example.com utilizza uno script di reindirizzamento, ad esempio example.com/redirect.php che riceve il parametro url e quindi esegue un HTTP 302 (o 301) all'URL contenuto nel % parametrourl. Ora, diciamo anche che example.com contiene contenuti generati dall'utente , incluso l'URL al quale gli utenti si collegano.
Quando un utente pubblica un URL su example.com , ad esempio, http://mywebsite.com/myarticle/ , quindi example.com visualizza questo URL come:
href="http://example.com/redirect.php?url=http://mywesite.com/myarticle"
Ma perché example.com visualizza l'URL in questo modo invece dell'URL semplice? Poiché redirect.php raccoglie statistiche sui collegamenti che gli utenti fanno clic.
Quindi, qual è il problema? Il problema è che posso aggiungere un URL su qualche altro sito web che ospita anche contenuto utente , completamente estraneo a example.com , ad esempio su facebook.com che legge:
http://example.com/redirect.php?url=http://myphishingwebsite.com/script.php
E l'utente farà clic che pensa che si tratti di un link che porta a example.com .
I browser spesso accorciano gli URL lunghi ma lasciano il dominio per intero e alcuni forum fanno addirittura risaltare un dominio su un link; tutto ciò per prevenire il phishing attraverso collegamenti a siti web poco raccomandabili. Ma nell'esempio sopra example.com ha distrutto queste salvaguardie e permetterà a qualsiasi sito web di essere reindirizzato a, mentre il dominio che vedi quando passa il mouse sul link è sempre example.com .
Quanto sopra è un problema di example.com e questo doiman dovrebbe quindi essere classificato come non sicuro per navigare anche se non contiene alcun contenuto dannoso.
Invece di usare un reindirizzamento non controllato, example.com dovrebbe fare una whitelist di domini a cui redirect.php può essere usato, o rendere i domini nel parametro url spiccano (ad esempio anteporre il dominio a un colore ad alto contrasto ) prima del collegamento stesso e richiedono un'appropriata intestazione Referer: durante il reindirizzamento (quindi i reindirizzamenti possono avvenire solo da example.com stesso). Preferibilmente, dovrebbe preformare entrambe le correzioni.
Ci sono due problemi con questi reindirizzamenti:
1) Perdita di origine
Diciamo che hai scritto un server web (insicuro) che a un certo punto inserisce il nome utente & password di un utente in un URL (ad esempio una richiesta GET). Un reindirizzamento direbbe a un malintenzionato da dove proviene un utente, consentendo loro di estrarre le proprie credenziali dall'URL.
2) Falso senso di fiducia
Gli utenti possono essere reindirizzati a un sito di phishing senza saperlo. Un utente prudente potrebbe utilizzare il sito legittimo e improvvisamente essere reindirizzato a un sito dannoso senza che lo sappia. Questo utente continuerà a utilizzare il sito normalmente, probabilmente avendo già controllato l'URL, ecc. Non so voi, ma non controllo l'URL ogni volta che mi muovo per un sito web.
Leggi altre domande sui tag url-redirection