È passato un anno da quando BREACH ci ha fatto strada nei nostri cuori, e da allora non sembrano esserci articoli o post o patch, il mio indebolimento di Google è diminuito?
BREACH è una vulnerabilità presente quando sono soddisfatte diverse condizioni:
Ognuna di queste condizioni non rappresenta una minaccia in sé, ma combinata porta a una vulnerabilità. Questo è in parte il motivo per cui non esiste una soluzione chiara a questa vulnerabilità: l'aggiornamento di Apache o OpenSSL non è sufficiente. Disabilitare la compressione gzip per tutto non ha molto senso. Riflettendo l'input dell'utente è assolutamente bene la maggior parte del tempo. Non esiste una soluzione semplice, ma negli ultimi anni sono stati compiuti progressi per mitigare BREACH.
Una delle soluzioni più promettenti è il cookie dello stesso sito bandiera . In questo modo i cookie non funzionano più su richieste di origine incrociata, il che risolve gli attacchi CSRF e quindi anche BREAK. Qualcuno sta lavorando su una specifica ed è già implementata in Chrome , Firefox e Edge su Windows 10 .
Ci sono anche diversi progetti che randomizzano la lunghezza della risposta. Alcuni modules metti un commento HTML casuale in ogni risposta, che è un hack totale. Il supporto di riempimento è stato formalizzato in TLS 1.3 , ma ci vorrà del tempo prima che venga implementato nei server.
Alcuni framework hanno anche adottato misure per mitigare gli attacchi BREACH, in particolare per evitare di indovinare il token CSRF. Django randomizza il token CSRF su ogni richiesta, in modo che non possa essere indovinato su più richieste. Questo è relativamente nuovo, pubblicato quest'anno in Django 1.10.
Ci sono stati anche dei progressi per gli attaccanti. Quest'anno i ricercatori hanno dimostrato che BREACH può anche essere convertito in un attacco a tempo (HEIST) , dove è sfruttabile semplicemente eseguendo Javascript nel browser. Infine, un nuovo toolkit (Rupture) è stato sviluppato anche quest'anno per sfruttare le vulnerabilità dei canali laterali di compressione.