因此，我的任务是研究 Acunetix 网络安全扫描发现的一个问题。
由于我的声誉不够，我还不能发布超过两个链接，但上述第一个链接上的 Skeletonscribe 参考资料更详细地介绍了该漏洞，似乎是该主题的主要来源。
建议的解决方法建议使用“虚拟”默认虚拟主机和应用程序，SERVER_NAME而不是使用主机头。当谈论真正的原始服务器时，这些建议很棒，但当您使用反向代理时，这些建议就不太好了。
Acunetix 正在扫描的我们的网站被设置为位于反向代理后面的应用程序服务器。在我们的例子中，反向代理是 iPlanet，但我已确认 Apache 2.4.7 中存在相同的行为mod_proxy。以下是它的工作原理以及它触发 Acunetix 扫描的原因。
当使用绝对 URI 发出请求时（如扫描仪所做的那样），根据 RFC 规范，服务器应忽略 Host 标头，而改用绝对 URI 内的主机。这是我们看到的行为，因此，即使 Host 标头的值不正确/恶意，也会选择正确的虚拟主机。到目前为止一切顺利。
当反向代理将此请求传递到后端源服务器时，就会出现问题。当它这样做时，它会将原始 Host 标头与请求一起传递。如果 Host 标头的值不正确或恶意，则会将其传递回源服务器。如果源服务器未实现虚拟主机，则无需验证 Host 标头是否正确。
结果是，任何在源 Web/应用服务器上运行的应用程序如果试图使用主机头将使用恶意主机值。SERVER_NAME在这种情况下使用是没有用的，因为站点的服务器名称（或真实主机）不会被反向代理转发，并且原始服务器仍然会使用 Host 标头值进行响应。在这里使用eUseCanonicalName指令ServerNam也是没有用的，因为您需要原始请求中的服务器名称，而该名称可能不止一个值。
这种“攻击”是在 2013 年发现的，但我找不到大量关于它的信息，除了重复上述参考资料中的细节。这不是一个常见的问题，因为 HTTP 客户端不会发送绝对 URI，除非它们正在与正向代理服务器通信。这意味着所有常规的请求将是相对 URI，然后这个问题就会消失（恶意主机标头会卡在反向代理上的“虚拟”或默认虚拟主机上）。
我确实创建了一个解决方法，即在将请求发送到后端之前，反向代理主动将 Host 标头设置为SERVER_NAME。这有效，但我担心这可能是一种违背最佳实践/标准的解决方案。像这样设置 Host 标头会破坏某些东西吗？我们对此进行了集思广益，但我想不出会破坏的场景。我明天会打电话给 Oracle 征求他们的反馈。
在我看来，这可能是一个边缘案例，只是我尝试的两种 Web 服务器产品的一个疏忽，但我无法想象有些事情会这么长时间没有得到解决。我一定是忽略了什么。
抱歉，文章太长了，但是，有什么想法吗？:) 这篇文章的“问题”部分将是这样的：
- 我的上述解决方法是一个好的解决方案还是会破坏一切？
- 这个问题有已知的解决办法吗？
答案1
您的反向代理应该默认为您更正 Host: 标头。如果它没有这样做，则是一个错误，应报告给其开发人员。
当代理收到具有绝对格式请求目标的请求时，代理必须忽略收到的 Host 标头字段（如果有），而是将其替换为请求目标的主机信息。转发此类请求的代理必须根据收到的请求目标生成新的 Host 字段值，而不是转发收到的 Host 字段值。
请注意，此 RFC 的先前版本 RFC 2616 不太具体。它只是说：
HTTP/1.1 代理必须确保它转发的任何请求消息都包含适当的 Host 标头字段，以标识代理所请求的服务。
您的代理的行为不能说符合旧规范或新规范。
同时，您的解决方法很好，因为它引入了正确的行为。
答案2
我有同样的问题需要修复，Acunetix 报告了这个漏洞 - 我没有反向代理，但我找到了同样的解决方案，我在 vHost 中明确设置了 Host 标头，因此它始终是我想要的。但是再次运行扫描显示问题仍然存在。
我使用 Postman 和 cURL 来验证我的解决方案，并注意到恶意 Host 或 X-Forwarded-Host 标头不再回显，但 Acunetix 仍然显示该漏洞，因为...
我实施了两个解决方案：
1）创建一个 catchall vHost...2）在我的服务器 vHost 中明确设置 Host 标头
要点 1 是为了防止仅仅更改 Host 标头，以防止 Apache 将请求传递给基于第一个名称的 vHost，要点 2 对 X-Forwarded-Host 修改进行排序。
那里还有什么？
Apache 2.4 Ubuntu 14.04.5