HSTS che previene attacchi di dirottamento di cookie MiTM

Question

HSTS che previene attacchi di dirottamento di cookie MiTM

#1 da (3 voti)
#2 da (2 voti)
#3 da (1 voti)

1

Stavo guardando la seguente presentazione:

Ha affrontato il problema durante il tentativo di accedere a un sito Web specifico disponibile su HTTP e HTTS e che la richiesta iniziale verrà inviata tramite HTTP quindi esponendo i cookie agli attacchi di tipo eavesdropping / MiTM e in che modo l'HSTS può risolvere questo tipo di problemi .

La soluzione definitiva sarebbe quella di avere TUTTO il contenuto da servire tramite HTTPS in modo che nessuno scambio di pacchetti venga effettuato tramite HTTP o non lo bloccherà?

Tuttavia, affinché HSTS funzioni in uno scenario HTTP / HTTPS misto, ogni pagina che sto richiedendo (il browser sarà impostato su HTTP) dovrà essere disponibile anche tramite HTTPS, giusto? Se non lo è, HSTS non permetterà affatto di fare una connessione HTTP?

Inoltre, se guardi le 8:22 nel filmato c'è un'illustrazione del processo mentre accedi a un sito (google.com nel suo esempio) dove un cookie viene inviato con la prima richiesta GET via HTTP, qualcuno potrebbe verificare:

a) Questo avverrebbe solo se il sito web è disponibile vi HTTP e HTTPS e un reindirizzamento viene inviato sulla richiesta GET iniziale dal client e dove HSTS non è in posizione (e ho un cookie per quel sito web già su il mio portatile), giusto? b) In uno scenario in cui accedo per la prima volta alla stessa pagina da un altro computer anche senza HSTS abilitato, non c'è alcun rischio perché non ho ancora un cookie dal server Web, quindi non verrà inviato alcun cookie con la richiesta HTTP GET iniziale, corretta? c) Citando da link

Because HSTS directives are delivered via an HTTP header (over an HTTPS connection), HSTS can only instruct a browser to only use HTTPS after the browser's first visit to a secure website.>

Ma questo non creerebbe una porta per gli attacchi MiTM e il dirottamento dei cookie nel caso SOLO quando il server Web non invia un reindirizzamento al client ma continua via HTTP? Intendo dire che nella richiesta HTTP GET del client iniziale non inviamo alcun cookie, il server lo invia, quindi il server web non lo invierà tramite HTTPS al client?

Grazie

T

hsts

posta adam86 21.02.2017 - 16:16

fonte

3 risposte

Leggi altre domande sui tag hsts

WiFi pubblico "sicuro" [duplicato] Come dovrebbe essere consegnata una backdoor? [chiuso]

score 3 · Answer 1

Se stai visitando una pagina Web per la prima volta, anche se usa l'HSTS, sei a rischio di attacchi MiTM poiché la connessione iniziale viene effettuata tramite HTTP e strumenti come sslstrip possono essere utilizzati per sfruttarlo (essenzialmente forzando rimanere su HTTP). Ma se hai già visitato una pagina e il tuo browser è consapevole che questa è una pagina HSTS, allora sslstrip non funzionerà.

La maggior parte dei browser più importanti ha anche elenchi precaricati di alcuni siti HSTS, il che significa che anche se visiti un sito da quell'elenco per la prima volta, sei protetto dagli attacchi MiTM.

score 2 · Answer 2

each page that I’m requesting [...] will have to be available via HTTPS as well, right ? If it’s not, HSTS will not allow to make an HTTP connection at all?

destro. Se abiliti HSTS, devi supportare HTTPS per tutte le pagine. Se imposti la direttiva includeSubDomains, che è consigliata, tutti i sottodomini devono supportare anche HTTPS.

a) This would only happen if the web site is available vi HTTP and HTTPS and a redirect is sent upon the initial GET request from client and where HSTS is not in place (and I have a cookie for that web site already on my laptop), right

No. Non importa ciò che è disponibile. Anche se nessun HTTP è disponibile, puoi comunque inviare la richiesta, quindi divulgare le informazioni a un passivo nel mezzo.

Un utente attivo nel mezzo potrebbe anche intercettare la richiesta HTTP, inoltrarla come richiesta HTTPS al server, leggere la risposta e inviarla a te come richiesta HTTP.

In a scenario where I’m accessing the same page for the very first time from a different computer even without HSTS enabled , there’s no risk because I don’t have a cookie from the web server yet, so no cookie will be sent with the initial HTTP GET request, correct ?

Sì, se non si inviano informazioni sensibili, non verranno esposte informazioni sensibili. Ma come accennato in precedenza, non è ancora sicuro, dato che sei suscettibile a un uomo attivo negli attacchi centrali.

But wouldn’t this create a door for MiTM attacks and cookie hijacking in case ONLY when the web server does not send a redirect to the client but continues via HTTP? I mean in the initial client GET HTTP request we’re not sending any cookie, the server sends it, so wouldn’t the web server send it via HTTPS to the client ?

Un uomo attivo nel mezzo potrebbe semplicemente non inviarti il reindirizzamento a HTTPS, costringendoti così a continuare a comunicare su HTTP.

Per un uomo passivo nel mezzo, questo è principalmente vero. Un problema esiste se i cookie durano più a lungo di HSTS e l'utente non visita la pagina per un po '. Quindi, la loro prima richiesta potrebbe essere tramite HTTP, rivelando così un cookie.

Alcuni dei problemi sopra menzionati possono essere evitati impostando i cookie come sicuri, impedendo quindi di inviarli via HTTP in primo luogo.

score 1 · Answer 3

MITM non è un problema

Se è veramente la tua prima visita a un sito HSTS, non avrai ancora alcun cookie. Devi visitare effettivamente un sito per poter impostare un cookie per te. Quando lo fai, il sito ti reindirizzerà immediatamente alla versione https e nel 99% dei casi non avrà impostato un cookie (il reindirizzamento a https avviene a monte della logica dell'applicazione, ad esempio nelle regole di reindirizzamento sul firewall o in IIS pre-elaborazione). Anche se per qualche motivo imposta un cookie, se è destinato a essere sicuro avrà il sicuro flag impostato, che indica al browser di non presentare il cookie su http.

La correzione della sessione è un problema

Su quella chiamata http iniziale, potresti colpire un sito dannoso che agisce come MitM e potrebbe impostare un cookie. In questo caso, comunque, il cookie è già noto all'hacker, quindi non vi è alcuna preoccupazione di perdere quel valore del cookie a una parte malintenzionata. Tuttavia, vi è un'altra preoccupazione: il cookie potrebbe essere utilizzato per lanciare un attacco di fissazione della sessione . Io attacco questo, il cookie imposta il proprio ID di sessione (ha effettuato l'accesso da qualche altra parte e ha annusato il cookie). Quando si effettua l'accesso, se il sito Web non ripristina il cookie, entrambi condivideranno effettivamente una sessione, il che significa che sarà in grado di visualizzare i dati o eseguire transazioni per proprio conto.