http请求走私底漆

One of the security issues you might face with your website or web app is request smuggling.

您的网站或网络应用可能面临的安全问题之一是请求走私。

HTTP request smuggling is a security vulnerability that allows an attacker to interfere with the way a server processes the HTTP requests it receives. It allows attackers to bypass security controls and gain access to data that they shouldn’t have access to.

HTTP请求走私是一个安全漏洞，攻击者可以利用该漏洞来干扰服务器处理收到的HTTP请求的方式。 它使攻击者可以绕过安全控制并获得对他们不应该访问的数据的访问权限。

In this article, we will cover:

在本文中，我们将介绍：

• How someone can engage in HTTP request smuggling
  某人如何进行HTTP请求走私
• How you can protect yourself and minimize the likelihood that an attacker can engage in this type of attack against you
  您如何保护自己并最大程度地降低攻击者对您进行这种攻击的可能性

背景：网站和应用程序的服务器基础结构 (Background: Server Infrastructure for Websites and Applications)

Before we talk more about HTTP request smuggling, let’s take a look at a typical server infrastructure for modern websites and applications:

在我们进一步讨论HTTP请求走私之前，让我们看一下现代网站和应用程序的典型服务器基础结构：

1. The end-user sends requests to a front-end server
   最终用户将请求发送到前端服务器
2. The front-end server forwards the requests to back-end servers; this utilizes the concepts of keep-alive and pipelining and is typically done by sending multiple requests using the same network connection to improve efficiency and performance
   前端服务器将请求转发到后端服务器。 这利用了保持活动和流水线的概念，通常是通过使用同一网络连接发送多个请求来完成的，以提高效率和性能
3. The back-end servers process the requests; to distinguish one request from another, the server parses the HTTP request headers to determine where one request end and where the next begins
   后端服务器处理请求； 为了将一个请求与另一个请求区分开来，服务器解析HTTP请求标头，以确定一个请求在哪里结束以及下一个请求在哪里开始

As you can see, the front- and back-end servers need to agree on where the start and the end of requests are, otherwise parts of one message may be mistakenly included with another request (and where the term request smuggling comes from).

如您所见，前端服务器和后端服务器需要就请求的开始和结束位置达成一致，否则一条消息的一部分可能会错误地包含在另一个请求中(以及术语“ 走私请求”来自何处)。

服务器如何理解请求在哪里开始和结束 (How Servers Understand Where Requests Start and End)

HTTP request smuggling works by using the headers of the request to “trick” the server into misinterpreting where a request ends. The HTTP specification provides you with two ways to specify where a request ends:

HTTP请求走私通过使用请求的标头来“欺骗”服务器以误解请求的结束位置而起作用。 HTTP规范为您提供了两种方法来指定请求的结束位置：

• The Content-Length header

  Content-Length标头

• The Transfer-Encoding header

  传输编码标头

内容长度标题 (The Content-Length Header)

The Content-Length header allows you to specify the length of the message body in bytes:

Content-Length标头允许您以字节为单位指定消息正文的长度：

POST / HTTP/1.1Host: shiftleft.ioContent-Type: application/x-www-form-urlencodedContent-Length: 23

传输编码标头 (The Transfer-Encoding Header)

The Transfer-Encoding header lets you specify that your message body utilizes chunked encoding (or that the message body contains one or more data chunks). They include the following:

通过Transfer-Encoding标头，您可以指定消息正文使用分块编码(或消息正文包含一个或多个数据块)。 它们包括：

• The chunk size in bytes
  块大小(以字节为单位)
• A newline
  换行符
• The contents of the chunk
  块的内容

To indicate the end of a message, you would include a chunk of zero bytes.

为了指示消息的结尾，您将包括一个零字节的块。

POST / HTTP/1.1Host: shiftleft.ioContent-Type: application/x-www-form-urlencodedTransfer-Encoding: chunked14\r\nHelloShiftLeft\r\n0\r\n\r\n

