Difendere il sito dall'essere abusato dal phishing

Un modo per avvicinarti a questo sarebbe crittografare il parametro mentre viene passato all'utente con una chiave memorizzata sul server (anche per una migliore protezione, considera l'aggiunta di un HMAC ). Quindi, quando l'utente invia il modulo, decrittografa il parametro (e controlla l'HMAC se usato) e lo usa per reindirizzare l'utente.

Ho visto casi in cui l'URL è semplicemente offuscato (codifica base64, ecc.). Ciò potrebbe dissuadere gli aggressori occasionali, ma non ci farei affidamento, dato che un determinato aggressore probabilmente elaborerà lo schema utilizzato.

Puoi aggiungere il prefisso del tuo sito web all'URL in modo che vada a:

example.com/login.php?returnurl=profiles/home.php

E nella pagina dovresti tornare al link e aggiungere l'URL di ritorno. (Http://example.com/RETURNURLHERE)

Esistono molti modi per attaccare un utente / browser o offuscare URL / reindirizzamenti. Un modo pazzesco che farà male al cervello e ti lascerà chiedere perché funziona ?! (vedi: link ) In generale, quando si convalida l'input, non provare a correggere i dati, se non è quello che ti aspettavi o meno nel formato che hai richiesto, buttalo via. Ricorda default deny, questo è solo un altro esempio di questo.

Come qualsiasi cosa, come si implementa questo, dipende dalle tue esigenze. Dovresti anche essere consapevole dei difetti di implementazione quando gestisci i reindirizzamenti che possono anche aprire ulteriori vulnerabilità come la divisione della risposta HTTP, l'iniezione dell'intestazione, ecc.

Di solito raccomando una combinazione di whitelisting di destinazione e firma della richiesta (utilizzando HMAC, simile al suggerimento di Rory). Durante la preforming della firma delle richieste, mi piace rendere visibile la destinazione nell'URI. Ad esempio:

link

Ciò consente all'utente di avere un po 'di redditività nel punto in cui la richiesta dovrebbe andare, e consente anche a più utenti esperti di notare un phishing o altri attacchi da soli.

Quando sta per verificarsi un reindirizzamento:

1. Verifica il 'returnurl' rispetto all'hash
2. Verifica che 'returnurl' sia autorizzato nella lista bianca
3. Quindi preforma il reindirizzamento.

Se un qualsiasi passaggio del processo di convalida fallisce, reindirizza a una pagina iniziale / predefinita o rifiuta la richiesta.

Ecco alcune altre risorse:

• link
• link
• link

1. Rimuovi tutte le informazioni non necessarie dall'URL (ad esempio http:// , il nome del sito, ecc.). Se hai diverse opzioni (ad esempio cinque siti), utilizza il loro indice.
2. Calcola un hash di ciò che rimane utilizzando un sale segreto lato server e anteponilo (o parte di esso - più corto è, maggiore è il pericolo di un attacco di collisione riuscito) a returnUrl
3. Dopo aver ricevuto returnUrl , verifica che l'hash sia valido. In caso contrario, rifiuta.
4. Aggiungi di nuovo tutte le informazioni mancanti e il reindirizzamento

Inoltre, alcuni reindirizzamenti possono seguire uno schema comune in cui devi solo inserire alcuni parametri. In questo caso potresti anche non aver bisogno dell'hash.

Ad esempio: invece di

returnUrl=http://www.myfifthsite.com/common/webpage/profile?user=lserni

puoi far bollire

returnUrl=5-5-lserni

che significa quinto sito, quinto pattern di reindirizzamento consentito, questo modello ha solo un parametro e il suo valore è il nome utente:

siti:     ...     5 = > ' link '     ...

modelli per il sito n. 5 (ovviamente l'autenticazione è non sovrascritta!):         5 = > '/ Common / sito / profilo? User = $ 1'         6 = > '/ Common / sito / messaggi? User = $ 1'

Un utente malintenzionato può enumerare tutti i numeri di sito e di modello consentiti, ma otterrebbe solo URL validi dei siti consentiti.

Quindi in un certo senso, in questo modo non è necessario controllare nulla. Gli URL saranno sempre automaticamente validi (anche se alcuni potrebbero richiedere ancora i cookie di autenticazione).