Servizio Web HTTPS passato a HTTP. Cosa può andare storto?

Hai ragione, la regressione su HTTP non ha senso.

Si noti che tutti i punti si applicano a un particolare tipo di attacco, in cui l'avversario è in grado di accedere al trasporto dei dati tra client e server. Potrebbe essere il proprietario di un hotspot WiFi o il tuo ISP che agisce come man-in-the- middle , che si trova tra te e il server. Questo può essere difficile da realizzare per un utente malintenzionato remoto, ma è particolarmente facile su un WiFi pubblico.

Quale HTTPS aggiunge a HTTP è trasporto sicuro dei dati . La stessa applicazione Web può essere completamente soddisfacente: se si comunica attraverso un canale non crittografato, l'utente malintenzionato sarà in grado di leggere, modificare e inserire dati arbitrari nelle richieste e nelle risposte del server. Con un cookie di sessione acquisito, sarà anche possibile impersonare te per tutto il tempo in cui il cookie è valido.

Ciò che l'attaccante non può fare è prendere in consegna il tuo account Google o riautentarti con Google in un secondo momento. Questo perché l'autenticazione con Google avviene sempre su SSL e il token concesso scade dopo un determinato periodo di tempo.

Quindi la situazione è in qualche modo migliore che catturare le tue credenziali immediatamente. Tuttavia, come hai detto, un utente malintenzionato sarebbe comunque in grado di rilevare la sessione ed eseguire qualsiasi azione a tuo nome.

Vorrei sollevare la seguente domanda:

Qual è il punto di avere l'autenticazione nell'applicazione?

Se tutta la pagina contiene un contenuto pubblico e verificabili in un modo esterno (ad esempio un mirror debian, dove i pacchetti sono con PGP) e i tuoi utenti non si preoccupano di una terza parte che esamina ciò che visita, la pagina potrebbe non aver bisogno di https. Ma neanche un login.

I motivi comuni per richiedere l'autenticazione includono:

• Ci sono alcuni dati che l'utente può leggere solo dopo aver effettuato l'accesso

• Un utente registrato può inviare messaggi ad altre persone

• Consente all'utente di guadagnare reputazione, mantenendo un'identità che è stata utilizzata solo da lui

• L'account può ricevere alcuni vantaggi ottenuti al di fuori (come l'accesso ai contenuti a pagamento)

Tutti loro sono sconfitti usando http invece di https nella comunicazione, così come quasi ogni altra ragione per inserire un login. Indipendentemente dal fatto che la password non sia stata esposta (il che sarebbe certamente peggiore).

Qualche tempo fa è stato sostenuto il prezzo di acquisto dei certificati, ma oggigiorno ci sono diverse CA che forniscono certificati gratuitamente.

† Angolo di Nitpicker, ci sono alcuni casi estremamente rari in cui la sicurezza non è compromessa da questo. Un esempio è Mega, che ha caricato alcuni javascript comuni con http, ma uno script https ha verificato i loro hash prima di eseguirli. Fragile e più complesso di impostare https ovunque. Non provarlo a casa, ragazzi.

Le tue credenziali sono sicure, ma potrebbe verificarsi il dirottamento della sessione

Una possibilità avrebbe potuto essere che un attaccante avrebbe potuto fare un attacco SSL Strip mentre agiva come Man In Middle, se ciò accadesse, il sito HTTPS verrà servito come HTTP alla vittima. Ma come hai confermato con il sito web che lo hanno fatto intenzionalmente, quindi questa possibilità viene eliminata.

Ora, Google utilizza oAuth2, quindi la stretta di mano con Google sarà su HTTPS e amp; verrai reindirizzato al tuo sito web su HTTP successivamente (accade allo stesso modo con link mentre usi il tuo account google). Il tuo sito web avrebbe generato un token di sessione dopo oAuth. Il rischio che l'HTTP possiede in questo caso è un attaccante può facilmente dirottare la tua sessione e navigare sul sito fingendo di essere te stesso

Hai perfettamente ragione. Escludendo le credenziali di accesso di Google, un utente malintenzionato può eseguire un attacco MITM e intercettare tutte le richieste della vittima. Ti suggerisco di comunicare loro i rischi e reimplementare il protocollo SSL.

"Cosa può andare storto": se lo fai con un'API, tutte le applicazioni iOS progettate per iOS 9 e in esecuzione su iOS 9 utilizzando quell'API smetteranno di funzionare.

Si chiama "App Transport Security" e, a meno che lo sviluppatore non crei un'eccezione per il tuo dominio, http non è accettato e https con connessioni non sufficientemente sicure non è accettato. Poiché la tua API utilizzava https, le app esistenti non hanno un'eccezione per il tuo dominio, quindi smetteranno di funzionare.