HTTP请求走私详解

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.请求的一部分应反映在响应中；

[1] [2]  下一页