Se ho già eseguito un reindirizzamento 301 da tutte le pagine interne HTTP a HTTPS, perché dovrei usare anche HSTS?
Diamo prima un'occhiata allo scenario con un reindirizzamento 301. La vittima invia una richiesta a http://example.com (come sottolineato nei commenti, ciò potrebbe essere dovuto a SSLStrip o perché l'utente ha appena inserito example.com nel La barra degli URL e i browser sono impostati su HTTP per impostazione predefinita) In assenza di attacchi MitM, ricevono una risposta 301 e vengono reindirizzati a https://example.com . Ma se esiste un MitM, l'attaccante può semplicemente scegliere di non inviare il 301, ma invece di servire una copia (eventualmente modificata) del sito su HTTP.
Il punto debole qui è che una connessione HTTP iniziale (senza TLS) e l'attaccante può modificare quel traffico. Tuttavia, se avessi utilizzato HSTS, il browser avrebbe saputo (supponendo che la vittima avesse visitato il sito in precedenza) che la pagina dovrebbe essere sempre servita su HTTPS: nessuna richiesta HTTP sarebbe mai stata inviata e il browser avrebbe semplicemente inviato una richiesta a https://example.com . L'aggressore non può MitM la connessione TLS, quindi l'attacco viene prevenuto.
(Il fatto che i browser memorizzino nella cache le risposte 301 rende questo un po 'più complicato nella pratica. Per maggiori informazioni, vedi bonsaiviking's great rispondi o questa domanda. Il racconto è che il 301 che viene memorizzato nella cache potrebbe aiutare un po ', ma non portarti fino in fondo come fa HSTS.
HTTP Strict Transport Security (HSTS) è progettato per la sicurezza. HTTP 301 spostato in modo permanente viene utilizzato per il reindirizzamento URL.
Il reindirizzamento 301 è una parte importante della distribuzione di un sito Web HTTPS. Come parte del protocollo HTTP, è supportato da più browser rispetto a HSTS. Serve come mezzo principale per aggiornare una connessione in chiaro a HTTPS, aggiornare gli indici di ricerca ed evitare la decomposizione dei link.
In molti casi, questi due metodi hanno lo stesso punto debole: la richiesta iniziale quando l'utente digita "esempio.com" nel browser viene inviato in chiaro. Se la richiesta iniziale viene effettuata su una rete ostile con un man-in-the-middle (MITM) attivo, la risposta può essere intercettata e la connessione non verrà aggiornata a una rete sicura.
Tuttavia, ci sono molte ragioni per cui HSTS è importante e un grande miglioramento della sicurezza rispetto a un reindirizzamento 301 standard:
example.com/ , una richiesta successiva a example.com/somepage utilizzerà inizialmente HTTP e dovrà essere reindirizzato nuovamente. Un sito che utilizza HSTS richiede una sola richiesta per coprire l'intero sito. Prima di tutto, alcuni vecchi browser non supportano HSTS, quindi è ancora necessario reindirizzare HTTP a HTTPS, impostare il flag secure su tutti i cookie, ecc. Ora, detto questo .. .
Oltre ai buoni motivi sopra elencati, poiché sconfiggere gli attacchi di tipo SSLStrip è uno degli scopi principali di HSTS, esiste un altro attacco da cui HSTS protegge ma i semplici reindirizzamenti no.
Supponiamo che un sito venga visitato interamente su HTTPS. L'utente è molto attento e richiede questo sito solo tramite HTTPS. Nessun reindirizzamento necessario. Non c'è HSTS, ma non ci sono nemmeno collegamenti al sito su HTTP non protetto, quindi tutto il traffico con il sito è crittografato.
Tuttavia, supponiamo che il sito abbia una vulnerabilità di sicurezza in cui riflette un cookie specifico (se present) nella pagina senza un corretto escape (XSS basato su cookie, raro ma difficilmente inaudito). L'autore dell'attacco non può effettivamente leggere (tanto meno modificare) il traffico HTTPS, ma desidera davvero accedere alla sessione dell'utente su quel sito HTTPS. Quindi, aspettano che l'utente visiti un altro sito su HTTP e modifichi la risposta da quel sito per includere una richiesta invisibile (forse uno script src) a http: // securesite. com / (il tuo sito solo HTTPS, ma su HTTP invece). Cosa succede dopo:
https://securesite.com/ e l'aggressore non può leggere o modificare il traffico. https: / /securesite.com/ e la richiesta viene nuovamente inviata tramite HTTPS. secure verranno inclusi con quella richiesta iniziale non sicura. L'aggressore può leggerli anche solo tramite intercettazioni passive a quel punto. Non va bene (e questo è un motivo per cui i cookie sensibili devono sempre avere il flag secure anche se il sito non dovrebbe essere mai accessibile tramite una connessione non sicura). sicuri , però, questo rende inutile questo attacco. L'aggressore dovrà manomettere di nuovo. Possono falsificare o modificare la risposta alla richiesta insicura. In questo caso particolare, l'attaccante aggiungerebbe un'intestazione Set-Cookie alla risposta, inserendo un cookie nel browser dell'utente che verrà inviato su richieste future a securesite.com, tramite HTTP o HTTPS. Con l'ipotizzato vettore XSS basato su cookie (o qualsiasi altra cosa in cui un attacco di impianto di cookie può arrecare danno), l'aggressore ha attaccato con successo un sito a cui l'utente è stato molto attento per accedere solo tramite HTTPS , solo perché non utilizzava HSTS e aveva una vulnerabilità che sarebbe stato impossibile sfruttare senza una connessione non protetta.
"). La cosa fondamentale da notare è che la politica della stessa origine per i cookie è più permissiva rispetto alla politica della stessa origine altrove. Cioè, non esiste un unico canale sicuro per i cookie, hanno la stessa origine:
Client ---- Plain HTTP ---- > ServerClient -------- -HTTPS ---- Server > Ovviamente il flag di sicurezza può essere impostato in modo che il valore di un cookie possa essere impostato per il trasferimento solo su HTTPS.
eg
Set-Cookie: foo = bar; sicuro
Client --> HTTP (nessun cookie) --> ServerClient --> HTTPS (Cookie: foo = bar) --> Server Tuttavia, il server non ha modo di sapere se un cookie è stato impostato con il flag di sicurezza.
ad es. su HTTP semplice
Set-Cookie: foo = bar
Client --> HTTPS (Cookie: foo = bar) --> Server Il server si troverà in questa situazione:
Quindi anche se i cookie impostati dal server su HTTPS non sono intercettabili, un MITM può iniettare i propri valori in una sessione "sicura". Ciò è vero anche se non si dispone di un semplice servizio HTTP:
Client ---- Plain HTTP ---- > Nessun servizio Client --------- HTTPS ---- > Server ... perché un MITM può ancora generare una semplice richiesta HTTP al tuo dominio e iniettare il cookie:
Client ---- Plain HTTP ---- > MITM --> No serviceClient --------- HTTPS ------------- > Server Questo può portare ad alcuni attacchi se il tuo sito ha alcune vulnerabilità che altrimenti non potrebbero essere sfruttate:
anche come sopra, gli attacchi in stile ssltrip possono essere eseguiti senza HSTS. sslstrip si basa in una certa misura sul fatto che l'utente non si accorga che il suo non è HTTPS.
Vedi anche questa risposta.
HSTS utilizza un reindirizzamento 307 lato client in modalità sandbox, quindi non raggiunge nemmeno il server finché non è in modalità https esplicita. Un reindirizzamento 301 d'altra parte è lato server, richiede risorse, tempo per il completamento, ecc. Inoltre, un reindirizzamento 301 aumenta il numero di reindirizzamenti [concatenati], che è generalmente attribuito alla diluizione SEO.
Quindi HSTS è generalmente la scelta migliore a causa della sua natura lato client + sandbox. Ma c'è un "pericolo" con un TTL molto lungo nella cache. Quando un SSL scade o se si desidera tornare alla modalità http, gli utenti verranno bloccati. Questo perché il TTL HSTS memorizzato nella cache è / cercherà solo https, ma i browser nogo i siti con un certificato scaduto. Quindi non lasciarlo mai scadere o cambiare modalità senza impostare il tempo della cache HSTS su 0 nelle settimane (o mesi) prima della modifica :) Non devi preoccuparti di questo con 301 poiché non è il browser a decidere reindirizzamento o meno: le persone non verranno bloccate se effettui la modifica lato server.
Poiché HSTS richiede ancora un reindirizzamento la prima volta che ogni utente visita il tuo sito web (a meno che non siamo così sicuri di nessun errore che si possa osare un precaricamento irreversibile tramite registrazione), questa è una domanda trabocchetto. In sostanza non c'è differenza tra l'utilizzo dell'intestazione HSTS e l'utilizzo di un'intestazione di reindirizzamento.
L'unica buona soluzione a cui riesco a pensare è l'aggiunta di un tipo di record o di un flag a ciascun record di zona DNS per specificare "questo dominio supporta HTTPS ". Quindi non c'è bisogno di HSTS o reindirizzamento. Il browser sa già che https è supportato (dalla sua ricerca DNS), quindi può (a meno che non venga annullato dall'utente) riscrivere l'http dell'utente in https prima ancora di inviare la prima richiesta al server remoto.