In che modo un'applicazione controlla se il suo contenuto http è compresso o meno? Non sto parlando della compressione di livello TLS, ma piuttosto della compressione di https: // solo corpi di risposta.
Nei casi in cui la risposta contenga sia token anti-CSRF che input riflessi dell'utente, credo che una tale compressione possa portare a un compromesso di BREACH. Allora, come faccio a scegliere di non comprimere quelle risposte?
La compressione HTTP è controllata dal server web, si configura IIS / Apache / Other come appropriato e questo imposta l'intestazione di compressione che il browser comprende e tratta il contenuto come di conseguenza.
BREACH è una vulnerabilità in applicazioni che usano la compressione HTTP, riflettono una sorta di input dell'utente e riflettono anche un segreto, come - come dici tu - un token CSRF. l'attaccante quindi trae vantaggio dalle differenze nelle dimensioni di risposta per determinare i segreti. C'è una buona spiegazione di BREAK qui
Semplici attenuazioni includono la disabilitazione della compressione che potrebbe non essere pratica a seconda dell'applicazione. Poiché la compressione viene eseguita a livello di server Web, la determinazione del momento in cui comprimere l'applicazione può essere complicata, un approccio più semplice consiste nell'iniezione di rumore sulla risposta in pagine vulnerabili. Una stringa casuale di lunghezza casuale iniettata nella risposta è una buona contromisura se si desidera mantenere abilitata la compressione.
Leggi altre domande sui tag http compression