Come evitare la fissazione della sessione (Login CSRF) con MitM attack senza HSTS?

Naviga le tue risposte
2

Sto scrivendo un'app Web che già utilizza connessioni crittografate TLS (HTTPS), cookie di sessione Secure; HttpOnly , token CSRF HMAC-SHA1, richiede un'intestazione Referer corretta per evitare Login CSRF e cambia ID di sessione durante l'accesso per evitare attacchi di fissazione di sessione di base.

Tuttavia, non posso utilizzare HSTS perché lo stesso dominio deve servire alcuni contenuti HTTP per ragioni storiche.

Non riesco a capire come evitare l'attacco MitM che esegue in pratica la fissazione della sessione:

  1. L'attaccante naviga verso https://example.com/login e riceve un nuovo cookie anonimo session-id e il corrispondente HMAC-SHA1 csrf-token incorporato nel modulo di accesso.
  2. L'attaccante completa l'accesso e il server sovrascrive il cookie session-id per il nuovo id utente.
  3. L'attaccante salva il valore di session-id cookie.
  4. La vittima passa a example.com utilizzando HTTP e l'attaccante avvia l'attacco MitM che modifica la risposta in modo che abbia Set-Cookie: session-id=<value-from-attacker-session> e Location: https://example.com/whatever .
  5. Il browser di Victim ora completa l'handshake TLS completo con example.com e fa GET /whatever con Cookie: session-id=<value-from-attacker-session> . In pratica, questo è un completamento dell'attacco di fissazione della sessione poiché Victim sta ora eseguendo la sessione condivisa con l'Attacker.

Certo, questo non è un attacco facile perché richiede un attacco MitM attivo e Victim deve utilizzare la connessione HTTP iniziale a example.com . Inoltre, questo consente solo la fissazione della sessione, non il dirottamento di sessione.

  1. L'HSTS è l'unico modo per evitare questo attacco?
  2. C'è un modo per evitare che i cookie impostati tramite la connessione HTTP siano visibili su una connessione HTTPS identica a Secure; HttpOnly cookie?

Aggiornamento 2014-09-04

Sto assumendo che le seguenti affermazioni siano vere:

  1. La connessione TLS è sicura e l'UA ha un elenco sano di CA affidabili.
  2. L'utente finale può evitare gli attacchi sslstrip -like in cui il browser chrome contiene URL non corretti.
  3. example.com non è presente nell'elenco HSTS precaricato.

