HTTP Request Smuggling：一个请求，两种解读

前端代理和后端服务器对同一个 HTTP 请求的边界判断不一致——这就是 Request Smuggling 的全部内核。听起来简单，但它能造成的后果远比想象中严重。

场景是这样的：很多部署架构在用户和源站之间放了反向代理（Nginx、HAProxy、CloudFront 等），代理收到请求后转发给后端。关键在于，代理和后端如何判断"这个请求在哪结束"？有人靠 Content-Length，有人靠 Transfer-Encoding: chunked。如果两者对同一份请求的解析结果不同，代理认为这是一个请求，后端可能认为这是两个——或者反过来。攻击者利用这个缝隙，把自己的payload"塞进"下一个用户的请求里，伪装成那个用户的身份操作。

最经典的变体是 CL-TE：代理认 Content-Length，后端认 Transfer-Encoding。攻击者构造一个边界模糊的请求，后端会把"溢出"的数据当成下一个请求的开头。后果包括绕过访问控制、窃取其他用户的 session token、投毒 Web 缓存。2019 年 Salesforce 的研究团队披露，亚马逊、Azure 等主流平台都受影响，整个行业狠狠地震了一次。

防御层面，最根本的做法是让代理和后端使用完全相同的解析逻辑——但现实中这并不容易保证。更务实的策略包括：代理层拒绝同时包含 CL 和 TE 头的请求、对后端连接禁用 keep-alive 复用、以及配置代理将 Transfer-Encoding 标准化后再转发。



#Security