有些师傅说国内挖不到HTTP请求走私，挖不到HTTP请求拆分，挖不到WEB缓存投毒。因为长久以来很少有师傅分享国内的这种漏洞的实战案例，几乎绝大多数实战案例都出自于国外，所以给大家造成一种错觉，似乎国内不存在这种漏洞。

但是实际情况并非如此。我在2023年的时候，就挖到了不少和HTTP请求相关的有趣漏洞，该种漏洞累积赏金拿了不下10w元。我敢肯定的说，“国内挖不到HTTP请求走私，挖不到HTTP请求拆分，挖不到WEB缓存投毒” 这种说法并不正确， 今天我就来给大家分享一个之前挖到的、有趣的、国内SRC的高危实战案例 ：HTTP请求拆分导致的HTTP请求走私漏洞。

一、故事的开始

某天，我发现某站点存在CRLF注入导致的请求拆分漏洞，但是经过一番探索，我发现上游服务器并不是存储桶，而是某个配置了基于Host 的请求转发的反向代理。

通过黑盒测试结果，我猜测该站点的架构可能类似于如下这种形式:

client ----> 反向代理1 --CRLF--> 反向代理2 --Host--> (web server1 | web server2 | web server3 | ...)

反向代理1将请求转发给上游的反向代理2时发生了CRLF注入， 反向代理2收到请求报文后，根据请求报文的Host请求头来转发请求报文给对应的web 服务器。

比如：

Host:case.target.com ----> web server1

Host:www.target.com ----> web server2

Host:user.target.com ----> web server3

...

这个案例有趣的点在于，反向代理1和反向代理2之间的通信是支持pipeline的。

也就是说: 反向代理1可以一口气给反向代理2发送多个HTTP请求报文：

step1. 反向代理1 ----> http请求报文1 ----> 反向代理2

step2. 反向代理1 ----> http请求报文2 ----> 反向代理2

step3. 反向代理1 ----> http请求报文3 ----> 反向代理2

...

而无需每一次发送都等待对应的响应报文:

step1. 反向代理1 ----> http请求报文1 ----> 反向代理2

step2. 反向代理1阻塞等待反向代理2返回对应的响应报文

step3. 反向代理1 ----> http请求报文2 ----> 反向代理2

step4. 反向代理1阻塞等待反向代理2返回对应的响应报文

...

正是因为这种特性，我发现当我通过CRLF注入来走私HTTP请求报文时，反向代理1似乎会将从上游服务器收到的多个响应报文合并为一个响应报文返回给我:

https://case.target.cn/%20HTTP/1.1%0d%0aHost:case.target.cn%0d%0a%0d%0aPOST%20/%3fid=%20HTTP/1.1%0d%0aHost:targ