Come impedisci di inviare i dati dei cookie su HTTP la prima volta? [duplicare]

12

Potresti utilizzare HSTS per dire al browser di utilizzare sempre HTTPS nelle future richieste.

Potresti utilizzare il flag Cookie Secure che d'ora in poi invierà solo i cookie su HTTPS.

Potresti usare il reindirizzamento basato su DNS ma solo dopo che la richiesta HTTP è arrivata lì ..

La mia domanda è: come assicurati che l'utente visiti sempre il sito come HTTPS e non invii mai dati su HTTP nemmeno la prima volta.

Modifica

Data la mancanza di soluzioni a questo, penso che i browser dovrebbero prima inviare automaticamente la richiesta https per impostazione predefinita e non funziona quindi eseguire il downgrade.

    
posta Muhammad Umer 12.03.2018 - 21:14
fonte

5 risposte

17

Nel sommario dei commenti (e sostituendo la mia risposta precedente): fino a quando sslstrip è possibile, l'attaccante può impersonare l'utente e controllare la sessione mentre il browser pensa che l'utente controlli la sessione. Solo l'HSTS può prevenire sslstrip e solo il preload dell'HSTS può impedire sslstrip alla prima richiesta (prima di ottenere un'intestazione HSTS).

Quindi il precarico HSTS dovrebbe essere la strada da seguire, come indicato correttamente in la risposta di Benoit Esnard .

Il problema è che il precarico HSTS può richiedere mesi per essere disponibile per un nuovo dominio poiché un elenco aggiornato viene spedito solo con una nuova versione del browser (almeno nel caso di Google Chrome).

In altre parole: non esiste una soluzione che possa essere implementata in breve tempo.

    
risposta data 12.03.2018 - 21:31
fonte
14

Invia il tuo sito web alla lista di precarico HSTS .

L'elenco precarico HSTS è un elenco di nomi host incorporati nei browser, che consente loro di sapere quali siti Web devono essere sottoposti a scansione come solo HTTPS, impedendo così qualsiasi richiesta non HTTPS.

    
risposta data 12.03.2018 - 21:27
fonte
6

Quello che stai descrivendo è chiamato Attacco alla fissazione della sessione (link Wikipedia) .

In breve, il problema è che l'utente malintenzionato può fornirti un cookie Session Identifier. Accedi con questo cookie e il server associerà la tua identità a questo cookie.

L'hacker conosce ancora il tuo cookie di identificazione di sessione e può fingere di essere te con il server. Attacco completato.

Per difendersi da questo, il server deve cambiare il cookie dell'ID di sessione quando qualcuno effettua il login. L'utente malintenzionato viene lasciato con un cookie inutile e non può fare nulla.

Non tutti i framework web ti permettono di cambiare il cookie di sessione. Se questo è un problema, è possibile utilizzare un cookie diverso per questo scopo, un "cookie autenticato" separato di cui il framework non è a conoscenza. Anche questo cookie deve essere modificato ogni accesso.

    
risposta data 13.03.2018 - 10:31
fonte
1

Dato che non esiste un modo completo per impedire ai client di connettersi a HTTP, possibilmente con i cookie ... la nostra sfida è trovare modi per ridurre quanto spesso accade.

Un approccio è di non supportare affatto l'HTTP. Lasciate scadere qualsiasi richiesta HTTP (nessun reindirizzamento, niente). Ciò riduce le possibilità di altri siti che si collegano al tuo indirizzo HTTP, dal momento che tali link non funzioneranno. Nel tempo, si spera che tutti coloro che si collegheranno al tuo sito si colleghino direttamente a HTTPS.

    
risposta data 13.03.2018 - 19:35
fonte
0

Non puoi impedire che i cookie inviino inviati via HTTP la prima volta, ma puoi prendere provvedimenti per ridurre al minimo il danno che potrebbe essere causato da questo. Il principio di base è che non si onora mai nulla di ciò che viene inviato tramite HTTP e ogni volta che si ricevono informazioni sensibili in testo non crittografato, le informazioni vengono considerate come compromesse.

