当使用负载平衡器时，HTTP请求走私是一个问题吗？

Question

CVE-2022-22720 (ApacheHTTPServer2.4.52漏洞)提到，风险在于HTTP走私。

我对HTTP请求走私的理解是，前端服务器A向后台服务器B发送请求。该请求可以通过服务器B解释的额外联系来“丰富”。

当服务器A有一些关于如何处理请求的情报时，我发现这是一个问题。例如，它终止了一个调用，做出了一些授权决定，并向B请求了一些东西，而B却盲目地提供了一些东西。

但是，如果A只是一个负载均衡器，而到达B的请求是完全由B授权的？HTTP请求走私仍然是一个问题吗？(这个场景在全局上类似于B在前面，出于性能/可用性的原因，它被推到后面)

Answer 1

请求走私攻击包括将内容长度头和传输编码头放置到单个HTTP请求中，并对这些请求进行操作，以便前端和后端服务器处理请求的方式不同。

如果有一个以上的服务器解释响应，您将面临HTTP请求走私的风险。下面是一个示例：

POST / HTTP/1.1
Host: yourwebsite.com
Transfer-Encoding: chunked
Content-Length: 53

0

GET /secret.txt HTTP/1.1
Host: yourwebsite.com   
Foo: x     

由于内容长度标头设置为53，前端将完全正常地解释请求。但是，如果后端使用分块编码，它将读取完全不同的请求。后端将看到此请求在"0“处被切断，超过该0的任何内容都将被解释为一个完整的新请求。这通常会附加在下一个人从web服务器请求任何东西的顶部。这就是为什么包含"Foo: x“标题的原因。后端服务器将看到下一个web请求，如下所示：

GET /secret.txt HTTP/1.1
Host: yourwebsite.com   
Foo: xGET / HTTP1.1Host:yourwebsite.com

对于下一个用户的请求，他们的请求被完全忽略，因为头部被忽略。

此时，由于请求已到达后端，因此后端服务器(在您的情况下是负载均衡器)信任它，并且要么给出响应，要么进一步传递响应。

Answer 2

下面是对请求走私的很好的解释：https://portswigger.net/web-security/request-smuggling

我会说，即使前端服务器只是一个负载均衡器，请求走私也是可能的。

从链接的文件中：

大多数HTTP请求走私漏洞的出现是因为HTTP规范提供了两种不同的方法来指定请求的结束位置:内容长度标头和传输编码头。

例如:攻击者同时发送内容长度和传输编码: chunck -header。前端服务器使用内容长度标头，后端服务器使用传输编码头。标头以- is传递到后端，现在开始。

Answer 3

请求走私就是改变HTTP协议中的消息数量。你认为只有一个消息(比如，一个请求或一个响应)，而另一个演员则认为有更多的消息(比如1、2或1.5，等等)。也可能是负载均衡器计数2，后端计数3，等等。

他们有很多方法来实现这一目标。通常，您会尝试将有关消息大小的信息设置为危险信息。要做到这一点，您可以利用奇怪的HTTP语法(加倍标题、冲突的标头、超大的属性、控制字符、糟糕的时间，.)。

作为一个负载均衡器或作为后端服务器有时并不是很重要，通常成功的攻击需要在负载均衡器和后端服务器上有不同的软件，这对于得到两个参与者对同一流的不同解释是很重要的。

另外，非常重要的是，HTTP管道是一个关键特性(在HTTP/1.1中引入，它不仅仅是Keepalive，还有几条链接消息)。通过流水线，您可以允许HTTP内容流包含多个消息，这解释了为什么负载平衡器在只有一个响应时会受到多个响应的影响，或者为什么后端可以认为有多个请求，而负载平衡器认为只发送了一个请求。在没有流水线的情况下，任何参与者都会在第一条消息之后切断流。

HTTP服务器对HTTP的这种错误使用(改变消息数量)的保护之一是，这通常会生成错误的查询和错误，从而生成400: Bad request或某些50x消息。因为攻击者正在处理解析问题。HTTP声明，任何错误消息也必须关闭连接(在此之后，头Connection: close和tcp/ip套接字将真正关闭)。它还多次指出，奇怪的语法应该会产生错误。

这就防止了一些走私攻击，在这些攻击中，隐藏响应的隐藏查询将在错误发生后出现。如果关闭通信通道，任何剩余的内容都不会对任何参与者造成伤害。所以，发送错误，然后在发送错误后关闭通道。

链接的CVE讨论了不使用错误消息实现这种保护(通过在发出错误时关闭保活通道来关闭http管道)，或者做得不够好(例如，没有从剩余的数据中清除读取缓冲区)。

我不确定这个漏洞是否与真正的攻击联系在一起，但它可能会助长攻击。在响应流中出现错误后，可以生成HTTP活动。没有在错误上实现强制的connection: close是许多HTTP的一个缺陷，而不仅仅是以前版本的Apache。我认为我们在这里看到的是通过更加严格的HTTP来防止未来问题的一种方法，这是Apache最近越来越多地做的事情，比如HttpProtocolOptions Strict指令。