在这篇文章中我将讲述在两个网站中发现的HTTP Request Smuggling漏洞。
关于HTTP Requests Smuggling
如果你还不了解这个漏洞，请务必阅读下面的文章了解漏洞详情。简单来说，就是攻击者的发起的某个请求变成了“受害者”的请求所引发的一系列问题。
https://portswigger.net/blog/http-desync-attacks-request-smuggling-reborn
从HTTP/1.1协议开始，就支持通过一个底层TCP连接或SSL/TLS套接字发送多个HTTP请求。在这种情况下，多个HTTP请求只是简单地连续放在一起，而服务器会通过解析报头来确定每个请求的开始和结束位置。
我们的消息的结尾必须与前端发送的请求一致。如果攻击者发送一个语句模糊的请求，就有可能被解析为两个不同的HTTP请求。
检测HTTP Requests Smuggling漏洞的首要方法就是发出一个语句模糊的请求，然后再发出一个正常的“受害者”请求，观察能否得到非正常的响应。当然，这非常容易受到干扰，如果另一个用户的请求插在我们两个请求之间，那么他就会中招，而我们观察不到任何异常。这意味着，对于一个实时流量很大的站点，如果不在检验过程中利用大量真实的用户，就很难证明漏洞的存在。即使在其他流量稀少的站点上，也有可能受到连接异常终止的干扰。
第一个漏洞
一开始我的想法是找到所有的功能点，依次进行HTTP Request Smggling检测。我使用了https://github.com/PortSwigger/http-request-smuggler工具来扫描和发现漏洞，利用Intruder去攻击。那时我还不知道如何进一步利用漏洞，所以我只是简单地尝试操控用户请求。
在练习期间我只是简单地搜索所有POST请求，然后在请求后添加了一个简单的payload来检测。虽然最后我发现了漏洞，但没有成功地利用这个漏洞来控制用户请求。
在我的搜索中，我发现了一个保存送货地址的功能存在HTTP Request Smuggling。我在相关请求后添加payload，向用户的/configs/web/switches/list路径发出GET请求，该路径涉及用户的敏感信息。
在这里我使用了Intruder来验证这个漏洞，最终请求返回了用户的敏感信息，“受害者”的请求已被我控制。
第二个漏洞
当我发现第一个漏洞时，我明白了如何更好地检测这类漏洞，在几天后我又发现了第一个漏洞。
这次的目标网站是一个购物网站，结果又在送货地址功能点发现这类漏洞。
我成功让受害者的网页重定向到404页面。
现在我不再满足于控制受害者请求，我决定寻找一个反射点。起初我想找到一个XSS，Self-XSS也行，但很可惜没找到。然后，我决定尝试把“受害者”数据保存到我可以查看的地方。刚开始我选择了“保存地址”中的地址，但我发现有50个字节的限制，经过一段时间的尝试没能成功绕过这个限制。接着我又开始寻找，尝试过“个人资料”等地点，并最终在“打印发票”处找到了发票标题这个合适的地点。
首先，我需要创建一个订单和一个发票，其中发票标题如下所示，位于请求最后。
接下来我就开始攻击。我利用自己的cookie发送一个请求，将受害者的信息保存为我的发票标题。
一开始由于我没有在请求中添加Content-length，导致攻击失败。
但最终在调试后攻击成功！我成功得到“受害者”的cookie等敏感信息！！
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理
