请求走私漏洞

2019年，请求安全研究员James Kettle在黑帽大会上公布了一种针对HTTP协议的走私攻击手法，现场演示中，漏洞他仅凭一个精心构造的请求请求，就让全球顶尖的走私CDN节点吐出其他用户的会话数据。这个漏洞不是漏洞SQL注入，不是请求XSS，而是走私请求走私——一个潜伏在HTTP协议规则缝隙里的幽灵。

要理解它，漏洞你得先知道一个事实：现代网站几乎都套着代理层，请求比如负载均衡器、走私内容分发网络、漏洞反向代理服务器。请求浏览器把请求发给代理，走私代理再转发给后端的漏洞真实服务器。问题来了——两端对请求边界的判定标准并不总是一致。代理认为一个请求结束了，后端却觉得还没完，于是残留的数据被拼接到下一个请求前面，就像传送带上多出来的包裹混进了别人的订单。

具体怎么触发？最常见的套路是利用Content-Length和Transfer-Encoding这两个头。前者告诉服务器“这个请求体有N字节”，后者则用分块编码标记数据流的结束。协议允许两者同时存在，但没规定优先级。前端代理可能优先处理Transfer-Encoding，后端却只认Content-Length。你构造一个同时携带两种头的请求，让代理和后端读取到不同长度的内容，走私就发生了。

举个真实案例。2018年，某大型电商平台被曝出存在请求走私漏洞。攻击者发送一个带有非法分块标记的请求，代理服务器将其视为正常请求转发，但后端解析时却把恶意负载“吞”进连接池。下一个用户访问时，后端误将残留数据当作新请求的一部分处理——攻击者就能直接篡改他人的购物车、读取订单信息，甚至接管管理员会话。整个攻击过程不需要任何暴力破解，纯粹是协议语义的错位。

最麻烦的是，这类漏洞很难被传统防火墙检测。因为攻击载荷看起来就是普通HTTP流量，没有恶意特征码。而且修复起来也头疼，得同时保证代理和后端对请求边界的解析完全一致，但现实中不同厂商的服务器实现千差万别。有些团队干脆禁用Transfer-Encoding，或者强制前端规范化请求头，可这又可能破坏正常业务逻辑。

我个人见过不少开发人员对此不以为然，觉得“代理和后端都是自家部署的，配置一致就行”。但别忘了，云时代你根本控制不了所有中间层——第三方API网关、容器编排系统的Ingress控制器、甚至老旧的内部代理都可能引入不一致。只要有一层解析逻辑不同，走私漏洞就可能复活。

说句实在话，请求走私之所以被低估，是因为它不像SQL注入那样有个明显的报错窗口。它更像一个静默的窃贼，利用协议设计的灰色地带，在不留日志的情况下搬运数据。如果你负责的站点架构里有多层转发，建议立刻检查一下前端和后端对Content-Length与Transfer-Encoding的处理逻辑。别等流量日志里出现异常拼接字段时，才想起这个藏在HTTP头里的老狐狸。

本文地址：http://www.79wt.cn/news/1423e1999838.html