Qual è la differenza tra l'utilizzo di HSTS e il reindirizzamento 301?

Diamo un'occhiata allo scenario con un reindirizzamento 301 prima. La vittima invia una richiesta a http://example.com (come indicato nei commenti, ciò potrebbe essere dovuto a SSLStrip o perché l'utente ha appena inserito example.com nella barra degli URL e i browser sono impostati su HTTP). Se non c'è un attacco MitM, ricevono una risposta 301 e vengono reindirizzati a https://example.com . Ma se c'è 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 viene effettuata una connessione HTTP iniziale (senza TLS) e l'utente malintenzionato può modificare quel traffico. Tuttavia, se avessi usato HSTS, il browser avrebbe saputo (supponendo che la vittima avesse visitato il sito in precedenza) che la pagina dovesse sempre essere servita su HTTPS - nessuna richiesta HTTP sarebbe mai stata inviata, e il browser avrebbe solo inviato una richiesta a %codice%. L'attaccante non può MitM la connessione TLS, quindi l'attacco è impedito.

(Il fatto che i browser nascondano 301 risposte rende questo un po 'più complicato in pratica. Per maggiori informazioni su questo, vedi bonsaiviking ottima risposta o questa domanda . Il racconto è che il 301 è in cache potrebbe aiutare un po ', ma non ti porta tutto il modo che fa HSTS.)

HTTP Strict Transport Security (HSTS) è progettato per la sicurezza. HTTP 301 spostato in modo permanente viene utilizzato per il reindirizzamento degli URL.

Il reindirizzamento 301 è una parte importante della distribuzione di un sito Web HTTPS. Come parte del protocollo HTTP, è supportato da più browser di HSTS. Serve come mezzo principale per l'aggiornamento di una connessione in chiaro in HTTPS, l'aggiornamento degli indici di ricerca e l'eliminazione del link rot.

In molti casi, questi due metodi hanno la stessa debolezza: la richiesta iniziale quando l'utente digita "example.com" nel proprio browser viene inviata in chiaro. Se quella richiesta iniziale viene effettuata su una rete ostile con un MITM (man-in-the-middle) attivo, la risposta può essere intercettata e la connessione non verrà aggiornata a quella sicura.

Tuttavia, ci sono molte ragioni per cui HSTS è importante e un grande miglioramento della sicurezza rispetto a un reindirizzamento 301 standard:

• L'HSTS copre l'intero dominio. Un reindirizzamento 301 copre solo un percorso URI specifico. Se un utente viene reindirizzato per example.com/ , una richiesta successiva a example.com/somepage utilizzerà comunque HTTP inizialmente e deve essere nuovamente reindirizzata. Un sito che utilizza HSTS richiede solo una richiesta per coprire l'intero sito.
• HSTS funziona anche con una connessione HTTPS iniziale. Un reindirizzamento 301 esegue solo il mapping di un URI di testo normale a uno HTTPS, pertanto la visita a HTTPS non conferisce alcuna protezione alle visite successive.
• HSTS utilizza una cache separata con un timeout separato. La cache 301 è spesso legata alla cache delle richieste del browser, progettata per le prestazioni. Se non visiti una pagina per un po ', sarà probabilmente cancellato dalla cache per favorire i siti più visitati di frequente. Potrebbe esserci anche un limite massimo per questa cache che è di alcune settimane o mesi. Una soluzione comune per "sito non funziona" sta dicendo all'utente "svuota la cache". Tutto ciò esporrebbe l'utente alla minaccia MITM. I timeout dell'HSTS sono di solito dell'ordine di mesi o anni e la cache di solito è separata, quindi non può essere cancellata facilmente o accidentalmente.
• HSTS può essere precaricato in un browser dal produttore. Google lo fa con il browser Chrome in base alle intestazioni rilevate durante la scansione web e inviate direttamente al loro programma. Per i siti precaricati, il browser non avrà mai bisogno di visitare tramite testo normale in primo luogo; si può sempre presumere che sia solo HTTPS.

Prima di tutto, alcuni vecchi browser non supportano HSTS, quindi devi ancora reindirizzare HTTP a HTTPS, impostare il flag secure su tutti i cookie, ecc. Ora, con quello detto ...

Oltre ai buoni motivi sopra elencati (anche se la risposta di @anders avrebbe dovuto menzionare SSLStrip , dopo averlo sconfitto l'attacco esatto è uno degli scopi principali dell'HSTS), c'è un altro attacco che HSTS protegge contro, ma i reindirizzamenti semplici no.

Supponiamo che un sito venga visitato interamente su HTTPS. L'utente è molto attento e richiede sempre questo sito su HTTPS. Nessun reindirizzamento necessario. Non ci sono HSTS, ma non c'è alcun collegamento al sito tramite HTTP non protetto, quindi tutto il traffico con il sito è crittografato.