Imposta il tuo sito per reindirizzare da HTTP a HTTPS e iniziare a inviare intestazioni di Strict-Transport-Security. (Non devi andare per il precarico finché non sei bravo e pronto, quello che sto per dire funzionerà a prescindere.)

Quindi, ogni volta che vedi i cookie inviati tramite testo non crittografato HTTP, invalida tutti questi cookie sul lato server. Non tentare di eliminarli dal barattolo dei cookie del browser a questo punto, perché non è garantito che funzioni per diversi motivi (un messaggio in chiaro la risposta HTTP non può manipolare i cookie codificati Secure, i browser più vecchi potrebbero ignorare max-age = 0 , il man-in-the-middle potrebbe eliminare del tutto Set-Cookie al fine di mantenere la vittima usando il cookie compromesso). Ma non onorarli quando compaiono in una richiesta HTTPS successiva. A quel punto (vale a dire solo quando è stato stabilito un canale sicuro), emettere un nuovo token di sessione e richiedere all'utente di eseguire nuovamente l'accesso.

Allo stesso modo, se vedi il tuo modulo di accesso presentato in testo non chiaro, non invalida semplicemente il cookie di sessione, blocca l'account . Non reindirizza il recupero dell'account, il login o il modulo di registrazione da HTTP a HTTPS; invia invece un messaggio di errore, istruendo l'umano a correggere l'URL a mano (è come un captcha, ma è per aggirare la riscrittura dell'URL in sslstrip ;-). E qualsiasi pagina che dovrebbe essere accessibile solo agli utenti che hanno effettuato l'accesso dovrebbe reindirizzare alla pagina principale, non a HTTPS stesso, quando vi si accede tramite cleartext.

Inoltre, assicurati che i tuoi cookie di sessione siano entrambi non rimborsabili e privi di significato . La maggior parte dei framework Web lo farà automaticamente al giorno d'oggi, ma se non ne hai uno, la costruzione più semplice che funzionerà è: ogni cookie di sessione è un numero casuale di grandi dimensioni (64 bit potrebbe essere sufficiente, 128 è abbastanza) generato da un RNG crittograficamente sicuro , più un messaggio di autenticazione del codice che firma quel numero. È possibile utilizzare un MAC simmetrico per questo, poiché il cookie deve solo essere autenticato dal sito, che è la stessa entità che ha emesso il MAC, quindi conoscerà lo stesso segreto entrambe le volte. Se un cookie arriva con un MAC non valido, ignoralo , indipendentemente da come lo hai ottenuto - fai finta di non averlo mai capito. (Questo addirittura sostituisce la regola sull'invalidazione dei cookie che arrivano su HTTP. Non vuoi che l'aggressore sia in grado di forzare la disconnessione delle persone forgiando le richieste.) Ma se il MAC è valido, allora usi il numero casuale come chiave per una tabella di database che registra tutte le informazioni effettive associate a una sessione utente.

È inoltre buona norma non emettere alcun cookie fino a quando qualcuno non tenta di accedere. Ciò rende molto più difficile per un MITM mettere le mani su un cookie valido, e rende anche più facile per te rispettare GDPR.

Dopo aver letto la discussione sulle altre risposte, mi rendo conto che l'OP si occupa di uno scenario molto particolare: un nuovo utente al sito lo accede per la prima volta attraverso un uomo-in- the-middle, che sta terminando l'HTTPS, estraendo HSTS e riscrivendo tutti i link e inoltrando il sito in chiaro all'ipotetico nuovo utente. Contro questo, infatti, l'unica cosa che può aiutare è il precarico dell'HSTS. In assenza del precarico HSTS, l'account del nuovo utente sarà "nato compromesso", per così dire, e l'attaccante conoscerà tutto su di esso: non solo il cookie di sessione, ma il nome utente e la password, e l'indirizzo email utilizzato per il recupero dell'account e ogni bit di informazioni personali inserite dalla vittima. Questo è brutto e, ahimè, più plausibile di quanto tu possa pensare.

Ma se hai solo una possibilità di interagire con l'utente su un canale che non viene attivamente manomesso, puoi spingere HSTS e cookie di sessione sicuri e tutti i consigli sopra riportati saranno utili.

    
risposta data 13.03.2018 - 18:37
fonte

Leggi altre domande sui tag