使用两种方法指定HTTP消息的长度 (The Use of Two Methods to Specify the Length of an HTTP Message)

The HTTP specification allows the use of both the Content-Length and the Transfer-Encoding headers, which means that an attacker could include both methods in a single message, making sure that the information contained in the two headers contradict one another.

HTTP规范允许同时使用Content-Length和Transfer-Encoding标头，这意味着攻击者可以在一条消息中同时包含这两种方法，从而确保两个标头中包含的信息彼此矛盾。

Though the HTTP specification states that the Content-Length header should be ignored in favor of the Transfer-Encoding header if both are present, there can still be ambiguity, especially if multiple servers are handling requests.

尽管HTTP规范指出如果同时存在Content-Length标头，而应该使用Transfer-Encoding标头，则应该忽略它们，但仍然存在歧义，尤其是当多个服务器正在处理请求时。

More specifically, depending on how the front-end server and the back-end server handle such a request, there may be conflict in interpreting where the message ends and the next one starts, leading to the possibility of smuggling and hence security vulnerabilities.

更具体地，取决于前端服务器和后端服务器如何处理这样的请求，在解释消息的结束位置和下一条消息的开始位置时可能存在冲突，从而导致走私的可能性，从而导致安全漏洞。

执行HTTP请求走私攻击 (Performing an HTTP Request Smuggling Attack)

To perform an HTTP request smuggling attack, the malicious party needs to send both the Content-Length header and the Transfer-Encoding header in a single request, making sure that the request is handled differently by the front- and back-end servers.

为了执行HTTP请求走私攻击，恶意方需要在单个请求中同时发送Content-Length标头和Transfer-Encoding标头，以确保前端服务器和后端服务器对请求的处理方式不同。

As you can see, implementing a successful attack does require that the attacker knows how the individual servers operate.

如您所见，实施成功的攻击确实需要攻击者知道各个服务器的运行方式。

