Gli attacchi HTTPS come il CRIME potrebbero essere mitigati modificando regolarmente il cookie di sessione?

3

Stavo leggendo su CRIME che è un attacco per sottrarre informazioni sensibili creando richieste. Questo attacco può essere mitigato se il server non invia al client la chiave di sessione effettiva da salvare in un cookie, ma una stringa generata a caso, che mappa la chiave di sessione? Su ogni richiesta (o ogni 100 richieste) questa stringa casuale viene generata di nuovo, quindi il client avrà un segreto in continua evoluzione nel suo cookie.

Questo renderebbe qualsiasi attacco che richiede molte richieste che contengono lo stesso segreto molto difficile e fornirebbe anche il vantaggio che ciascuna delle stringhe casuali è valida solo per un tempo molto breve ...

Ci sono degli svantaggi ovvi a questo approccio? O tutto ciò che in realtà non renderebbe più sicuro dei metodi attuali?

    
posta Falco 06.08.2014 - 16:40
fonte

2 risposte

3

Nel caso di CRIME, l'attacco è sul client. Il Javascript ostile nel client attiva le richieste al server, che l'utente malintenzionato osserva dall'esterno; e (questo è il punto importante qui) l'attaccante può bloccare la richiesta in uscita. L'utente malintenzionato deve vedere i record crittografati, ma non necessariamente lasciarli andare fino al server.

Quindi, durante tutto l'attacco, il server non vede mai alcuna richiesta con il cookie al suo interno. Anche se il server ha modificato il cookie per ogni richiesta (un "cookie unico"), l'attacco funzionerebbe comunque.

    
risposta data 06.11.2014 - 12:30
fonte
1

Forse, ma se c'è uno script che esegue attacchi con il cookie di sessione immediatamente dopo che è stato intercettato, il danno sarà già fatto. Se una persona sta interagendo con i dati della sessione, potrebbe non essere in grado di agire abbastanza velocemente. In realtà, questo significa che attenuerai gli attacchi non mirati o non sofisticati.

    
risposta data 08.08.2014 - 07:54
fonte

Leggi altre domande sui tag