CL.0请求走私
Last updated
Last updated
请求走私漏洞是由于链式系统确定每个请求的开始和结束位置的方式存在差异而产生的。通常是由于标头解析的不一致，导致一个服务器使用请求的Content-Length，而另一个服务器将消息视为分块。然而，我们可以在不依赖这些问题的情况下进行许多相同的攻击。
在某些情况下，服务器可以被说服忽略Content-Length标头，这意味着它们假设每个请求都在标头结束时结束。实际上这与将Content-Length视为0的效果是一样的。
如果后端服务器表现出这种行为，但前端仍然使用Content-Length标头来确定请求的结束位置，那么你就可能可以利用这种差异进行HTTP请求走私。我们决定将其称之为“CL.0”漏洞。
PortSwigger Research
本节中的材料和实验基于PortSwigger Research的《》。
要探测CL.0漏洞，首先发送一个在其正文中包含另一个部分请求的请求，然后再发送一个正常的后续请求。之后你可以检查后续请求的响应是否受到了走私前缀的影响。
在下面的例子中，对主页的后续请求收到了404响应。这强烈表明后端服务器将POST请求的正文（GET /hopefully404...）解释为另一个请求的开始。
POST /vulnerable-endpoint HTTP/1.1
Host: vulnerable-website.com
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 34
GET /hopefully404 HTTP/1.1
Foo: xGET / HTTP/1.1
Host: vulnerable-website.com
HTTP/1.1 200 OK
HTTP/1.1 404 Not Found
关键的是，请注意我们没有以任何方式篡改标头，请求的长度由完全正常、准确的Content-Length标头指定。
要使用Burp Repeater自己尝试这个：
创建一个包含设置请求的选项卡和一个包含任意后续请求的选项卡。
按正确的顺序将这两个选项卡添加到一个组中。
使用Send按钮旁边的下拉菜单，将发送模式更改为Send group in sequence (single connection)。
将Connection标头更改为keep-alive。
发送序列并检查响应。
在实际环境中，我们观察到的这种行为大多发生在不期望POST请求的端点上，因此它们隐式地假设没有请求有正文。触发服务器级别重定向的端点和请求静态文件的端点是首要的候选者。
如果找不到任何看起来易受攻击的端点，你可以尝试引发这种行为。
当一个请求的标头触发一个服务器错误时，一些服务器会发出错误响应，但不会消耗套接字上的请求体。如果它们在此之后没有关闭连接，这可以提供一个替代的CL.0异步载体。
你可以利用CL.0漏洞进行我们在之前的请求走私材料中介绍的服务器端请求走私攻击。可以使用以下实验自己尝试。
LAB
如果后端服务器忽略降级请求的Content-Length标头，则将HTTP/2请求降级为HTTP/1的网站可能容易受到类似“H2.0”问题的攻击。
接下来做什么？
你可以在这一部分学到的基础上，进行一些请求走私攻击的客户端版本。要了解如何做到这一点，请查看客户端异步攻击实验。
你还可以尝试使用带有混淆的Content-Length标头的GET请求。如果你能够隐藏这个标头使得后端服务器看不到，但前端服务器能够看到，这也有可能导致异步。在之前介绍TE.TE请求走私时，我们研究了一些。
关于你可以采取的一些高级措施，以防止CL.0漏洞和其他形式的异步攻击，请参阅。