Django fornisce il middleware GZip, ma i documenti pubblicano un avviso severo su BREACH , che fino ad allora avevo dimenticato. Il primo pensiero che ho avuto è stato che dovevo essere in grado di modificare il middleware in modo da aggiungere prima una quantità casuale di caratteri casuali nel corpo della richiesta prima di rimuoverlo e rendere BREACH inutile. È corretto o sto fraintendendo completamente il BREACH?
Se hai sempre la stessa quantità di dati casuali, probabilmente l'attacco funzionerà ancora allo stesso modo. Se invece aggiungi una quantità casuale di dati casuali, l'attacco originale potrebbe non funzionare più, ma penso che possa essere modificato semplicemente tentando ancora e ancora nella speranza che la stessa quantità di dati casuali venga aggiunta abbastanza spesso. Il che significa che rallenterà solo l'attacco e quanto dipende dalla quantità di dati casuali che aggiungi. Ad esempio se aggiungi tra 1 e 10 caratteri casuali nella parte superiore del file, probabilmente rallenterà l'attacco di un fattore 10. Se aggiungi 1.100 caratteri il rallentamento sarà il fattore 100.
Un approccio migliore sarebbe quello di creare un valore casuale e modificare il token CSRF in modo che sia costituito da questo valore casuale e un XOR o con questo valore con il token CSRF originale. In questo modo il token CSRF cambierà tutto il tempo all'interno dell'HTML in modo che BREACH non funzioni più. E l'applicazione può facilmente recuperare il token CSRF originale.
add a random amount of random characters into the request body before GZipping it
Questo rallenterà l'attacco, ma non lo impedirà.
L'idea alla base di BREACH (e degli oracoli di compressione in generale) è che il testo in chiaro (e quindi il testo cifrato) sarà leggermente più corto se l'hacker indovina correttamente il prossimo byte del token segreto. Se c'è una certa casualità nella lunghezza del testo in chiaro, l'attaccante può fare la stessa ipotesi molte volte e "mediare" i risultati. Le richieste fatte usando l'ipotesi corretta saranno leggermente più basse in media .
(Un vero aggressore userebbe una tecnica statistica più sofisticata per ridurre il numero di richieste richieste, ma tu hai l'idea.)
Leggi altre domande sui tag compression exploit known-vulnerabilities