【思路】某第三方支付对接平台的HTTP请求走私与缓存投毒

一、故事背景

这次对某第三方支付对接平台进行协议层安全测试。目标系统为多个棋牌平台提供代收代付的支付通道系统，接口与资金流水密集。目标采用 CDN + 后端服务的架构，前后端可能由不同的服务处理请求。我在拿到授权后，测试了 HTTP 请求走私漏洞。请求走私的根源是前后端对 HTTP 请求边界（Content-Length 和 Transfer-Encoding）的解析不一致。

二、信息收集

信息收集阶段，我先确认了目标的架构。通过响应头分析，确认前端是 CDN 服务，后端是自建的 Nginx + 应用服务。我用 smuggler 工具对目标进行了请求走私测试，发现前后端对 Transfer-Encoding 头的处理不一致，存在 CL.TE 或 TE.CL 型的请求走私。

三、漏洞发现

确认走私类型后，我开始构造走私载荷。目标是让后端误解析后续的请求，实现请求走私。我构造了一个 CL.TE 走私包，前端按 Content-Length 解析，后端按 Transfer-Encoding 解析，导致后端把下一个正常请求的一部分当作走私请求的内容。

四、漏洞利用

利用请求走私，我进一步测试缓存投毒。如果能通过走私控制缓存服务器的响应内容，就能对大量用户实施攻击。我构造了一个走私请求，让缓存服务器缓存了一个包含恶意 JS 的响应，这个恶意 JS 会被注入到公共页面中，形成存储型攻击效果。

五、权限获取

我验证了缓存投毒的效果：管理员访问被投毒的页面时，会执行我注入的恶意脚本，脚本会窃取会话信息。至此，完成了从协议层漏洞到应用层攻击的完整利用链。我整理了详细的技术报告，包括走私类型的判定、载荷构造、缓存投毒的过程。

六、复盘总结

这次测试说明，协议层漏洞虽然隐蔽，但危害同样严重。修复建议：第一，统一前后端的 HTTP 解析行为，升级到最新版本的代理和应用服务；第二，使用支持 HTTP/2 的代理，减少走私面；第三，对缓存服务器的缓存键做严格控制，防止缓存投毒；第四，定期使用专业的走私检测工具进行测试。

本文为授权安全评估实录，目标均已脱敏（IP 为文档保留段），仅用于安全研究与学习交流。