查找HTTP请求走私漏洞
在本节中，我们将介绍用于发现HTTP请求走私漏洞的不同技术。
使用计时技术发现HTTP请求走私漏洞
检测HTTP请求走私漏洞通用最有效的方法是发送请求，如果存在漏洞，应用程序的响应会出现时间延迟。这种技术被Burp Scanner用于自动检测请求走私漏洞。
使用计时技术发现CL.TE漏洞
如果一个应用程序易受到CL.TE类型请求走私的攻击，那么发送如下请求通常会导致时间延迟：
由于前端服务器使用Content-Length标头，因此它只会转发此请求的一部分，省略X。后端服务器使用Transfer-Encoding标头，处理第一个分块，然后等待下一个分块的到来。这将导致一个可观察到的时间延迟。
使用计时技术发现TE.CL漏洞
如果一个应用程序易受到TE.CL类型请求走私的攻击，那么发送如下请求往往会导致时间延迟：
由于前端服务器使用Transfer-Encoding标头，因此它只会转发此请求的一部分，省略X。后端服务器使用Content-Length标头，期望在消息正文中有更多内容，并等待剩余内容的到来。这将导致一个可观察到的时间延迟。
注意
如果应用程序易受CL.TE类型漏洞的攻击，基于时间的TE.CL漏洞测试将有可能干扰其他应用程序用户。因此，为了隐蔽和减少干扰，应该先使用CL.TE测试，只有在第一个测试不成功时才继续进行TE.CL测试。
使用差异响应确认HTTP请求走私漏洞
在检测到一个可能的请求走私漏洞后，你可以通过利用它来触发应用程序响应内容的差异，从而获得关于该漏洞的进一步证据。这涉及到向应用程序快速连续地发送两个请求：
一个“攻击”请求，旨在干扰下一个请求的处理。
一个“正常”请求。
如果正常请求的响应包含预期的干扰，那么就证实了该漏洞。
例如，假设正常请求如下所示：
这个请求通常会收到一个状态码为200的HTTP响应，其中包含一些搜索结果。
干扰该请求所需的攻击请求取决于存在的请求走私类型：CL.TE与TE.CL。
使用差异响应确认CL.TE漏洞
要确认CL.TE漏洞，你需要发送这样的攻击请求：
如果攻击成功，那么后端服务器将此请求的最后两行视为属于收到的下一个请求。这将使随后的“正常”请求看起来像这样：
由于此请求现在包含一个无效的URL，服务器将以404状态码进行响应，表明攻击请求确实对其造成了干扰。
LAB
使用差异响应确认TE.CL漏洞
要确认TE.CL漏洞，你需要发送这样的攻击请求：
注意
要使用Burp Repeater发送此请求，你首先需要转到Repeater菜单，确保取消选中“Update Content-Length”选项。
需要在最后一个
0之后包含尾随序列\r\n\r。
如果攻击成功，那么从GET /404开始的所有内容都将被后端服务器视为属于收到的下一个请求。这将使随后的“正常”请求看起来像这样：
由于此请求现在包含一个无效的URL，服务器将以状态码404进行响应，表明攻击请求确实对其造成了干扰。
LAB
注意
在尝试通过干扰其他请求来确认请求走私漏洞时，应注意以下几点：
“攻击”请求和“正常”请求应使用不同的网络连接发送到服务器。通过相同的连接发送这两个请求并不能证明漏洞存在。
“攻击”请求和“正常”请求应尽可能使用相同的URL和参数名称。这是因为许多现代应用程序根据URL和参数将前端请求路由到不同的后端服务器。使用相同的URL和参数可以增加请求被同一个后端服务器处理的机会，这对于攻击的成功是至关重要的。
在测试“正常”请求以检测“攻击”请求的任何干扰时，你需要与应用程序同时接收的其他请求（包括其他用户的请求）进行竞争。你应该在“攻击”请求之后立即发送“正常”请求。如果应用程序繁忙，你可能需要进行多次尝试以确认漏洞。
在某些应用程序中，前端服务器充当负载均衡的作用，并根据某种负载均衡算法将请求转发到不同的后端系统。如果你的“攻击”和“正常”请求被转发到不同的后端系统，那么攻击将会失败。这是在确认漏洞之前需要尝试多次的另一个原因。
如果你的攻击成功干扰了后续请求，但这不是你发送的用于检测干扰的“正常”请求，那么这意味着你的攻击影响了另一个应用程序用户。如果继续执行测试，可能会对其他用户产生破坏性影响，你应该谨慎行事。
阅读更多
Last updated