Fragnesia漏洞在代理缓存场景下的隐蔽利用

Fragnesia漏洞本质是HTTP/1.1协议中“请求走私”攻击的一种高级变体，它专门针对代理服务器与后端服务器在解析HTTP请求时存在的差异进行隐蔽利用。攻击者通过精心构造一个包含特定“Transfer-Encoding: chunked”头部与矛盾“Content-Length”头部的畸形HTTP请求，诱使代理服务器与后端服务器对请求体的结束位置产生分歧。在代理缓存场景下，这种分歧尤为危险：攻击者可以“走私”一个恶意请求，使其被代理服务器误认为是另一个合法请求的一部分，并导致代理将后续用户的正常请求响应，错误地缓存为攻击者注入的恶意内容。解决之道在于严格统一前后端服务器的请求解析逻辑，彻底禁用有歧义的请求，并对缓存键进行更严格的校验。

要理解Fragnesia，必须先理解HTTP/1.1协议中定义请求体结束的两种方式：明确的Content-Length头部和分块传输编码（Transfer-Encoding: chunked）。根据RFC标准，两者不能共存。然而，许多代理服务器（如Nginx、Varnish等）和后端应用服务器（如Apache、Tomcat等）在处理不严格遵循规范的请求时，会采用不同的容错策略。Fragnesia攻击正是构造了一个同时包含“Content-Length: X”和“Transfer-Encoding: chunked”的请求。代理服务器可能优先采用Transfer-Encoding规则解析，认为请求体在遇到0字节的chunk时结束；而后端服务器可能忽略Transfer-Encoding，只认Content-Length，读取固定X字节作为请求体。这个解析差异就创造了一个“走私”空间：代理看到的请求A结束后，后端认为还有剩余字节，这些剩余字节就会被后端解释为下一个独立的请求B。在缓存代理场景中，如果请求B是一个获取首页的GET请求，其响应可能会被代理服务器缓存，并关联到错误的缓存键上。

单纯的请求走私可以攻击单个用户会话，而结合代理缓存，其危害将指数级放大，演变为“缓存中毒”或“缓存污染”。攻击流程通常分四步：首先，攻击者发送一个精心设计的“走私请求”，其中夹带了另一个完整的恶意请求（例如，GET /index.html HTTP/1.1...）。其次，代理服务器正确解析了第一个请求，并将其转发给后端。接着，后端服务器因解析分歧，将夹带的恶意请求识别为第二个独立请求并执行。关键一步在于，后端对第二个请求（如GET /index.html）的响应，会沿着TCP连接返回到代理服务器。此时，代理服务器误以为这个响应是对它看到的第一个请求的回复，但由于HTTP协议的特性，代理可能会将这个响应内容与它认为的“下一个”来自其他用户的正常请求（例如另一个用户也请求/index.html）的缓存键进行关联。最终，导致所有后续用户访问/index.html时，都从代理缓存中获取到攻击者注入的恶意页面（如包含盗取Cookie的JavaScript代码）。

检测Fragnesia类漏洞，核心在于探测代理与后端对歧义请求的处理差异。一种经典的手工检测方法是发送两个连续的畸形请求，并观察响应。

POST /vulnerable-endpoint HTTP/1.1
Host: target.com
Content-Length: 6
Transfer-Encoding: chunked

0

G

上面的请求中，代理可能看到“0”结束的chunk，认为请求体结束（“G”属于下一个请求）。而后端根据Content-Length: 6，会读取“0\r\n\r\nG”共6个字节作为请求体，而紧跟其后的字符（可能是另一个请求头）则被当作下一个请求。自动化工具如HTTP Request Smuggler、 smuggler.py等，可以系统性地测试CL.TE（前端认Content-Length，后端认Transfer-Encoding）和TE.CL（前端认Transfer-Encoding，后端认Content-Length）等多种场景。在确认存在解析分歧后，构造缓存污染利用载荷需要精确控制HTTP头，尤其是“Host”头和用于生成缓存键的其他头（如“X-Forwarded-Host”）。攻击者可能通过注入一个包含恶意“Host”头的走私请求，使代理将响应缓存到标准URL下，从而污染全局缓存。

彻底防御Fragnesia漏洞需要多层次、纵深防御的策略。首要且最有效的措施是在架构层面统一请求解析行为。

对于Nginx，应确保配置中禁用对歧义请求的容错处理，例如显式检查并拒绝同时包含CL和TE头的请求。对于HAProxy，可以使用“option http-use-proxy-header”来规范协议解析。所有代理应升级到最新稳定版，以应用针对请求走私漏洞的补丁。

应用层面应使用规范的HTTP库，并设置严格的解析模式。例如，在Node.js中使用"http"模块时，应避免使用自定义的原始套接字处理。对于Java应用，确保Servlet容器（如Tomcat）更新至已修复相关CVE的版本。在所有后端服务前部署一个统一的HTTP规范检查网关，过滤所有畸形请求。

缓存键的生成必须包含完整且不可被走私请求篡改的元素。避免仅使用URL路径作为缓存键，应至少将“Host”头部、请求方法纳入哈希计算。对于CDN或缓存服务，启用“缓存键规范化”功能，并禁用对包含可疑头部的请求进行缓存。实施缓存净化（Cache Purging）的紧急响应流程，一旦发现污染可立即清除。

在网络边界部署能够识别HTTP协议异常和请求走私模式的WAF（Web应用防火墙）规则。日志分析系统应监控是否存在大量相同的请求却返回了不同寻常的响应内容，这可能是缓存污染的迹象。建立定期的安全审计，使用自动化工具对生产环境的请求链进行协议一致性测试。

Fragnesia漏洞揭示的不仅仅是单个软件缺陷，而是分布式Web架构中普遍存在的“语义鸿沟”问题。随着微服务、服务网格（如Istio）和云原生API网关的普及，请求穿越的节点增多，每个节点对协议的微小实现差异都可能被放大为安全漏洞。未来，随着HTTP/3（基于QUIC）的逐步部署，其不再使用纯文本而是二进制帧的格式，有望从协议层面减少解析歧义。但在过渡期内，混合部署（HTTP/1.1、HTTP/2、HTTP/3共存）可能引入新的、更复杂的请求走私变体。因此，安全团队必须将协议安全纳入常态化的威胁建模，并推动开发、运维和安全团队共同采用“零信任”原则对待内部服务间的HTTP通信，默认不信任任何传入请求的格式，进行严格校验和规范化。这要求从传统的边界防御思维，转向对应用层数据流本身完整性和一致性的深度保护。