Tuttavia, si supponga che il sito abbia una vulnerabilità di sicurezza in cui riflette un cookie specifico (se presente) nella pagina senza escape appropriato (XSS basato su cookie, raro ma difficilmente inedito). L'autore dell'attacco non può effettivamente leggere (molto meno modificare) il traffico HTTPS, ma vuole davvero accedere alla sessione dell'utente su quel sito HTTPS. Quindi, aspettano che l'utente visiti un sito altro 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:

• Se il sito ha una politica HSTS attiva nel browser, il browser automaticamente riscrive la richiesta come https://securesite.com/ e l'autore dell'attacco non può leggere o modificare alcun traffico.
• Se l'utente malintenzionato non effettua la manomissione, ma il sito non ha HSTS, la richiesta si interrompe, ottiene un valore compreso tra 301 e https://securesite.com/ e la richiesta esce nuovamente tramite HTTPS.
  • Tuttavia, qualsiasi cookie per securesite.com ma senza il flag secure su di essi verrà incluso con quella richiesta iniziale non sicura. L'attaccante può leggerli anche solo tramite intercettazioni passive a quel punto. Non va bene (e questo è il motivo per cui i cookie sensibili devono sempre avere il flag secure anche se il sito non dovrebbe essere mai visitato su una connessione non protetta).
• Se tutti i cookie sono secure , ciò rende questo attacco inutile. L'attaccante dovrà nuovamente manomettere. Possono falsificare o modificare la risposta alla richiesta non sicura. In questo caso particolare, l'autore dell'attacco aggiungerà un'intestazione Set-Cookie alla risposta, inserendo un cookie nel browser dell'utente che verrà inviato alle richieste future su securesite.com, su HTTP o HTTPS.

Con il vettore XSS ipotizzato basato su cookie (o qualsiasi altra cosa in cui un attacco di impianto di cookie può fare del male), l'attaccante ha attaccato con successo un sito che l'utente è stato molto attento all'accesso solo tramite HTTPS , solo perché non stava usando HSTS e aveva una vulnerabilità che sarebbe impossibile da sfruttare senza una connessione non protetta.

La cosa fondamentale da notare è che Stessa politica di origine per i cookie è più lassista della stessa politica di origine altrove. Cioè, non esiste un singolo canale sicuro per i cookie, hanno la stessa origine:

Client ----Plain HTTP----> Server
Client ---------HTTPS----> Server

Ovviamente il Flag di sicurezza può essere impostato in modo che un valore di cookie possa essere impostato per il trasferimento solo su HTTPS.

per es.

Set-Cookie: foo=bar; secure

Client --> HTTP  (no cookies)      --> Server
Client --> HTTPS (Cookie: foo=bar) --> Server

Tuttavia, non è possibile per il server sapere se un cookie è stato impostato con il Flag sicuro.

es. su semplice HTTP

Set-Cookie: foo=bar

Client --> HTTPS (Cookie: foo=bar) --> Server

Il server si troverà in questa situazione:

Quindi,sebbeneicookieimpostatidalserversuHTTPSnonsianosniffabili,unMITMpuòimmettereiproprivaloriinunasessione"sicura". Questo è vero anche se non hai un semplice servizio HTTP:

Client ----Plain HTTP----> No service
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 service
Client ---------HTTPS-------------> Server

Questo può portare ad alcuni attacchi nel caso in cui il tuo sito abbia alcune vulnerabilità che altrimenti non potrebbero essere sfruttate:

• Fissazione sessione: In che modo i cookie non protetti o non solo HTTP possono influire sulla sicurezza di un sito Web HSTS?
• Avvelenamento da cookie XSS: Flash cookie e man- in-the-middle

Oltre a quanto sopra, gli attacchi di stile ssltrip possono essere eseguiti senza HSTS. sslstrip si basa su un grado sull'utente che non si accorge che non è un HTTPS.

Vedi anche questa risposta .

HSTS utilizza un reindirizzamento 307 lato client sandboxed, quindi non colpisce nemmeno il server finché non si trova in modalità https esplicita. Un reindirizzamento 301 d'altra parte è lato server, richiede risorse, tempo per il completamento, ecc. Inoltre, un 301 accumula il conteggio del reindirizzamento [incatenato], che è generalmente attribuito alla diluizione SEO.

Quindi HSTS è generalmente la scelta migliore a causa della sua natura client + sandboxed nature. Ma c'è un "pericolo" con un TTL molto lungo nella cache. Quando scade un SSL o se vuoi tornare indietro in modalità http, gli utenti saranno bloccati. Questo perché l'HSTS TTL memorizzato nella cache è / cercherà solo https, ma i browser visualizzeranno i siti con un certificato scaduto. Quindi non lasciarlo mai scadere o cambiare modalità senza impostare il tempo di cache HSTS a 0 nelle settimane (o mesi) prima del cambiamento :) Non devi preoccuparti di questo con 301 poiché non è il browser a prendere la decisione di reindirizzare o meno: le persone non verranno bloccate se esegui il cambio sul lato server.