Innanzitutto, si nota non utilizzando la compressione a livello SSL, ma la compressione a livello HTTP: esiste un'intestazione HTTP che descrive la modalità di compressione. La compressione viene applicata solo alla risposta HTTP body , ad esempio il file colors.min.js
, ad esclusione di qualsiasi altra cosa, in particolare i cookie HTTP o altri valori di questo tipo.
La compressione non è sicura se applicata su valori segreti e l'autore dell'attacco ha la possibilità di ottenere molti esempi di dati compressi con lo stesso segreto ripetuto in tutti loro, ma anche con varianti. In particolare quando l'aggressore arriva a inserire i dati scelti da lui all'interno della sequenza di dati che è compresso.
Nel caso in cui mostri, non ci sono dati segreti; la sequenza di dati che viene compressa è una parte di Javascript completamente pubblica. La compressione è abusata in attacchi dalla sua capacità di divulgare informazioni sui dati contenuti attraverso i dati lunghezza (e la lunghezza non è protetta da alcuna successiva crittografia ). Se i dati di origine sono completamente pubblici, non ci sono informazioni da perdere e quindi nessun attacco.
(Anche se colors.min.js
è pubblico, vuoi comunque superare HTTPS, non per riservatezza ma per integrità : vuoi impedire agli aggressori attivi di modificare Javascript codice al volo.)
Anche se i dati compressi non erano pubblici, un file statico poteva ancora essere servito con compressione, perché la compressione è deterministica e produrrebbe la stessa identica sequenza di byte ogni volta, quindi, in particolare, sempre la stessa lunghezza - niente per imparare per l'aggressore.