有些师傅说国内挖不到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. 反向代理2 ----> 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

4A评测 - 免责申明

本站提供的一切软件、教程和内容信息仅限用于学习和研究目的。

不得将上述内容用于商业或者非法用途，否则一切后果请用户自负。

本站信息来自网络，版权争议与本站无关。您必须在下载后的24个小时之内，从您的电脑或手机中彻底删除上述内容。

如果您喜欢该程序，请支持正版，购买注册，得到更好的正版服务。如有侵权请邮件与我们联系处理。敬请谅解！

程序来源网络，不确保不包含木马病毒等危险内容，请在确保安全的情况下或使用虚拟机使用。

侵权违规投诉邮箱：4ablog168#gmail.com（#换成@）