HTTP请求走私域/子域是宽的还是目录宽的？

Question

我对HTTP请求走私漏洞有很好的理解，但是我仍然需要澄清的一点是，它们是域/子域宽还是目录范围宽？

我的意思是:如果HTTP请求走私漏洞是由于前端服务器和任何后端服务器之间的配置差异而产生的，那么这是否意味着您应该只在整个域/子域中的单个POST参数上测试该漏洞？

假设您有example.com，它们有两个子域(a.example.com & b.example.com)。我们还假设example.com及其两个子域有两个目录(每个目录)，您可以向其发出POST请求。

所有这些都表明，在测试HTTP请求走私时，在每个POSTable请求和每个目录上测试请求走私是否合理。还是只值得在每个子域上检查一个POSTable目录。

我目前的假设是，如果请求走私本质上是服务器范围的，那么您就不需要测试每个单独的POST请求，因为它们都会通过相同的后端进程。不过，我想好好测试一下，好让任何人的想法都能被欣赏。

Answer 1

攻击不是针对位置(即目录，url的位置部分)，也不是在域(即对Host:头的攻击，也不是对包含在第一行位置部分中添加的主机的绝对url)的攻击--确实存在实际主机头攻击)。

请求走私是对协议级别的攻击，因此在任何位置或主机概念之前都是如此。受攻击的部分是服务器的HTTP解析器。如果您的服务器存在协议级解析缺陷，则服务器管理的所有虚拟主机和目录都可能出现问题。

要检查服务器，实际上有两种情况：

• 1/服务器是最终的后端
• 2/服务器处于中间(负载均衡器、TLS终端、代理等)

对于第一种情况，如果您有解析器缺陷，攻击者通常会使用它来使服务器响应“经典请求”，而不是禁止的。作为真正的目标是第二种情况的服务器，代理。

对于用作中介的服务器(案例2)，如果存在缺陷，所有可能的主机都可能成为目标。

让我们看看走私攻击的一个例子，保护旁路。在代理中，除了一些IP之外，您还可以阻止对'/admin/‘的任何调用。

攻击者发送1个有效请求，第二个/admin请求隐藏在正文中。代理只发送和看到一个带有主体的请求。在后端，因为您以另一种方式解释请求，所以可以看到两个请求，一个是有效的查询，另一个是/admin的请求，并且假设它是一个有效的查询，因为阻止对/admin的无效访问是代理的工作。你发送了两个答复。就是这样。实际上，要获得'/admin‘响应，需要向代理发送2个有效的请求，其中一个隐藏在中间，作为第一个请求体。您将从后端获得3个响应，代理将返回2个第一响应，第二个响应是/admin的响应。

另一个例子是缓存中毒，如果代理缓存响应，则隐藏请求的响应将替换真实的第二个请求的响应。

另一个例子是响应故障，一旦在代理中引入了请求和响应的混合，每个人都会从其他人的请求中获得响应，最糟糕的情况是，直到重新启动代理。

所以..。这不是测试你在一个网址中有问题，如果你在服务器上有问题.你有问题了。

有一个特例，它只与一个域相关。当您的应用程序在特定的域上有一个引入HTTP注入的应用程序缺陷时。就像注射CRLF一样。假设您想要生成带有Location:头的重定向，用户可以控制在该标头中使用的参数，并且不过滤该内容中的\r\n (CR和LF)。然后，在应用程序使用的特定域上，应用程序可能会引入HTTP响应注入。所以这个特例是由应用程序代码引入的HTTP注入。

但是其他的攻击是独立于应用程序的，只能通过使用固定的服务器，或者使用一些带有健壮HTTP解析器的代理来解决，而HTTP解析器会在到达后端之前阻止奇怪的查询(例如，haproxy通常非常好)。