it-swarm.dev

La pubblicazione da HTTP a HTTPS è una cattiva pratica?

Lavorando sul presupposto che SSL serve sia per crittografare i dati e per fornire certezza sull'identità e la legittimità del sito Web, la pratica di fornire un modulo di accesso su una pagina richiesta su HTTP dovrebbe essere evitata, anche quando si pubblica su HTTPS?

La domanda si riferisce a un post che ho scritto ieri sul Who's who of bad password practice e ad alcuni dei feedback che suggeriscono che non vedere visibilmente il certificato rappresentato nel browser prima dell'autenticazione andava bene se il modulo è stato pubblicato in modo sicuro .

A mio avviso, questo vende SSL in breve poiché non solo perdi la possibilità di convalidare la legittimità del sito prima di consegnare le tue credenziali, ma non hai nemmeno la certezza che sia is pubblicazione su HTTPS. Sono consapevole che artisti del calibro di Twitter e Facebook adottano questo approccio, ma dovrebbero? Sto trascurando qualcosa qui o è una pratica che dovrebbe essere scoraggiata?

Aggiornamento: Ho finito per dettagliare il risultato di questa domanda e la successiva discussione nel post del blog SSL non riguarda la crittografia

64
Troy Hunt

OWASP afferma:

(copiato letteralmente da http://www.owasp.org/index.php/SSL_Best_Practices )

Pagine di accesso sicuro
Esistono diverse considerazioni importanti per la progettazione sicura di una pagina di accesso. Il seguente testo affronterà le considerazioni relative a SSL.

Gli accessi devono essere inviati a una pagina SSL È abbastanza ovvio. Il nome utente e la password devono essere registrati su una connessione SSL. Se guardi l'elemento di azione del modulo, dovrebbe essere https.

La pagina di destinazione dell'accesso deve utilizzare SSL La pagina effettiva in cui l'utente compila il modulo deve essere una pagina HTTPS. In caso contrario, un utente malintenzionato potrebbe modificare la pagina quando viene inviata all'utente e modificare la posizione di invio del modulo o inserire JavaScript che ruba il nome utente/la password durante la digitazione.

Non devono esserci messaggi di errore o di avviso SSL La presenza di qualsiasi messaggio di avviso SSL è un errore. Alcuni di questi messaggi di errore sono legittimi problemi di sicurezza; altri desensibilizzano gli utenti rispetto a reali problemi di sicurezza poiché fanno clic ciecamente su accetta. La presenza di qualsiasi messaggio di errore SSL è inaccettabile, anche la mancata corrispondenza del nome di dominio per il www.

Le connessioni HTTP devono essere eliminate Se un utente tenta di connettersi alla versione HTTP della pagina di accesso, la connessione deve essere negata. Una strategia consiste nel reindirizzare automaticamente le connessioni HTTP alle connessioni HTTPS. Mentre ciò porta l'utente alla pagina protetta, esiste un rischio persistente. Un utente malintenzionato che esegue un uomo in attacco intermedio potrebbe intercettare la risposta di reindirizzamento HTTP e inviare l'utente a una pagina alternativa.

Per ripetere: La pagina di destinazione dell'accesso deve utilizzare SSL

58
Tate Hansen

Potrebbe valere la pena aggiungere che ci sono strumenti automatici per fare esattamente ciò che affermano le migliori pratiche di OWASP: "un utente malintenzionato potrebbe modificare la pagina quando viene inviata all'utente e cambiare la posizione di invio del modulo ... "Il collegamento include una presentazione di Black Hat sull'attacco.

13
PulpSpy

Da aggiungere alle risposte già fornite. Ci sono stati casi pratici in cui la presenza di pagine di destinazione non HTTPS consente agli autori di attacchi di modificare il sito e acquisire le credenziali degli utenti. Questo esempio , è il più recente che abbia mai visto. In questo caso è stato fatto a livello di ISP, ma allo stesso modo potrebbe essere fatto dai provider di hotspot wireless o da chiunque utilizzi gli strumenti pertinenti per eseguire un attacco Man-In-The-Middle.

10
Rory McCune