Netty HTTP请求走私漏洞(CVE-2019-16869)深度分析与修复指南<\/h1>

1. 漏洞概述<\/h2>
CVE编号<\/strong>: CVE-2019-16869
漏洞类型<\/strong>: HTTP请求走私(HTTP Request Smuggling)
影响组件<\/strong>: io.netty:netty (所有版本)
发现者<\/strong>: OPPO子午互联网安全实验室
严重性<\/strong>: 高危
漏洞描述<\/strong>: Netty错误地处理了HTTP标头中冒号前的空格(如`Transfer-Encoding : chunked<\/code>)，导致可能被利用进行HTTP请求走私攻击，绕过安全控制，未经授权访问敏感数据。<\/p>`

2. 漏洞原理深度解析<\/h2> 2.1 HTTP请求走私基础<\/h3> HTTP请求走私漏洞的核心原因是前端服务器和后端服务器在处理HTTP请求头时存在差异<\/strong>，导致请求被错误解析。具体表现为：<\/p> Content-Length<\/strong>和Transfer-Encoding<\/strong>头的处理不一致<\/li> 请求可能被错误地分割或合并<\/li> 导致安全边界被绕过<\/li> <\/ul> 2.2 Netty特定实现问题<\/h3> 在Netty 4.1.42.Final之前版本中，splitHeader<\/code>方法处理HTTP头时存在缺陷：<\/p> for<\/span> (<\/span>nameEnd =<\/span> nameStart;<\/span> nameEnd <<\/span> length;<\/span> nameEnd ++)<\/span> {<\/span> <\/span><\/span> char<\/span> ch =<\/span> sb.<\/span>charAt<\/span>(<\/span>nameEnd);<\/span> <\/span><\/span> if<\/span> (<\/span>ch ==<\/span> ':'<\/span> ||<\/span> Character.<\/span>isWhitespace<\/span>(<\/span>ch))<\/span> {<\/span> <\/span><\/span> break<\/span>;<\/span> <\/span><\/span> }<\/span> <\/span><\/span>}<\/span> <\/span><\/span><\/code><\/pre>关键问题<\/strong>:<\/p> 将空格与冒号(:<\/code>)同等处理<\/li> 允许头字段名与冒号之间存在空格(如Transfer-Encoding : chunked<\/code>)<\/li> 不符合RFC 7230标准规范<\/li> <\/ul> 2.3 攻击场景示例<\/h3> 攻击请求<\/strong>:<\/p> POST \/getusers HTTP\/1.1 Host: www.backend.com Content-Length: 64 Transfer-Encoding : chunked 0 GET \/hacker HTTP\/1.1 Host: www.hacker.com hacker: hacker <\/code><\/pre> 攻击流程<\/strong>:<\/p> 前端服务器(如ELB)会忽略Transfer-Encoding : chunked<\/code>(因为空格不符合RFC标准)<\/li> ELB使用Content-Length<\/code>解析，认为是一个完整请求<\/li> 后端Netty服务器优先解析Transfer-Encoding<\/code>(尽管有空格)<\/li> Netty将请求拆分为两个请求，导致请求走私<\/li> <\/ol> 3. 漏洞影响<\/h2> 3.1 直接危害<\/h3> 会话劫持<\/strong>: 获取用户会话凭证和标识符<\/li> 身份伪装<\/strong>: 绕过认证机制，获得未授权访问<\/li> 敏感信息泄露<\/strong>: 获取PII、金融数据等敏感信息<\/li> 业务破坏<\/strong>: 干扰正常业务逻辑和系统配置<\/li> <\/ul> 3.2 潜在风险<\/h3> 绕过WAF和其他安全控制<\/li> 缓存投毒攻击<\/li> 权限提升<\/li> 服务器端请求伪造(SSRF)<\/li> <\/ul> 4. 修复方案<\/h2> 4.1 官方修复<\/h3> Netty在4.1.42.Final版本中修复了该漏洞：<\/p> 修复思路<\/strong>:<\/p> 识别TE[space]: field value<\/code>为错误标头或自定义标头<\/li> 两种处理方式选择：像ELB一样根据header分离请求CL并转发整个header<\/li> 识别为不正确header，返回400(Bad Request)响应码<\/li> <\/ul> <\/li> <\/ol> 代码变更<\/strong>:<\/p> for<\/span> (<\/span>nameEnd =<\/span> nameStart;<\/span> nameEnd <<\/span> length;<\/span> nameEnd ++)<\/span> {<\/span> <\/span><\/span> char<\/span> ch =<\/span> sb.<\/span>charAt<\/span>(<\/span>nameEnd);<\/span> <\/span><\/span> if<\/span> (<\/span>ch ==<\/span> ':'<\/span> ||<\/span> (<\/span>isDecodingRequest()<\/span> &&<\/span> Character.<\/span>isWhitespace<\/span>(<\/span>ch)))<\/span> {<\/span> <\/span><\/span> break<\/span>;<\/span> <\/span><\/span> }<\/span> <\/span><\/span>}<\/span> <\/span><\/span><\/code><\/pre>关键修改<\/strong>:<\/p> 增加了isDecodingRequest()<\/code>条件检查<\/li> 仅在解码请求时处理空格情况<\/li> 对不符合RFC标准的header返回400错误<\/li> <\/ul> 4.2 修复验证<\/h3> 发送包含空格的头字段请求：<\/p> Transfer-Encoding : chunked <\/code><\/pre> 预期结果<\/strong>:<\/p> Netty应返回400 Bad Request响应<\/li> 或正确处理为自定义header而不导致请求走私<\/li> <\/ul> 5. 缓解措施<\/h2> 如果无法立即升级Netty版本，可考虑以下临时方案：<\/p> 前端代理配置<\/strong>:<\/p> 在前端服务器(如Nginx、ELB)上严格校验HTTP头格式<\/li> 拒绝包含非法空格的请求<\/li> <\/ul> <\/li> 应用层防护<\/strong>:<\/p> 实现自定义过滤器检查HTTP头格式<\/li> 对可疑请求进行拦截<\/li> <\/ul> <\/li> 网络层防护<\/strong>:<\/p> 配置WAF规则检测和阻断HTTP走私攻击模式<\/li> 监控异常请求模式<\/li> <\/ul> <\/li> <\/ol> 6. 参考资源<\/h2> NVD漏洞详情<\/a><\/li> GitHub Issue讨论<\/a><\/li> GitHub修复PR<\/a><\/li> 修复提交<\/a><\/li> RFC 7230标准<\/a><\/li> <\/ol> 7. 总结<\/h2> CVE-2019-16869暴露了Netty在HTTP头处理上的严格性问题，通过精心构造的包含空格的HTTP头，攻击者可实施请求走私攻击。该漏洞的修复强调了严格遵循RFC标准的重要性，特别是在处理网络协议时的细节问题。对于使用Netty的开发者和运维人员，应及时升级到修复版本或实施适当的缓解措施，以确保系统安全。<\/p>