Stricto sensu, non puoi veramente avere un test generico. In HTTP, il client annuncia se supporta la compressione con una riga di intestazione Accept-Encoding . Il server si sentirà quindi autorizzato a utilizzare questi schemi di compressione. @Adnan punta a questo post del blog che descrive come si può manualmente inviare una richiesta HTTP a un server e vedere a cosa risponde il server. Come metodo di controllo, per verificare il supporto della compressione HTTP, questo ha due problemi:
-
Non esiste un elenco limitato di possibili algoritmi di compressione. Almeno gzip , deflate e compress sono comuni. Con la compressione a livello TLS, almeno, ogni "metodo di compressione" era specificato da un singolo byte, quindi c'erano solo 255 possibili metodi di compressione (senza contare il metodo "nessuna compressione"), ed era possibile essere esaustivi. Questo non è il caso qui.
-
Il server è libero di applicare la compressione o meno, come meglio crede, su qualsiasi documento. Ad esempio, la documentazione di Apache mostra come la decisione di comprimere può essere fatta in base al tipo del documento di destinazione ma anche la sua collocazione nella struttura della directory del sito. IIS distingue tra "compressione statica" e "compressione dinamica": la compressione statica viene applicata solo sulle pagine o documenti che sono fisicamente file sul disco. Nel caso di IIS, la decisione di comprimere, o meno, viene quindi presa in base a come viene generata la pagina richiesta, quindi può variare per ogni singolo URL ...
Non ho ancora molti dettagli sull'attacco, tuttavia mi sento come se fosse, per sua natura, molto specifico per ogni sito di destinazione, quindi abbiamo qualche giorno prima di noi; non è necessario andare in panico e dichiarare il divieto di compressione. Iniziamo ad ottenere alcuni dettagli sull'attacco reale. In altre parole, il "consiglio emergente" mi sembra un po 'prematuro.