Supponiamo che un utente sia autenticato e che l'intero processo di autenticazione dell'account sia avvenuto in HTTPS protetto.
Dopo il login riuscito, l'utente viene reindirizzato alla home page. Tuttavia, la homepage contiene collegamenti all'interno del sito Web che non hanno SSL abilitato - HTTP di base.
Ad esempio:
Si tratta di una vulnerabilità di sicurezza e, in caso affermativo, quale gravità? Se no, perché? I cookie non sono sicuri quando si passa da HTTPS a HTTP?
In termini di sicurezza di navigazione / privacy, ogni volta che si è sopra http, il traffico potrebbe essere (e spesso è, vedere la discussione della cache di seguito) intercettato e manipolato con i server lungo la strada. Periodo. Non puoi essere sicuro che la pagina che vedi su una connessione http sia effettivamente la pagina che il server web ha inviato in risposta alla richiesta del tuo client web.
Per quanto riguarda il dirottamento di sessione, la risposta è un po 'più complicata. La preoccupazione sarebbe quella di digitare il nome utente e la password su una connessione https, e il server imposta quindi un cookie sul tuo browser che ti identifica. Tale cookie verrà rispedito al server dal tuo browser con ogni successiva richiesta di pagine e il server saprà quindi che stai chiedendo le pagine. La preoccupazione è che qualcuno lungo la strada stava ascoltando e copiato quel cookie. Potrebbero quindi inviare richieste allo stesso sito Web utilizzando il cookie e il sito potrebbe pensare che fossi tu.
L'intestazione Set-Cookie ha un flag sicuro ( vedi qui ) che può essere attivato quando il cookie è originariamente dato al tuo browser. Se questo flag è impostato, il client Web non invierà il cookie al dominio di origine eccetto su una connessione https.
Sarebbe possibile per un sito, ad esempio, avere due cookie di autenticazione, uno dei quali è contrassegnato come sicuro. In questo modo, ogni volta che vuoi fare qualcosa di veramente sensibile, devi avere il cookie sicuro e quindi essere reindirizzato a una pagina https.
In questo caso, i progettisti del sito devono prendere una decisione per pagina su cosa sia "veramente sensibile" e cosa no. Lo scopo di "oops" è enorme. Questa è una delle ragioni per cui è preferibile l'https fino in fondo. Ci sono dei motivi per cui questo non viene fatto da tutti i siti:
(Probabilmente la ragione principale): molte reti (potenzialmente il tuo ISP) gestiscono un server cache che controlla il traffico in uscita dalla rete. Se vede che stai cercando di recuperare il contenuto (tutte le piccole immagini e icone su una pagina popolare per esempio) che altre persone hanno recentemente recuperato, ti darà una versione memorizzata nella cache. C'è tutto il supporto per questo: il sito originale ha un modo per indicare cosa può e non può essere memorizzato nella cache e per quanto tempo. Tutto ciò va bene per l'ISP e il sito originale, poiché significa che entrambi hanno meno banda che attraversa / esce dalle loro reti. Https si rompe, poiché il proxy ora non ha idea di cosa stai chiedendo per il sito originale.
(non è più un problema) L ' è overhead computazionale per impostare una connessione sicura a un sito per la prima volta. Questo era un problema per un server che accetta molte connessioni https. Questo problema è in gran parte scomparso ora - ci sono diversi fattori di mitigazione del protocollo, così come l'hardware di accelerazione e altri metodi che hanno fondamentalmente risolto questo problema. Ne parlo solo nel caso in cui senti che https mette un carico di calcolo pesante sul server: AFAIK che non è più vero.
Sì , tuttavia , questo è uno schema comune.
Ad esempio, questo è il modo in cui l'autenticazione di reddit funziona e quella di Instagram.
Francamente, l'unica cosa contro cui protegge è l'invio della password sulla rete in chiaro. Ma il processo espone la tua sessione e tutti i tuoi dati di navigazione via HTTP, il che significa che la tua sessione ha la stessa potenza di HTTP.
Alcuni altri take away da questo.