HTTP请求走私详解

http://dy.163.com/v2/article/detail/F4OE9JKC0511CJ6O.html

　　

　　

　　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请求走私。

　　

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

　　以下面的屏幕截图所示，该请求没有响应选项卡，代表该请求已超时而且存在HTTP请求走私。

　　

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

　　一旦Burp标记了HTTP请求走私，咱们须要确认它确实存在，而且没有误报。

　　发送有效请求的过程以下图所示：

　　

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

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

　　下图说明了这一点：

　　

　　
演示

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

　　

　　若是咱们将其加载到Intruder中，并在响应中查找“405”错误，则代表咱们已成功用初始请求攻击了后端套接字。

　　

　　如上所示，显示了一个“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=” 是请求中的最后一个参数：

　　

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

　　下面的屏幕截图确认了POST请求的最后一个参数字段中的全部内容都将呈如今响应字段中。

　　如今，咱们能够确认

　　1.后端套接字能够被攻击；

　　2.具备有效的POST请求参数输入，该输入将呈如今响应字段中；

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

　　让咱们先看看咱们的请求，该请求的走私有效载荷以下（蓝色文本）：

　　

　　从上图能够看出，这里的请求管道中的第一个请求是有效的发布请求。第二个蓝色是咱们走私的有效载荷。

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

　　
攻击利用

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

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

　　

　　查看咱们在Intruder中找到的响应后，咱们能够看到用户已将其请求附加到咱们的有效载荷中。下图显示了来自用户的GET请求，该请求的所有内容都呈如今咱们的响应字段中。

　　

　　所以，若是有人正在使用应用程序，就不须要针对特定的用户。若是有效载荷正在Intruder中运行，而且有人将请求发送到服务器，咱们将捕获该请求。它将添加到咱们的走私请求中，而后咱们能够窃取他们的会话cookie并劫持他们的账户。

　　本文参考自：https://www.pentestpartners.com/security-blog/http-request-smuggling-a-how-to/