Il cookie di guardia suggerito da Steffen Ullrich risolverebbe il problema a parte il fatto che non è in grado di rilevare se l'attacco viene eseguito durante la connessione iniziale. L'implementazione del cookie di guardia eviterebbe comunque l'attacco cambiando la sessione al volo. Attualmente MitM Attacker può sovrascrivere il cookie Secure; HttpOnly originale chiamato session-id con un normale cookie HTTP in qualsiasi momento in futuro, in modo che possa accedere all'UR da qualsiasi URL HTTP per lo stesso dominio. (Questo può essere piuttosto facile perché l'Attacker può reindirizzare qualsiasi connessione HTTP dalla stessa sessione del browser.)

Ancora non riesco a vedere alcun modo per risolvere il problema senza assistenza da parte di UA. Se gli UA avessero solo un modo per dire quali cookie sono stati impostati tramite la connessione TLS invece del semplice vecchio HTTP ...

(Come parte non devo dire che tutti i suggerimenti per rilevare% attacchi di tiposslstrip dal lato server come descritto nella risposta collegata da Steffern Ullrich sembrano vani perché tutti i suggerimenti richiedono l'invio di JavaScript i file che eseguono il rilevamento e sslstrip riguardano strettamente MitM attacker in grado di modificare i file al volo. Pertanto, l'attaccante può facilmente rendere qualsiasi rilevamento JavaScript per restituire sempre "ok".)

Link correlati:  1. Forzare i cookie  2. Accedi CSRF

    
posta Mikko Rantalainen 03.09.2014 - 10:36
fonte

2 risposte

3

How to avoid session fixation (Login CSRF) by MitM attack without HSTS?

Non puoi. Devi avere il tuo sito negli elenchi precaricati dell'HSTS per evitare questo tipo di attacco MITM altrimenti l'attaccante potrebbe MITM la prima connessione e impostare i cookie di sessione per fissarlo alla sessione dell'attaccante.

However, I cannot use HSTS because the same domain needs to serve some HTTP content for historical reasons. ...the historical HTTP content contains embedded IFRAMEs from domains that do not support HTTPS

Questo non dovrebbe impedirti di impostare un criterio HSTS.

Ad esempio, ospita i tuoi contenuti storici su legacy.example.net . Nota che questo deve essere un dominio diverso dal tuo contenuto sicuro ( www.example.com ), non un sottodominio da inviare su elenco precaricato di Chrome as il flag includeSubDomains deve essere impostato sull'intestazione. Se la tua pagina storica era http://www.example.com/iframe.htm , sostituiscila con un reindirizzamento a http://legacy.example.net/iframe.htm . Ciò ti consentirà di pubblicare il contenuto storico HTTP e incorporare un iFrame in un dominio HTTP senza avvisi di sicurezza del browser.

Quindi un utente che naviga ad un contenuto storico con HSTS precaricato otterrà il seguente processo.

  1. L'utente inserisce l'URL normale per il contenuto nella barra degli indirizzi del browser: http://www.example.com/iframe.htm .
  2. Browser controlla il proprio elenco precaricato HSTS e trova www.example.com .
  3. Browser aggiorna la connessione a TLS cambiando l'URL in https://www.example.com/iframe.htm
  4. Il server riceve una richiesta ed emette un reindirizzamento 301 a http://legacy.example.net/iframe.htm
  5. Il server in legacy.example.net visualizza IFrame contenente contenuto HTTP di terze parti e tutti sono felici.

Ciò ti consentirà di usare HSTS per la tua applicazione mentre permetterò al contenuto di hosting IFrame storico di funzionare senza problemi. Inoltre, potresti trovare utile un'altra risposta su protezione contro CSRF di accesso , in quanto copre anche gli attacchi MITM.

    
risposta data 05.09.2014 - 12:18
fonte
2

Domanda interessante. Quello che stai descrivendo è un ambiente in cui l'attaccante monta un attacco man-in-the-middle, in cui può leggere e modificare il traffico HTTP degli utenti ma non il traffico HTTPS. Ciò esclude gli attacchi SSLStrip e SSL man-the-middle in modo da poter visualizzare qui per idee su come rilevare questo tipo di attacchi sul server.

Nell'ambiente che descrivi i seguenti presupposti dovrebbe essere valido:

  • L'utente malintenzionato non può leggere il cookie di sessione originale o qualsiasi altro cookie con i flag Secure e HttpOnly impostati. Inoltre, non è nemmeno in grado di vedere quali cookie sono in uso all'interno di una connessione HTTPS.
  • Ma può leggere, modificare e creare cookie all'interno di HTTP non sicuro. Ciò consentirà inoltre all'utente malintenzionato di creare o modificare cookie con il flag Secure, anche se non può leggerli.

In base a ciò, potrebbe funzionare:

  • Il server invia un cookie di sessione con valore id di sessione con i flag Secure e HttpOnly.
  • Il server invia anche un cookie di "guardia" con un nome in qualche modo basato sull'ID di sessione e il valore "GuardCookie", anche con il flag Secure e HttpOnly e con la stessa durata del cookie di sessione.
  • Ogni volta che il server aggiorna il cookie di sessione, il cookie di guardia riflette la nuova sessione, ovvero se il nome del cookie di guardia deve essere modificato, il vecchio cookie di protezione deve essere invalidato e un nuovo set. O un nome utente specifico del cookie di guardia potrebbe essere scelto in modo casuale al login e incluso hash all'interno dell'ID di sessione.

L'utente malintenzionato può ignorare il cookie di sessione con il proprio e può anche aggiungere il cookie di guardia dalla propria sessione. Ma, non può rimuovere il cookie di guardia dalla sessione degli utenti perché non conosce il suo nome. Pertanto, se il server riceve una richiesta dal client su HTTPS, deve controllare:

  1. È incluso un ID di sessione valido. In caso contrario, la sessione verrà ripristinata.
  2. Il cookie di guardia derivato dall'ID di sessione è incluso? In caso contrario, la sessione verrà ripristinata.
  3. Ci sono altri cookie con il valore "GuardCookie"? In caso affermativo, la sessione viene ripristinata e tutti i cookie di protezione esistenti vengono rimossi.

Con l'ultimo passo il server può rilevare l'attacco di fissazione della sessione, perché l'attaccante non è in grado di rimuovere il cookie di guardia per la sessione originale.

Non sono completamente sicuro che funzioni, ma sembra un approccio degno di una discussione:)

Modifica: come notato dall'utente SilverlightFox, l'attaccante può ancora fissare un nuovo utente senza sessione precedente alla sessione degli attaccanti. Questa idea aiuta solo a rilevare la sostituzione di una sessione esistente.

    
risposta data 03.09.2014 - 14:48
fonte

Leggi altre domande sui tag

Ogni richiesta post include il token csrf? RDP vs VNC quando li guardi dal lato della sicurezza