Stricto sensu, no puedes realmente realizar una prueba genérica. En HTTP, el cliente anuncia si admite la compresión con una línea de encabezado Accept-Encoding . El servidor se sentirá permitido para utilizar estos esquemas de compresión. @Adnan apunta a esta publicación de blog que describe cómo se puede manualmente envíe una solicitud HTTP a un servidor y vea con qué responde el servidor. Como método de auditoría, para verificar la compatibilidad con la compresión HTTP, esto tiene dos problemas:
-
No hay una lista finita de posibles algoritmos de compresión. Al menos gzip , deflate y compress son comunes. Con la compresión de nivel TLS, al menos, cada "método de compresión" estaba especificado por un solo byte, por lo que solo había 255 métodos de compresión posibles (sin contar el método "sin compresión"), y era posible que fuera exhaustivo. Este no es el caso aquí.
-
El servidor es libre de aplicar compresión o no, según lo considere conveniente, en cualquier documento. Por ejemplo, la documentación de Apache muestra cómo se puede tomar la decisión de comprimir para depender del tipo del documento de destino, pero también su ubicación en el árbol de directorios del sitio. IIS hace una distinción entre "compresión estática" y "compresión dinámica": la compresión estática se aplica solo en las páginas o documento que son archivos físicamente en el disco. En el caso de IIS, la decisión de comprimir o no se toma dependiendo de cómo se genera la página solicitada, por lo que puede variar para cada URL individual ...
Aún sin tener muchos detalles sobre el ataque, todavía siento que es como si fuera, por naturaleza, muy específico para cada sitio objetivo, por lo que tenemos algunos días por delante; ya no es necesario entrar en pánico y declarar una prohibición de compresión. Primero vamos a obtener algunos detalles sobre el ataque real. En otras palabras, el "consejo emergente" me parece un poco prematuro.