HTTP请求走私攻击

1. 什么是HTTP请求走私?
HTTP请求走私是一种干扰网站处理从一个或多个用户接收到的HTTP请求序列的技术。请求走私漏洞本质上来说通常是非常严重的，它允许攻击者绕过安全控制，获得对敏感数据的未授权访问，并直接危及应用程序其他用户。2005年就被发现这种攻击。

2. 在HTTP请求走私攻击中会发生什么?
今天的web应用程序经常在用户和最终的应用逻辑之间使用HTTP服务链。用户向前端服务器(有时称为负载均衡器或反向代理)发送请求，该服务器将请求转发给一个或多个后端服务器。在现代基于云的应用程序中，这种类型的架构越来越普遍，在某些情况下不可避免。

当前端服务器将HTTP请求转发给后端服务器时，它通常通过同一个后端网络连接发送多个请求，因为这样效率和性能都要高得多。该协议非常简单:HTTP请求一个接一个发送，接收服务器解析HTTP请求头，以确定一个请求在哪里结束，下一个请求在哪里开始

在这种情况下，前端和后端系统就请求之间的边界达成一致是至关重要的。否则，攻击者可能会发送一个不明确的请求，前端和后端系统会对其进行不同的解释

在这里，攻击者使他们的部分前端请求被后端服务器解释为下一个请求的开始。它被有效地附加到下一个请求之前，因此可能会干扰应用程序处理该请求的方式。这是一种请求走私攻击，可能会带来毁灭性的后果。

3. HTTP请求走私漏洞是如何产生的?
大多数HTTP请求走私漏洞的出现是因为HTTP规范提供了两种不同的方法来指定请求的结束位置:Content-Length头和Transfer-Encoding头。

Content-Length头很简单:它以字节为单位指定消息体的长度。例如:

POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11

q=smuggling
Transfer-Encoding头可用于指定消息体使用分块编码。这意味着消息体包含一个或多个数据块。每个块包括：块大小(以十六进制表示)，后面跟着换行符，后面跟着块内容。最后以0结束。例如:

POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked

b
q=smuggling
0
许多安全测试人员没有意识到分块编码可以用于HTTP请求，原因有二:

Burp Suite自动解包分块编码，使消息更容易查看和编辑。

浏览器通常在请求中不使用分块编码，它通常只在服务器响应中看到。

既然HTTP规范提供了两种不同的方法来指定HTTP消息的长度，因此单个消息可能同时使用这两种方法，从而导致它们相互冲突。HTTP规范试图通过声明，如果Content-Length和Transfer-Encoding头同时存在，则Content-Length头应该被忽略，来防止这个问题。当只有一个服务器在运行时，这可能足以避免歧义，但当两个或多个服务器链接在一起时，就不能了。在这种情况下，出现问题的原因有两个:

有些服务器不支持请求中的Transfer-Encoding报头。

一些支持Transfer-Encoding报头的服务器如果以某种方式混淆头，可能会被诱导不处理它。

如果前端和后端服务器对(可能混淆的)Transfer-Encoding头处理方式不同，那么它们可能会对连续请求之间的边界产生分歧，从而导致请求走私漏洞。

4. 如何执行HTTP请求走私攻击
请求走私攻击包括将Content-Length报头和Transfer-Encoding报头放置到单个HTTP请求中，并对它们进行操作，以便前端和后端服务器以不同的方式处理请求。具体的方式取决于两个服务器的行为:

CL.TE: 前端服务器使用Content-Length头，后端服务器使用Transfer-Encoding头。

TE.CL: 前端服务器使用Transfer-Encoding头，后端服务器使用Content-Length头。

TE.TE: 前端和后端服务器都支持Transfer-Encoding头，但可以通过某种方式混淆头来诱导其中一个服务器不处理它。

4.1 CL.TE 漏洞
在这里，前端服务器使用Content-Length头，后端服务器使用Transfer-Encoding头。我们可以执行一个简单的HTTP请求走私攻击:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED
前端服务器处理Content-Length头，并确定请求体的长度为13字节，直到SMUGGLED的末尾。此请求被转发到后端服务器。

后端服务器处理Transfer-Encoding头，因此将消息体视为使用分块编码。它处理第一个块，该块被声明为零长度，因此被视为终止请求。下面的字节走私者未被处理，后端服务器将把它们作为序列中下一个请求的开始。

4.2 TE.CL 漏洞
在这里，前端服务器使用Transfer-Encoding头，后端服务器使用Content-Length头。我们可以执行一个简单的HTTP请求走私攻击:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 3
Transfer-Encoding: chunked

8
SMUGGLED
0

注意：要使用Burp Repeater发送此请求，你首先需要进入Repeater菜单，并确保“Update Content-Length”选项未选中。你需要在最后的0后面包含尾随序列\r\n\r\n。

前端服务器处理Transfer-Encoding头，因此将消息体视为使用分块编码。它处理第一个数据块，这个数据块被认为有8个字节长，一直到SMUGGLED结束。它处理第二个块，该块被声明为零长度，因此被视为终止请求。此请求被转发到后端服务器。

后端服务器处理Content-Length头并确定请求体的长度为3字节，一直到8就结束了。下面的字节(从SMUGGLED开始)未被处理，后端服务器将把这些字节作为序列中下一个请求的开始。

4.3 TE.TE: 混淆TE头
在这里，前端和后端服务器都支持Transfer-Encoding头，但可以通过某种方式混淆头来诱导其中一个服务器不处理它。

可能有无穷无尽的方法来混淆Transfer-Encoding头。例如:

Transfer-Encoding: xchunked

Transfer-Encoding : chunked

Transfer-Encoding: chunked
Transfer-Encoding: x

Transfer-Encoding:[tab]chunked

[space]Transfer-Encoding: chunked

X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked
这些技术都与HTTP规范有细微的不同。实现协议规范的实际代码很少绝对精确地遵守它，对于不同的实现来说，这是很常见的，以容忍与规格的不同变化。发现TE.TE漏洞时，需要找到Transfer-Encoding头的一些变体，以便只有一个前端或后端服务器处理它，而另一个服务器忽略它。

取决于是前端服务器还是后端服务器可以被诱导不处理混淆的Transfer-Encoding头，攻击的其余部分将采取与前文描述的CL.TE或TE.CL漏洞相同的方式。

5. 如何防止HTTP请求走私漏洞
当前端服务器通过相同的网络连接将多个请求转发给后端服务器，而两个服务器对请求边界意见不一致的风险时，HTTP请求走私漏洞就会出现。防止HTTP请求走私漏洞产生的一般方法如下:

禁用后端连接的重用，以便每个后端请求通过单独的网络连接发送。

使用HTTP/2作为后端连接，因为该协议防止了请求之间边界的模糊性。

为前端和后端服务器使用完全相同的web服务器软件，以便它们对请求之间的边界处理一致。

在某些情况下，通过使前端服务器对模糊请求进行规范化或使后端服务器拒绝模糊请求并关闭网络连接，可以避免漏洞的产生。但是，这些方法可能比上面所提到的一般缓解方法更容易出错

:)