HTTP请求走私详解 - 嘶吼 RoarTalk – 网络安全行业综合服务平台,4hou.com

HTTP请求走私详解

luochicun web安全 2020-02-06 09:15:51
1072672
收藏

导语:HTTP请求走私是一种干扰网站处理HTTP请求序列方式的技术,使攻击者可以绕过安全控制,未经授权访问敏感数据并直接危害其他应用程序用户。

01.png

HTTP请求走私是一种干扰网站处理HTTP请求序列方式的技术,使攻击者可以绕过安全控制,未经授权访问敏感数据并直接危害其他应用程序用户。请求走私大多发生于前端服务器和后端服务器对客户端传入的数据理解不一致的情况。这是因为HTTP规范提供了两种不同的方法来指定请求的结束位置,即 Content-Length 和 Transfer-Encoding标头。

HTTP请求走私不是一个新问题,Watchfire(一家安全软件测试公司,2018年被IBM收购)于2005年发布的白皮书就对此进行了详细讨论,除此之外,还有其他介绍HTTP请求走私的资源。但我发现,这些资源缺少的是实用的,可行的参考指南。

这篇文章介绍了我的发现,希望你能对HTTP请求走私的复杂性有更深地了解。

最近我测试了一个web应用程序,它似乎容易受到HTTP请求走私的攻击,我不仅要识别漏洞并向客户证明它的存在,还要在实际操作中演示它。

HTTP请求走私的攻击方式

使用HTTP请求走私的攻击方法有很多,例如跨站点脚本(XSS),其中攻击者以应用程序的用户为目标,而不是攻击者直接以用户为目标。另外还有会话劫持以及服务器端请求伪造(SSRF)。此外,我相信还存在其他仍需要探索的攻击方法。

不过,请求走私也有不同的变体,这些变体由表示攻击中使用的标头的缩写而为人所知。比如CL:CL, CL:TE, TE:TE和TE:CL。 CL表示标头值Content-Length,TE表示报头传输编码。本文为了方便讲解,本文将仅介绍一种请求走私方法的细节。

我将在本文中演示的HTTP请求走私方法称为CL:TE,并且使用此方法,我将执行后端套接字攻击。

发现走私请求

使用Burp Suite Web代理浏览Web应用程序时,你可能会注意到在“仪表板”选项卡中标记了HTTP请求走私。由于缺乏理解,这通常被忽略或被视为误报。

的确,有时此漏洞可能很难被利用和演示,但是通过本文,我希望你对这个概念有个清楚地了解。

首先,让我们看看由Burp Suite标记的HTTP请求走私。

1.png

当它发送具有格式错误的内容长度和传输编码头的请求时,Burp将其标记为HTTP请求走私。当其中一个响应超时时,Burp将把它标记为HTTP请求走私。

如下面的屏幕截图所示,该请求没有响应选项卡,表明该请求已超时并且存在HTTP请求走私。

2.png

如何证明HTTP请求走私攻击的存在

一旦Burp标记了HTTP请求走私,我们需要确认它确实存在,并且没有误报。

发送有效请求的过程如下图所示:

3.png

从上面可以看出,发送了一个有效的请求。前端重写请求,添加后端所需的标头信息,后端处理此请求并返回预期的响应。

因此,要检测到我们发现了HTTP请求走私,我们必须发送格式错误的请求。为此,在下面的示例中,我们在“ Transfer-Encoding”标头和后面的冒号之间添加一个空格。前端将忽略“传输编码:分块”,并使用“内容长度”来确定请求是否有效。然后,前端重写标头并删除使此传输编码标头在发送到后端请求时有效的空间。在本例中,传输编码头到达后端时优先于内容长度标头。

下图说明了这一点:

4.png

演示

下面的截图演示了一个恶意请求,其中有变形的“传输编码”标头,在请求主体的开始处有一个“0”来终止后端请求,还有一个“X”用来攻击后端套接字。

5.png

