HTTP Requests Smuggling所导致的信息泄露

iso60001  1888天前

22.png

在这篇文章中我将讲述在两个网站中发现的HTTP Request Smuggling漏洞。

关于HTTP Requests Smuggling

如果你还不了解这个漏洞,请务必阅读下面的文章了解漏洞详情。简单来说,就是攻击者的发起的某个请求变成了“受害者”的请求所引发的一系列问题。

aa.png

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来检测。虽然最后我发现了漏洞,但没有成功地利用这个漏洞来控制用户请求。

1.png

在我的搜索中,我发现了一个保存送货地址的功能存在HTTP Request Smuggling。我在相关请求后添加payload,向用户的/configs/web/switches/list路径发出GET请求,该路径涉及用户的敏感信息。

1.png

在这里我使用了Intruder来验证这个漏洞,最终请求返回了用户的敏感信息,“受害者”的请求已被我控制。

第二个漏洞

当我发现第一个漏洞时,我明白了如何更好地检测这类漏洞,在几天后我又发现了第一个漏洞。

这次的目标网站是一个购物网站,结果又在送货地址功能点发现这类漏洞。

我成功让受害者的网页重定向到404页面。

现在我不再满足于控制受害者请求,我决定寻找一个反射点。起初我想找到一个XSS,Self-XSS也行,但很可惜没找到。然后,我决定尝试把“受害者”数据保存到我可以查看的地方。刚开始我选择了“保存地址”中的地址,但我发现有50个字节的限制,经过一段时间的尝试没能成功绕过这个限制。接着我又开始寻找,尝试过“个人资料”等地点,并最终在“打印发票”处找到了发票标题这个合适的地点。

首先,我需要创建一个订单和一个发票,其中发票标题如下所示,位于请求最后。

55.png

接下来我就开始攻击。我利用自己的cookie发送一个请求,将受害者的信息保存为我的发票标题。

66.png

一开始由于我没有在请求中添加Content-length,导致攻击失败。

但最终在调试后攻击成功!我成功得到“受害者”的cookie等敏感信息!!

88.png

感谢阅读这篇文章!可以到我的twitter@C1h2e11来联系我。

本文由白帽汇整理并翻译,不代表白帽汇任何观点和立场
来源:https://medium.com/@cc1h2e1/write-up-of-two-http-requests-smuggling-ff211656fe7d

最新评论

昵称
邮箱
提交评论