学习日志14：Request Smuggling攻击

本文主要内容摘自freebuf
原文链接：https://www.freebuf.com/articles/web/213360.html

1.Content-Length
用于表示HTTP消息长度，用十进制数字表示的八位字节的数目，Content-Length首部指示出报文中实体主体的字节大小，这个大小是包含了所有内容编码的，比如，对文本文件进行了gzip压缩的话，Content-Length首部指的就是压缩后的大小而不是原始大小。
特殊情况1：Content-Length>实际长度：服务端/客户端读取到消息结尾后，会等待下一个字节，自然会无响应直到超时。
特殊情况2：Content-Length<实际长度：首次请求的消息会被截取，比如参数为12345，Content-Length为2，那么这次请求的消息会被截取为：12。
当Content-Length<实际长度并且开启了“Connection：keep-alive”时，被截断的多余请求将出现在下一次请求的最前面，比如12345，Content-Length为2，那么下一次请求将以345为开头，如345GET HTTP1.1…
Content-Length首部指示出报文中实体主体的字节大小，但如在请求处理完成前无法获取消息长度，我们就无法明确指定Content-Length，此时应该使用Transfer-Encoding：chunked

2.Transfer-Encoding
Transfer-Encoding: chunked是什么？
数据以一系列分块的形式进行发送，Content-Length 首部在这种情况下不被发送，在每一个分块的开头需要添加当前分块的长度，以十六进制的形式表示，后面紧跟着 \r\n，之后是分块本身，后面也是\r\n，终止块是一个常规的分块，不同之处在于其长度为0。
形如：
长度(十六进制)\r\n数据\r\n
长度(十六进制)\r\n数据\r\n
长度(十六进制)\r\n数据\r\n
…
长度(0)\r\n
\r\n
如果报文中包含Transfer-Encoding: chunked首部, 那么Content-Length将被忽略。

3.Content-Length和Transfer-Encoding一起使用
由于HTTP规范提供了以上两种不同方法来指定HTTP消息体的长度，因此单个消息可以同时使用这两种方法，这种情况下，它们就会发生相互冲突。HTTP规范试图通过声明来防止此问题的发生，即：如果Content-Length和Transfer-Encoding标头同时出现在一个请求中，则应忽略Content-Length标头。这种规范在一台服务器接收请求时可以避免出现歧义，但在两台或多台服务器链接收请求时可能会出现问题。

4.Request Smuggling攻击
(1)服务器部署情况
现如今的Web应用通常会在用户和最终应用程序逻辑之间使用大量的HTTP服务器，用以优化分流控制网络流量。客户端用户的请求会经过Front-End前端服务器（有时叫负载平衡器或反向代理），然后转发到一个或多个Back-End后端服务器，Web应用这种类型的架构越来越常见，尤其是在现今云服务的流行概念下，某些环境中不可避免。
(2)漏洞原因
这种部署方式下，前端和后端服务器就不同序列请求之间的界限达成一致非常重要，否则，攻击者可能会发送一个模糊的请求，这样一来，前端和后端系统由于对该请求的结束界限不清，会对这个模糊的请求执行不同的解析处理，从而产生不同的响应结果，Request Smuggling漏洞也由此而生。
(3)攻击方式
将Content-Length和Transfer-Encoding标头放入单个HTTP请求中，并对其进行操控，让前端和后端服务器以不同方式处理请求，这种攻击取决于前端和后端两台服务器对标头的处理方式：
CL.TE：前端服务器使用Content-Length头，后端服务器使用Transfer-Encoding头；
TE.CL：前端服务器使用Transfer-Encoding标头，后端服务器使用Content-Length标头；
TE.TE：前端和后端服务器都支持采用Transfer-Encoding标头，但可以通过某种方式对标头进行模糊构造，导致其中一台服务器对它实行处理。
(4)案例
（a）CL.TE漏洞
这里前端服务器使用Content-Length标头，后端服务器使用Transfer-Encoding标头，因此我们可以执行简单的HTTP请求夹带攻击，如：
POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 13
Transfer-Encoding: chunked

0
SMUGGLED
前端服务器按照Content-Length标头处理并确定请求主体长度为13个字节，直到SMUGGLED结束，并将此请求转发到后端服务器。但后端服务器只支持Transfer-Encoding标头，因此它会将消息体视为分块编码，它按序处理数据块，但第一个块就为0数据块，因此处理终止，后序消息体SMUGGLED不会被执行处理，后端服务器将这些字节视为序列中下一个请求的开始。此时如果前端服务器继续向后端服务器转发请求，那么后端服务器下一个接收到的请求就会是：SMUGGLED+POST=SMUGGLEDPOST的请求方法，这样，后端服务器会返回响应：Unrecognized method SMUGGLEDPOST（未知的请求方法SMUGGLEDPOST）
（b）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，之后解析处理第二个块，它是0长度，因此解析终止。该请求转发到后端服务器后，由于后端服务器采用Content-Length标头，按照其中请求主体长度的3个字节，解析会执行到8之后的行开头，所以SMUGGLED及以下的内容就不会被处理，后端服务器会将余下内容视为请求序列中下一个请求的起始。

(5)漏洞利用
通过不断变换请求，可以检索出更多目标应用的内部敏感信息，有些系统完全依赖前端来保证安全性，一旦绕过前端就能获取到更多后端目标应用的相关信息

(6)可能的防御手段
WAF新增规则：
POST body里有HTTP请求头内容，直接拒绝
POST body长度和content-length不等的请求直接拒绝