24请求走私

## 概述

HTTP 请求走私是一种干扰网站处理来自一个或多个用户的 HTTP 请求序列的技术。请求走私漏洞通常非常严重，攻击者可以利用这些漏洞绕过安全控制措施，未经授权访问敏感数据，并直接危害其他应用程序用户的安全。

请求走私主要与 HTTP/1 请求相关。但是，支持 HTTP/2 的网站也可能存在漏洞，具体取决于其后端架构。

## 走私方式

如今的 Web 应用程序经常在用户和 服务器之间使用 HTTP 协议，用户将请求发送到前端服务器（有时称为负载均衡器或反向代理），该服务器再将请求转发到一个或多个后端服务器，这种架构在现代云应用程序中越来越常见，在某些情况下甚至不可避免。

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

![image-20250909214857424](https://oss.maolin101.com/image-20250909214857424.png-101.webp)

在这种情况下，前端和后端系统就请求之间的界限达成一致至关重要。否则，攻击者可能会发送模糊的请求，而前端和后端系统会对此做出不同的解释：

![image-20250909214927578](https://oss.maolin101.com/image-20250909214927578.png-101.webp)

通常而言，攻击者会让前端请求的一部分被后端服务器解释为下一个请求的开始。干扰应用程序处理该请求的方式，这就是一种前期走私的方式。

## 漏洞原理

大多数造成HTTP请求走私漏洞的原因是HTTP/1 规范中提供了两种不同的方式来指定请求的结束位置：Content-Length 与  Transfer-Encoding请求头字段。

Content-Length（CL）请求头字段：明确指定了请求 Body 的字节长度。例如：

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

q=smuggling
```

Transfer-Encoding（TE）请求头字段：用于指定**消息体（请求体或响应体）传输编码方式**。

当服务器动态生成内容（如实时日志、流数据），无法预先计算总长度时，`Transfer-Encoding` 可通过 “分块编码” 逐步传输数据，无需提前声明总长度。

这意味着消息正文包含一个或多个数据块，每个数据块由以字节为单位的块大小（以十六进制表示）组成，后跟换行符，然后是块内容，消息以大小为零的块结尾。例如：

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

b
q=smuggling
0
```

`chunked` 是 `Transfer-Encoding` 中最重要的取值，用于将消息体分割为一系列 “块（chunk）” 进行传输，每个块包含 “长度标识” 和 “数据内容”，最后以 “长度为 0 的块” 标识传输结束。

由于 HTTP/1 规范提供了两种不同的方法来指定 HTTP 消息的长度，因此一条消息可能同时使用这两种方法，从而导致它们相互冲突。

为了避免这个问题，规范规定，如果同时存在 Content-Length 和 Transfer-Encoding 标头，则应忽略 Content-Length 标头。当只有一台服务器运行时，这可能足以避免歧义，但当两台或多台服务器连接在一起时则不然。在这种情况下，可能会出现以下两个问题：

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

- 某些支持 Transfer-Encoding 标头的服务器，如果该标头以某种方式被混淆，则可能会被诱导不处理该标头。

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

注意：

端到端使用 HTTP/2 的网站本质上可以免受请求走私攻击，由于 HTTP/2 规范引入了一种单一且强大的机制来指定请求的长度。

然而，许多网站拥有支持 HTTP/2 的前端服务器，但却将其部署在仅支持 HTTP/1 的后端服务器中。这意味着前端必须将收到的请求有效地转换为 HTTP/1，此过程称为 HTTP 降级。

## 攻击类型与利用方式

经典的请求走私攻击是将 Content-Length 标头和 Transfer-Encoding 标头放入单个 HTTP/1 请求中，并对其进行操作，以使前端和后端服务器以不同的方式处理该请求。

具体操作方式取决于两个服务器的行为：

- CL.TE：前端服务器使用Content-Length标头，后端服务器使用Transfer-Encoding标头；
- TE.CL：前端服务器使用Transfer-Encoding标头，后端服务器使用Content-Length标头；
- TE.TE：前端和后端服务器都支持 Transfer-Encoding 标头，但可以通过某种方式混淆标头来诱导其中一个服务器不处理它。

**值得注意的是**

这些技术只能使用 HTTP/1 请求来实现，浏览器和其他客户端（包括 Burp）默认使用 HTTP/2 与在 TLS 握手期间明确声明支持 HTTP/2 的服务器进行通信。

因此，在测试支持 HTTP/2 的站点时，您需要在 Burp Repeater 中手动切换协议。

### CL.TE

前端服务器使用Content-Length头，后端服务器使用Transfer-Encoding头，如下：

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

0

GET /smuggled.html HTTP/1.1
Host: vulnerable-website.com
Foo: bar
```

攻击过程：

**前端处理**：看到 `CL: 55`，它认为 Body 有 55 字节。它将整个请求（包括55字节的Body）转发给后端。

**后端处理**：看到 `TE: chunked`，它使用分块编码解析 Body。

- 它读取第一个块：`0\r\n`（表示块大小为0，结束）。
- 它认为**请求到此结束**。

**遗留数据**：后端服务器之后在缓冲区中看到的字节（`GET /smuggled...`）被认为是**下一个独立请求的开始**。当下一个真实用户发送请求时，这个“走私”的请求会前置到他们的请求前，导致他们的请求被破坏或触发恶意操作。

### TE.CL

前端服务器使用Transfer-Encoding头，后端服务器使用Content-Length头，如下：

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

5c
GET /smuggled.html HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=
0

```

攻击过程：

**前端处理**：看到 `TE: chunked`，它使用分块编码解析 Body。

- 读取第一块：`5c`（十六进制，等于92字节），它转发接下来的92字节。
- 读取第二块：`0\r\n`（结束块），请求处理完毕。

**后端处理**：看到 `CL: 4`，它认为 Body 只有 4 字节长。

- 它只读取 `5c\r\n` 这4个字节（`5`, `c`, `\r`, `\n`）作为整个 Body。
- 它认为**请求到此结束**。

**遗留数据**：后面的所有字节（`GET /smuggled.html...`）再次被遗留在线路中，被视为下一个请求。

### TE.TE

前端和后端服务器都支持 Transfer-Encoding 标头，但可以通过某种方式混淆该标头，诱导其中一台服务器不处理该标头。混淆 Transfer-Encoding 标头的方法可能有很多种，例如：

```http
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
```

攻击者需要找到一个前端或后端服务器会忽略的变体，从而有效地创建一个 CL.TE 或 TE.CL 场景。

## 危害

成功的请求走私攻击可以导致毁灭性的后果：

**绕过安全控制**：走私的请求可能绕过前端服务器设置的安全规则（如WAF、访问控制、身份验证），因为前端服务器看不到完整的走私请求。

**劫持用户请求**：将其他用户的请求“捕获”到攻击者控制的页面，窃取他们的 Cookie、令牌或敏感信息。

**执行未授权操作**：以其他用户的身份执行操作，例如更改密码、购买物品、发布内容。

**反射型 XSS 升级为存储型 XSS**：如果反射的 XSS 点存在于请求走私的路径上，可以将其转化为持久的 XSS，影响所有后续访问该页面的用户。

**扫描内部网络**：通过走私请求，攻击者可以扫描和访问后端网络中的内部系统，这些系统通常受到前端服务器的保护。