☰

HTTP 请求头中的（假）主机接收请求是否正常？

tag-icon • tag-icon routing http
HTTP 请求头中的（假）主机接收请求是否正常？

渗透测试表明我们的 Web 应用容易受到服务器端请求伪造的攻击。所谓证据是，当使用伪造的 Host 标头（例如：）fakehost.com向我们的 Web 应用发出请求时，我们会在日志中看到传入的 HTTP 请求fakehost.com。（fakehost.com可能由攻击者控制）此行为发生一次，但无法针对给定主机重现。

curl -i -s -k -X $'GET' \
    -H $'Host: fakehost.com' -H $'Accept-Encoding: gzip, deflate' -H $'Accept: */*' -H $'Accept-Language: en' -H $'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36' -H $'Connection: close' \
    $'https://subdomain.django_web_app.com/example'

将上述请求发送到我们的 Web 应用程序一次，就会生成六个传入请求fakehost.com，其中两个没有路径，四个有来自请求的路径。这些请求来自三个不同的 IP 地址，两个来自托管 Web 应用程序的国家/地区，一个来自我所在的国家/地区 - 无法识别这些 IP 地址中的任何一个，它们不是我自己的 IP 地址或我们的服务器，也不在 Amazon AWS IP 范围内。（Web 应用程序位于 Amazon AWS 负载均衡器后面。）

这些请求是网络在途中发出的吗？这是正常现象吗？

答案1

是的，事实上，将此类请求转发到你的应用程序的情况非常普遍，Django 文档用了一段话只是讨论如何解决常见的看似安全的配置，明确警告

在许多常见的 Web 服务器中，配置似乎会验证 Host 标头，但实际上可能并未这样做

最简单最明显的情况是，当您的应用程序后端无需通过代理即可访问时，攻击者完全绕过您的负载均衡器。

无论如何，由于在代理上正确操作非常困难，因此指出访问日志不仅记录这些请求，而且还记录它们已被400HTTP 状态代码正确拒绝可能是完全可以接受的。

请记住，您的应用程序不会仅仅因为收到这些请求就容易受到此类欺骗攻击。以任何可能泄露或更改状态的方式对这些请求采取行动会使其容易受到攻击。您的应用程序应该正确配置以验证标头，并HTTP 400在收到来自意外主机的请求时做出相应的响应。

相关内容