HTTPS protegge il canale di comunicazione contro le intercettazioni: vale a dire, qualsiasi uomo-in-the-middle che potrebbe leggere il tuo traffico senza che nessuna delle due parti si accorga ora non vedrà altro che dati crittografati e la crittografia viene eseguita in modo può essere annullato solo recuperando la chiave privata del server o attaccando l'algoritmo di crittografia stesso. Inoltre, HTTPS si assicura che il server con cui stai parlando sia effettivamente quello corretto: il certificato punta in modo specifico a un nome di dominio (ad esempio acme.com ) e il server si autentica da solo attraverso il certificato; in questo modo, quando qualcuno dirotta il tuo DNS e punta acme.com sul proprio server, non avrà un certificato valido da servire e l'autenticazione fallirà (questo è ciò che accade quando il tuo browser lancia un enorme segnale di pericolo in faccia ).
Ora, quando si accede a un sito Web, il server deve sapere chi si trova nelle richieste successive, e il modo in cui questo è solitamente (beh, praticamente sempre) è attraverso un cookie di sessione . Questo cookie viene impostato una volta all'accesso e quindi inviato nuovamente al server ad ogni richiesta. Consideriamo ora cosa succede quando tale richiesta non è crittografata: un intercettatore può leggerlo, inclusa l'intestazione Cookie , estrarre il cookie e prendere il controllo del login. Non vuoi quello.
Tecnicamente parlando, solo le richieste sensibili devono contenere il cookie e funzionare su una connessione sicura, ma la combinazione di richieste protette e non sicure all'interno di un documento porta a un'intera cornucopia di altri problemi, ed è semplicemente troppo difficile ottenere quello corretto il consenso generale è che è meglio (più facile e più affidabile) servire semplicemente tutto su HTTPS, inclusi script, immagini, fogli di stile, richieste AJAX e qualsiasi altra cosa tu possa pensare.
Un'altra cosa da tenere a mente: la RFC dei cookie specifica due flag che puoi impostare su un cookie: SECURE e HTTP_ONLY . Per i cookie di sessione, devi sempre impostare entrambi, ed ecco perché:
-
SECURE indica al browser di non inviare mai il cookie su una connessione non protetta. Quando lo si imposta, un utente malintenzionato non sarà in grado di ingannare il browser per inviarlo su una connessione non sicura (e potenzialmente dirottata), che rimuove un'intera classe di angoli di attacco dalla scena. Allo stesso modo, se vi siete persi uno spot e la vostra applicazione invia accidentalmente richieste HTTP da un contesto HTTPS, un intercettatore potrebbe ancora vedere il cookie senza questo flag, ma con esso il browser semplicemente escluderà il cookie dalla richiesta. Non tutti i browser rispettano questa bandiera, quindi hai ancora bisogno di tutte le altre precauzioni, ma tutti i recenti mainstream fanno tutti.
-
HTTP_ONLY significa che il cookie non è accessibile da JavaScript, nemmeno da sola lettura. Ciò impedisce combinazioni di attacchi XSS e Session Hijacking, laddove un utente malintenzionato utilizza XSS per installare JavaScript, quindi legge il cookie di sessione e lo invia a casa. Con il flag HTTP_ONLY , il cookie sarà invisibile a JavaScript, quindi l'attacco non funzionerà.