如果我们将其加载到Intruder中,并在响应中查找“405”错误,则表明我们已成功用初始请求攻击了后端套接字。

6.png

如上所示,显示了一个“405方法不允许”响应。这是因为下一个启动的请求是“XPOST / HTTP/1.1”,因此不是一个有效的请求。

至此可以确认,请求走私确实存在!

PoC

从以上的介绍中我们可以发现,有许多可以与请求走私一起使用的攻击,这些攻击包括:

1.将XSS映射到站点范围的XSS;

2.会话劫持和帐户接管;

3.SSRF;

4.缓存攻击;

5.显示前端请求重写;

我将在以下示例中演示的利用方法是会话劫持和帐户接管。

但是,随着请求走私攻击的发生,所有这些信息就从窗口中消失了,这些cookie不再受到保护!此方法还将显示前端请求重写。

为了能够利用HTTP请求走私并劫持会话,攻击需要满足一些先决条件:

1. CL:TE 后端套接字攻击;

2.请求的一部分应反映在响应中;

我们需要找到一个请求,该请求的一部分反映在响应中。在此示例中,我移动了“maincontent_0%24firstname=” 参数,并将其转换为请求中的最后一个参数。

以下是POST请求有效载荷的后半部分,其中maincontent_0%24firstname=” 是请求中的最后一个参数:

7.png

检查这个POST请求的响应是否在响应中呈现X字符串,如果该字符串被呈现,这将是响应体中的字段,我们将在该字段中找到被利用的用户的请求。

下面的屏幕截图确认了POST请求的最后一个参数字段中的所有内容都将呈现在响应字段中。

8.png

现在,我们可以确认

1.后端套接字可以被攻击;

2.具有有效的POST请求参数输入,该输入将呈现在响应字段中;

然后,我们可以走私该请求,对后端套接字进行攻击。然后,对服务器的下一个请求将附加到我们的走私请求中,并在如上所示的相同响应字段中对我们进行响应。

让我们先看看我们的请求,该请求的走私有效载荷如下(蓝色文本):

9.png

从上图可以看出,这里的请求管道中的第一个请求是有效的发布请求。第二个蓝色是我们走私的有效载荷。

我已经在走私的有效载荷中突出显示了内容长度,因为我们希望添加比请求体中更多的内容长度,这是因为我们需要给被利用的用户请求一些空间,以便将其放置在响应字段中。

攻击利用

我们将带有有效载荷的请求加载到Intruder中,运行时,我们将看到响应内容的长度不同。在我们发送连续请求时,某些攻击者会返回我们自己的响应。但是,如果毫无戒心的用户使用该应用程序,我们将捕获他们发送的请求。他们发送的这些请求将被写入到我们的有效载荷的末尾,并反映在我们接收到的响应字段中。

下面显示的是Intruder的输出。返回的响应长度不同,表明我们已经成功利用了用户,只要他们在我们在Intruder中运行该利用程序的同时就一直在使用该应用程序。

10.png

查看我们在Intruder中找到的响应后,我们可以看到用户已将其请求附加到我们的有效载荷中。下图显示了来自用户的GET请求,该请求的全部内容都呈现在我们的响应字段中。

11.png

因此,如果有人正在使用应用程序,就不需要针对特定的用户。如果有效载荷正在Intruder中运行,并且有人将请求发送到服务器,我们将捕获该请求。它将添加到我们的走私请求中,然后我们可以窃取他们的会话cookie并劫持他们的帐户。

本文翻译自:https://www.pentestpartners.com/security-blog/http-request-smuggling-a-how-to/如若转载,请注明原文地址
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论

 
本站4hou.com,所使用的字体和图片文字等素材部分来源于原作者或互联网共享平台。如使用任何字体和图片文字有侵犯其版权所有方的,嘶吼将配合联系原作者核实,并做出删除处理。
©2022 北京嘶吼文化传媒有限公司 京ICP备16063439号-1 本站由 提供云计算服务