利用Burp插件挖掘HTTP请求走私
HTTP请求走私通常遗留在漏洞发现赏金项目中。但通过正确的插件，您
可以在下一个赏金项目中自动化地完成挖掘HTTP请求走私漏洞的过程。
了解HTTP请求走私
现代网站经常部署多个代理服务器用于转发用户请求到托管Web应用程序的真实服务器。这些带有真实后端的前端服务器或代理服务器是云应用中最常见的架构。
前端服务器用于获取多个用户的请求并转发给后端服务器。这两个前后端服务器必须在两个不同用户的请求边界上达成一致。有时候，两者服务器不能在边界上达成一致，攻击者便能够通过利用处理不一致来修改HTTP请求，造成HTTP请求走私。
当前后端服务器对用户请求边界不一致时，就会出现HTTP请求走私。
边界(即)HTTP请求的结尾由"Content-Length"或"Transfer-Encoding" HTTP标头定义。有些服务器不支持"Transfer-Encoding"，有些服务器将"Content-Length"标头作为默认请求结尾的定义(如果两者都出现在请求中)。如果前后端服务器配置不当，它们会取不同的边界值，从而导致请求走私漏洞。
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
Content-Length: 4
存在两个标头的请求示例
攻击者可以在HTTP请求中包含两个不同边界的值的两个标头。如果前端服务器接收"Transfer-Encoding" 而后端服务器接收"Content-Length"标头，因为每个头中的边界值不一致，会导致请求过程受到污染。反之亦然，前端服务器接收"Content-Length"，后端服务器接收"Transfer-Encoding"。前者称为TE.CL,后者称为CL.TE 请求走私漏洞。
前端和后端服务器的这种模棱两可的处理机制会导致HTTP请求走私，用于获取的未授权数据、接管应用程序等。
手工查找HTTP请求走私
在使用burp插件自动发现请求走私漏洞之前，让我们看看该如何手动检测它。这样您可以对这个漏洞了解地更深入。
您只需要同时发送经过修改的带有"Content-Length"和"Transfer-Encoding"头部HTTP请求。如果时间延迟了，服务器比正常情况花更多时间来处理这个污染的请求，那么意味着您发现了一个HTTP请求走私漏洞。
示例请求:
如果前端服务器只接受"Transfer-Encoding"头部，那么它会省略’0’之后的所有内容，将上面没有"Y "的内容发送给后端服务器。
如果后端服务器只使用Content-Length头部，那么他会认为请求的长度只有4。但由于前端服务器遗漏了一些数据，实际请求的长度小于4。因此后端服务器会等待一段时间来接收剩余的数据。这会造成时间延迟，从而检测到请求走私漏洞。
您可以编辑相同的请求在使用"Content-Length"的前端服务器和使用"Transger-Encoding"标头的后端服务器来查找漏洞。
利用Burp Suite扩展查找HTTP请求走私漏洞
HTTP Request Smuggler
HTTP Request Smuggler 是一个 burp 扩展，可帮助您自动完成上述手动任务来寻找此漏洞。手动查找漏洞是可以做到的，但非常繁琐，因此您可以利用burp中的现有扩展来实现这个过程。
安装扩展程序后，您可以立即开始使用它。右键单击Burp Proxy截获的请求，然后点击HTTP Request Smuggler->Smuggle Probe。然后它会自动修改拦截的请求并发送它以查找漏洞。它会发送许多修改的请求来检查此漏洞的两种类型-CL.TE & TE.CL。如果有任何与此相关的发现，您将可以在scan issues activity页面中找到它们。
默认Burp Suite主动扫描
实际上，如果您使用Burp Suite主动地去扫描一个目标，也可以检测HTTP 请求走私漏洞。您可以在Burp Suite的Active Scan配置中看到这一点。完成主动扫描后，Burp Suite还会在问题活动页面上报告发现的结果。如果您遇到此问题，请不要忽略它。处理它并通过HTTP Request Smuggeler扩展来确认此漏洞。
总结
HTTP请求走私是一个经常被忽视的严重漏洞。我实际上在一个真实系统，通过使用主动扫描和Request Smuggler扩展发现过此漏洞。希望这篇文章能让您了解到这个漏洞以及该如何检测它。如果您想要了解更多关于此漏洞的信息，您可以查看Port Swigger ，其中有关于它的详细说明。
