Imperva Cloud WAF 曾存在一个绕过漏洞，允许攻击者在发送恶意 HTTP POST 载荷（如 log4j 漏洞利用、SQL 注入、命令执行、目录遍历、XXE 等）时规避 WAF 规则。
Imperva 团队从收到报告的那一刻起就非常重视此事，并在短短几天内拿出了全球性的修复方案。值得称赞。截至 2021 年 12 月 22 日，所有 Cloud WAF 客户均已自动完成修补。与 Imperva 的合作非常愉快，他们显然拥有一支成熟、专业且能力过硬的安全团队。
向 HTTP POST 请求添加 Content-Encoding: gzip 头。保持 POST 数据原样，不要对其进行编码。只要 Content-Encoding 头的前四个字节是 gzip，WAF 规则就不会应用于 POST 请求。
你可以通过 Burp 代理的 Match & Replace（匹配与替换）功能来实现这一点：
像这样添加一个新头：
就这样，搞定。
对支持 POST 请求的 URL 运行 imperva_gzip.py，如下所示：
语法：
./imperva_gzip.py [[-t] | [-r]] URL
猜测给定 URL 的 WAF 类型：
$ ./imperva_gzip.py -t https://www.vulnerable.com/search
Imperva Incapsula
$ ./imperva_gzip.py -t https://www.wordpress-user.com/login
WordFence
$ ./imperva_gzip.py -t https://www.cloudflare-customer.com
Cloudflare
检查 WAF 是否存在 gzip 绕过漏洞：
$ ./imperva_gzip.py https://www.vulnerable.com/search
[+] Can we make POST requests to https://www.vulnerable.com/search?
[+] Checking for Imperva WAF...
[+] Attempting gzip bypass for UNIX trigger...
[+] Vulnerable! HTTP response code: 200
[+] Attempting gzip bypass for Windows trigger...
[+] Vulnerable! HTTP response code: 200
如果你遇到以下错误：
$ ./imperva_gzip.py https://www.vulnerable.com/search
[+] Can we make POST requests to https://www.vulnerable.com/search?
[!] Can't POST to https://www.vulnerable.com/search. Try -r if 30x redirects are allowed. HTTP response code: 302
那么请尝试在命令行上传递 -r 以启用宽松模式。宽松模式默认关闭，这意味着 POST 请求预期会从服务器得到 HTTP 200 响应。-r 将可接受的响应扩展到 HTTP 2xx、3xx。
imperva_gzip.py 的退出码如下：
0: Returned after getting WAF type.
1: Command-line was invalid.
2: There was an error connecting. Could be DNS error, timeout, etc.
3: No WAF was detected; malicious UNIX/Windows payloads weren't blocked.
4: A WAF was detected, but it wasn't Imperva.
5: The server responded to a test POST request with something other than HTTP 200.
128: There is an Imperva WAF, but it is not vulnerable to the gzip bypass.
129: The bypass was effective for the UNIX payload, but not the Windows one.
130: The bypass was effective for the Windows payload, but not the UNIX one.
131: The bypass was effective against both Windows and UNIX payloads.
发送三个 POST 请求：
&test=../../../../../../../etc/shadow），以验证 Imperva 会将其阻止Content-Encoding: gzip 头，并验证 Imperva 不会阻止它根据 https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding，`Content-Encoding` 头有四个有效值：
compressdeflategzipbr在测试中，只有 gzip 可以作为绕过手段。
Cloud WAF 由 Imperva 管理。因此，Cloud WAF 的更新几乎会同时影响几乎所有客户。截至 2021 年 12 月 22 日，所有客户均已获得修补。
gzip 绕过漏洞已在 Imperva 的另一款产品 SecureSphere 中得到修复。SecureSphere v12.6 的发布说明中包含以下段落：
SPHR-58185：当 SecureSphere 无法解压带有 “Content-Encoding: gzip/deflate” 头的请求中的 POST 正文时，它不会发出警报，而是放行该请求。
我很确定这是同一个漏洞，也许与 Cloud WAF 有着相同的代码渊源……这么具体的漏洞出现在两款产品中，实在不寻常。该问题于 2021 年 2 月在 SecureSphere 中得到解决，但我们不知道它是什么时候引入的。这个漏洞很可能已经存在多年了！
Imperva 客户支持：https://www.imperva.com/support/technical-support/