HTTP请求走私攻击示例＃1 (HTTP Request Smuggling Attack Example #1)

Let’s take a look at what happens when the front-end server uses the Transfer-Encoding header and the back-end uses the Content-Length header.

让我们看一下前端服务器使用Transfer-Encoding标头而后端使用Content-Length标头时会发生什么。

Our request is as follows:

我们的要求如下：

POST / HTTP/1.1Host: shiftleft.ioContent-Length: 2Transfer-Encoding: chunked23UnauthorizedInformation0

This is what happens when the two servers process the request:

当两个服务器处理请求时，将发生以下情况：

• The front-end server, using the Transfer-Encoding header, processes the first chunk (which is UnauthorizedInformation) because it was told the chunk is 23 characters long
  前端服务器使用Transfer-Encoding标头来处理第一个块(即UnauthorizedInformation)，因为它被告知该块的长度为23个字符
• The front-end server then processes the next chunk, which is 0; it then terminates the request and forwards everything to the back-end server
  然后，前端服务器处理下一个块，即0； 然后终止请求并将所有内容转发到后端服务器
• The back-end server, which is using the Content-Length header, sees that the body is only 2 bytes long; as such, it only processes the first two bytes, ignoring the subsequent information and including it with the following request it handles
  使用Content-Length标头的后端服务器看到主体只有2个字节长； 这样，它仅处理前两个字节，而忽略后续信息，并将其包含在它处理的以下请求中

HTTP请求走私攻击示例2 (HTTP Request Smuggling Attack Example #2)

Let’s take a look at the reverse situation, where the front-end server uses the Content-Length header and the back-end uses the Transfer-Encoding header. We can send a request that looks like:

让我们看一下相反的情况，前端服务器使用Content-Length标头，而后端使用Transfer-Encoding标头。 我们可以发送如下请求：

POST / HTTP/1.1Host: example.comContent-Length: 24Transfer-Encoding: chunked0UnauthorizedInformation

Regarding this request:

关于此请求：

• The front-end server, using the Content-Length header, acts as if the body is 24 characters long
  前端服务器使用Content-Length标头，就像正文是24个字符长
• The back-end server, however, uses the Transfer-Encoding header and sees that the message body is chunked encoded. It processes the first chunk (which you can see from the sample above is size zero) and terminates the request without processing the UnauthorizedInformation portion. This information is then included as part of the next request that it handles
  但是，后端服务器使用Transfer-Encoding标头，并看到邮件正文已分块编码。 它处理第一个块(您可以从上面的示例中看到大小为零)，并在不处理UnauthorizedInformation部分的情况下终止请求。 然后，此信息将作为处理的下一个请求的一部分包括在内

HTTP请求走私攻击示例3 (HTTP Request Smuggling Attack Example #3)

One final example that we’ll go over involves both the front- and the back-end using Transfer-Encoding header. Depending on how it is used and how the attacker chooses to deviate from what is called for by the HTTP specification, you can find some variation so that one of the servers ignores it:

我们将要讨论的最后一个示例涉及使用Transfer-Encoding标头的前端和后端。 根据使用方式以及攻击者如何选择偏离HTTP规范要求的方式，您可以找到一些变化，以便其中一台服务器将其忽略：

Transfer-Encoding: chunkedTransfer-Encoding: xchunkedTransfer-Encoding: chunked #note the space at the beginning of the header

The variations on how to pass in the Transfer-Encoding header possible are endless, but depending on which server is the one not processing the header appropriately, you’ll see behavior similar to one of the examples mentioned above.

关于如何传递Transfer-Encoding标头的变化可能是无止境的，但是取决于哪一台服务器没有适当地处理标头，您将看到类似于上述示例之一的行为。

如何防范HTTP请求走私漏洞 (How to Protect Against HTTP Request Smuggling Vulnerabilities)

In short, HTTP request smuggling vulnerabilities are a possibility if:

简而言之，在以下情况下，可能会出现HTTP请求走私漏洞：

• The front-end server forwards two or more requests to back-end servers over the same network connection (remember, this is done in the name of performance and efficiency)
  前端服务器通过同一网络连接将两个或多个请求转发到后端服务器(请记住，这是以性能和效率的名义完成的)
• The protocol for the back-end connection means that it’s possible the front- and back-end servers disagree about how a specific request should be handled
  后端连接协议意味着前端服务器和后端服务器可能就应如何处理特定请求存在分歧

So, what can you do to prevent these issues? Well, you can:

那么，您该怎么做才能防止这些问题？ 好吧，您可以：

• Require the use of the HTTP/2 protocol (especially on the back-end) to prevent ambiguity about where a request starts and ends; the Transfer-Encoding header (available in HTTP 1.1 only; it is unsupported by HTTP/2
  要求使用HTTP / 2协议(尤其是在后端)，以防止有关请求在何处开始和结束的歧义； 传输编码标头(仅在HTTP 1.1中可用； HTTP / 2不支持该标头)
• Require separate connections for each request (though this may have a negative impact on performance)
  每个请求都需要单独的连接(尽管这可能会对性能产生负面影响)
• Use the same web server for both front- and back-end servers so that they interpret requests identically, reducing ambiguity about where a message starts/ends
  前端服务器和后端服务器使用相同的Web服务器，以便它们以相同的方式解释请求，从而减少了消息在何处开始/结束的歧义

结论 (Conclusion)

HTTP smuggling attacks are a way for malicious parties to influence the behavior of your servers by selectively altering requests that your server handles. This can be as simple as requesting information to which they shouldn’t have access, but it can also be used to force redirects, change hostnames, and more. Protecting yourself is a fairly simple process, even if there are some trade-offs to be had.

HTTP走私攻击是恶意方通过有选择地更改服务器处理的请求来影响服务器行为的一种方式。 这可以像请求他们不应该访问的信息那样简单，但是它也可以用于强制重定向，更改主机名等等。 保护自己是一个相当简单的过程，即使需要权衡取舍。

翻译自: https://blog.shiftleft.io/http-request-smuggling-a-primer-dc5beb2ed9b5