Hai ragione, la regressione a HTTP è inutile.

Tieni presente che tutti i tuoi punti si applicano a un particolare tipo di attacco, in cui l'avversario è in grado di accedere ai dati trasporto tra client e server. Potrebbe essere il proprietario di un hotspot WiFi o il tuo ISP che funge da man-in-the-middle , che si trova tra te e il server. Questo può essere difficile da ottenere per un utente malintenzionato remoto, ma è particolarmente facile su una rete Wi-Fi pubblica.

Ciò che HTTPS aggiunge a HTTP è trasporto sicuro dei dati . L'applicazione web stessa può funzionare perfettamente: se stai comunicando su un canale non crittografato, l'attaccante sarà in grado di leggere, modificare e iniettare dati arbitrari nelle tue richieste e nelle risposte del server. Con un cookie di sessione acquisito, sarà anche possibile impersonarti fintanto che il cookie è valido.

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

Quindi la situazione è leggermente migliore rispetto all'acquisizione immediata delle tue credenziali. Tuttavia, come hai detto, un utente malintenzionato potrebbe comunque assumere il controllo della sessione ed eseguire qualsiasi azione per tuo conto.

Vorrei sollevare la seguente domanda:

Qual è lo scopo di avere l'autenticazione nell'applicazione?

Se tutta la pagina contiene è contenuto pubblico e verificabile in un modo esterno (es. un mirror Debian, dove i pacchetti sono con PGP) e ai tuoi utenti non importa che una terza parte controlli ciò che visitano, la pagina potrebbe non aver bisogno di https. Ma nemmeno 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

• Permette all'utente di guadagnare reputazione, mantenendo un'identità che utilizza solo da lui

• L'account può ricevere alcuni vantaggi ottenuti all'esterno (come l'accesso a contenuti a pagamento)

Tutti vengono sconfitti da utilizzando http invece di https nella comunicazione, così come quasi ogni altro motivo per inserire un login. Indipendentemente dal fatto che la password non fosse esposta (cosa che certamente sarebbe anche peggio).

Qualche tempo fa si discuteva il prezzo di acquisto dei certificati, ma oggigiorno esistono diverse CA che forniscono certificati gratuitamente.

† Nitpicker, ci sono alcuni casi estremamente rari in cui la sicurezza non viene compromessa da questo. Un esempio è Mega, che caricava alcuni javascript comuni tramite http, ma uno script caricato su https ne verificava gli hash prima di eseguirli. Fragile e più complesso rispetto all'impostazione di https ovunque. Non provateci a casa, ragazzi.

Le tue credenziali sono al sicuro, ma potrebbe verificarsi un dirottamento della sessione

Una possibilità poteva essere che un utente malintenzionato potesse aver effettuato un attacco SSL Strip mentre agiva come l'uomo in mezzo, se in tal caso, il sito Web HTTPS verrà servito come HTTP alla vittima. Ma come hai confermato con il sito web che l'hanno fatto intenzionalmente, quindi questa possibilità viene eliminata.

Ora, Google utilizza oAuth2, quindi la stretta di mano con Google sarà su HTTPS & verrai reindirizzato a dopo di che il tuo sito web su HTTP (succede allo stesso modo con https://security.stackexchange.com/ mentre utilizzi il tuo account Google). Il tuo sito web avrebbe generato un token di sessione dopo oAuth. Il rischio che HTTP possiede in questo caso è che un attaccante può facilmente dirottare la tua sessione e navigare nel sito web fingendo di essere te

Hai assolutamente ragione. Escludendo le credenziali di accesso di Google, un utente malintenzionato può eseguire un attacco MITM e intercettare tutte le richieste della vittima. Ti consiglio di comunicare loro i rischi di una reimplementazione del 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 che utilizzano tale 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 viene accettato e https con connessioni non sufficientemente sicure non viene accettato. Poiché la tua API utilizzava https, le app esistenti non avranno un'eccezione per il tuo dominio, quindi smetteranno di funzionare.