BREACH: un nuovo attacco contro HTTP. Cosa si può fare?

Anche se l'articolo non è pieno di dettagli, possiamo dedurre alcune cose:

• L'attacco utilizza la compressione con lo stesso principio generale di CRIME : l'utente malintenzionato può fare in modo che un sistema di destinazione comprima una sequenza di caratteri che include sia un valore segreto (che l'utente malintenzionato tenta di indovinare) sia alcuni caratteri che l'utente malintenzionato può scegliere. Questo è un attacco di testo normale scelto . La lunghezza compressa dipenderà dal fatto che la stringa dell'attaccante "assomigli" al segreto oppure no. La lunghezza compressa passa attraverso la crittografia SSL, poiché la crittografia nasconde contenuto , non lunghezza .

• L'articolo parla specificamente di "qualsiasi segreto che si trova [...] nel corpo ". Quindi stiamo parlando di compressione a livello HTTP, non di compressione a livello SSL. La compressione HTTP si applica solo al corpo della richiesta, non all'intestazione. Quindi i nell'intestazione , in particolare i valori dei cookie, sono al sicuro da quello.

• Poiché ci sono "richieste di probe", l'attacco richiede del codice dannoso nel browser del client; l'utente malintenzionato deve inoltre osservare i byte crittografati sulla rete e coordinare entrambi gli elementi. Questa è la stessa configurazione di CRIME e BEAST.

• Non è chiaro (dal solo articolo, che è tutto quello che ho ora di cui discutere) se il corpo compresso è uno dal client o dal server . Le "richieste di verifica" sono inviate dal cliente (a nome dell'attaccante) ma le risposte dal server possono includere parte di ciò che viene inviato nella richiesta, quindi l'attacco "plaintext scelto" può funzionare in entrambi i modi.

In ogni caso, "BREAK" sembra una metodologia di attacco che deve essere adattata al caso specifico di un sito di destinazione. In questo senso, non è affatto nuovo; era già "noto" che la compressione perde informazioni e non c'era motivo di ritenere che la compressione a livello HTTP fosse magicamente immune. Diamine, è stato discusso proprio qui l'anno scorso. È comunque positivo che alcune persone facciano il possibile per mostrare dimostrazioni di lavoro perché altrimenti i difetti non verranno mai risolti. Ad esempio, gli attacchi oracle di padding contro CBC sono stati descritti e persino prototipati nel 2002, ma nel 2010 è stata necessaria una vera e propria demo contro ASP per convincere Microsoft che il pericolo era reale. Allo stesso modo per BEAST nel 2011 (la necessità di IV imprevedibile per la modalità CBC era nota anche dal 2002) e CRIME nel 2012; BREAK è più "CRIME II": un altro livello di pedagogia per abbattere i miscredenti.

Sfortunatamente, molte persone sbagliano e credono che si tratti di un attacco contro SSL, cosa che non lo è. Non ha nulla a che fare con SSL, davvero. È un attacco che costringe una perdita di informazioni attraverso un canale dati a bassa larghezza di banda, la lunghezza dei dati , che SSL non ha mai coperto e non ha mai preteso di coprire.

Il riepilogo esecutivo di una riga è che non comprimi .

BREACH, come CRIME, è un attacco relativo alla compressione. Disattivare la compressione rende impossibile l'attacco.

AGGIUNTO
Nota che in questo caso sembra che tu spegni una configurazione di compressione diversa ; mentre CRIME sfrutta la compressione a livello TLS, BREACH sfrutta la compressione a livello HTTP.

Ho appena pensato a un modo per aggiungere "Randomizing secrets per request", "Length hiding" e "Rate-limiting request" a una misura di mitigazione CSRF.

1. Considera quali forme non desideri che un utente malintenzionato desideri sottoporre a POST per conto dell'utente. Queste sono le forme che proteggeresti da CSRF.
2. Per ogni visualizzazione di pagina, genera un salt casuale di lunghezza casuale. Invia questo sale come input nascosto. La lunghezza casuale dovrebbe contribuire ad aggiungere rumore alle lunghezze, anche se il bilanciamento del carico front-end elimina i commenti o comunque minimizza il codice HTML.
3. Calcola un hash di sale, l'ID di sessione e un segreto sul lato server e invia questa chiave CSRF come un altro input nascosto.
4. Facoltativamente registra la chiave salt o CSRF su una tabella. Ciò consente di limitare la frequenza di un determinato account utente o indirizzo IP a un numero di hash all'ora e di limitare i replay di un particolare salt.
5. Quando elabori il modulo, calcola l'hash nello stesso modo dei passaggi precedenti, usa il salt nel modulo e assicurati che corrisponda alla chiave CSRF.

L'attacco funziona inferendo informazioni dalla dimensione del payload. Il riempimento artificiale delle pagine HTTPS (ad esempio una stringa di commento di dimensioni casuali) potrebbe mitigarne l'efficacia.