Quanto è sicuro reindirizzare l'utente da http://normal.bank.com a https://secure.bank.com?

Sì, sei vulnerabile agli attacchi MITM perché stai iniziando con un'applicazione web non criptata. È qui che si verifica l'attacco, in quanto l'utente malintenzionato potrebbe modificare qualsiasi riferimento a https://secure.bank.com e sostituirli con http://secure.bank.com . L'utente malintenzionato intercetterà quindi i tuoi dati e trasmetterà il contenuto alla connessione sicura effettiva a https://secure.bank.com

È altamente consigliato forzare SSL sin dall'inizio della sessione, e dovresti assicurarti di pubblicizzare solo l'URL sicuro.

Is this is still vulnerable to MIM attack?

Sì, lo è, perché probabilmente andresti con i cookie di sessione che potrebbero essere annusati tramite un plug-in del browser come firesheep o man-in-the-middle'd facilmente.

What are the precautions?

Al giorno d'oggi la best practice consiste nel far eseguire l'intera applicazione su HTTPS perché:

• cookie sicuri non funzionano in un ambiente misto
• Gli attacchi MITM fanno funzionano in un ambiente misto
• assicurando l'autenticità del tuo sito web ai suoi utenti non funziona in un ambiente misto
• non è necessario pensare a risorse HTTP in una pagina HTTPS e a brutti avvisi del browser

Per garantire HTTPS in tutto il sito:

• crea 2 virtualhost-configs, uno per http: e uno per https:
• nella tua configurazione http, usa un reindirizzamento da http://site/resource a https://site/resource come unico modello in questa configurazione, quindi se qualcuno digita in http://site/somepath verrà sempre reindirizzato al sito sicuro
• nella configurazione di https, utilizza l'intestazione HTST per garantire (in base al browser) che il tuo utente visita il tuo sito sempre tramite HTTPS

Tutto il resto, come la crittografia della pagina di accesso, non è aggiornato; cerca "firesheep"

Dopo aver visitato http://normal.bank.com , un utente malintenzionato può sostituire tutti i link in https://secure.bank.com con link a http://secure.bank.com . Quando l'utente fa clic su http://secure.bank.com , il MITM si connetterà felicemente al server tramite HTTPS e servirà il contenuto al client via HTTP. Indipendentemente dalle precauzioni di reindirizzamento utilizzate qui, l'intero reindirizzamento può essere impedito dal MITM.

In conclusione, sì, sei ancora vulnerabile agli attacchi MITM.

Ho intenzione di invertire la tendenza qui e dire che è accettabile reindirizzare in questo modo.

È vero che un utente è vulnerabile al MITM se va a link e continua a utilizzare il sito senza ulteriori controlli sui certificati , URL, ecc.

Tuttavia, si tratta di un problema relativo al comportamento degli utenti e non a qualcosa che puoi correggere sul lato server.

Pensiamo solo per un minuto a come potresti provare a correggere questo lato server. Anziché emettere un reindirizzamento, potresti mostrare una pagina informativa, magari con un avvertimento scritto con cura "Per accedere a questo sito in modo sicuro, devi utilizzare link " Oppure potresti avere il server web in ascolto solo sulla porta 443 e rifiutare la porta 80.

Ora cosa succede se un utente malintenzionato ha il pieno controllo della rete di un utente? Quando l'utente visita il link l'utente malintenzionato li reindirizza a link e presenta una pagina di phishing. O forse inseriscono una pagina di phishing direttamente nel link in ogni caso, un utente esperto e in stato di allerta potrebbe rilevarlo, ma molti utenti continueranno.

Non fa alcuna differenza come si comporta il vero collegamento - l'attaccante può fare quello che vuole.

Quindi alla fine si tratta di un problema di formazione dell'utente. E il comportamento del sito può influenzare questo. La maggior parte delle volte che un utente visita il sito, visiterà il sito reale e non un attacco MITM. Se il sito li reindirizza automaticamente, questo non fa nulla per scoraggiarli usando l'URL http in futuro. Se ricevono un messaggio di avviso, o semplicemente il sito non funziona, impareranno rapidamente a utilizzare https per impostazione predefinita.

Ma quanto sei responsabile come operatore del sito per addestrare i tuoi utenti in questo modo? La realtà è che la maggior parte dei siti reindirizza da http a https in questo modo. Dal punto di vista del business, perché rendere il tuo sito più difficile da usare rispetto a un concorrente? Se stai solo facendo questo, avresti davvero un effetto sul comportamento generale degli utenti?

Per questi motivi, a conti fatti, raccomando che la maggior parte dei siti reindirizzino da http a https in questo modo.

Per bloccarlo il più possibile, ti consiglio di impostare il reindirizzamento in modo che link reindirizzi a link - spoglia il resto dell'URL.

Non è stato menzionato esplicitamente finora, quindi questa risposta tardiva. I siti web che cambiano tra HTTP e HTTPS sono inevitabilmente inclini a SSL-strip . Una buona spiegazione che puoi trovare qui:

presentazione SSL-strip di Moxie Marlinspike

Alcuni punti importanti:

• È la prima richiesta che fa la differenza. Ogni volta che l'utente inizia con HTTP come prima pagina, la striscia SSL può comunicare all'utente con HTTP e al sito con HTTPS. Un sito di passaggio impedirà all'utente di scegliere HTTPS per la prima richiesta.
• Qui è dove salta l'intestazione HSTS. Se hai già visitato il sito in precedenza da una connessione protetta, l'intestazione dirà al browser di chiamare il sito con HTTPS solo per richieste future. Se visiti il sito per la prima volta, l'intestazione HSTS non può essere di aiuto.
• Se l'utente si preoccupa, può iniziare con HTTPS (digitando l'url con https: // nella barra del browser), questo rende impossibile la striscia SSL sui siti solo SSL.

Ho scritto un post sul blog qualche mese fa. Nel mio post sul blog ho mostrato come il reindirizzamento del traffico da http a https potrebbe essere pericoloso a seconda del meccanismo selezionato. Ho proposto HSTS (HTTP Strict Transport Security).

link