所以我负责研究Acunetixnetworking安全扫描发现的问题。
以下是有关扫描的详细信息：
Host_header_attack
主机头部攻击的自动检测
由于我没有足够的声望，所以我不能发布两个以上的链接，但是上面的第一个链接上的结构参考文献更详细地介绍了这个漏洞，似乎是这个主题的主要来源。
build议的解决方法build议使用“虚拟”默认虚拟主机和应用程序使用SERVER_NAME而不是使用主机头 。 当谈到一个真正的原始服务器时，这些build议是非常棒的，但是当你使用一个反向代理时，这些build议并不多。
我们的Acunetix正在扫描的网站被设置为一个位于逆向代理之后的应用服务器。 在我们的例子中，反向代理是iPlanet，但是我已经使用mod_proxy在Apache 2.4.7中确认了相同的行为。 这是它是如何工作的，为什么它会触发Acunetix扫描。
当使用绝对URI进行请求时（正如扫描程序所做的那样），根据RFC规范，服务器将忽略主机头，而是使用绝对URI内的主机。 这是我们看到的行为，因此，即使Host标头具有不正确的/恶意值，也会select正确的虚拟主机。 到现在为止还挺好。
当反向代理将此请求传递到后端原始服务器时，会出现问题。 当它这样做的时候，它会把原来的Host头和请求一起传递。 如果主机头有一个不正确的或恶意的值，这将被传回原始服务器。 如果源服务器不实现虚拟主机，则不需要validation主机头是否正确。
这样做的结果是任何运行在试图使用Host头的值的原始web / app服务器上的应用程序都将使用恶意主机值。 在这种情况下使用SERVER_NAME是没有用的，因为站点的服务器名称（或者真正的主机）没有被反向代理转发，并且源服务器仍然响应主机头值。 在这里使用UseCanonicalName和ServerNam e指令也是没有用的，因为您需要原始请求中的服务器名称（可能是多个值）。
这个“攻击”是在2013年发现的，但是我找不到很多关于它的信息，不仅仅是重复上面引用的细节。 这不是一个常见的问题，因为HTTP客户端不会发送绝对URI，除非他们正在与转发代理服务器交谈。 这意味着所有常规的请求都是相对的URI，这个问题就会消失（恶意主机头然后卡在反向代理上的“dummy”或默认虚拟主机上）。
我确实创build了一个解决方法，在请求发送到后端之前，反向代理主动将主机头设置为SERVER_NAME 。 这是有效的，但是我担心它是否可能是一种违背押注做法/标准的解决scheme。 将这样的主机头设置为什么会破坏？ 我们对此进行了头脑风暴，但我无法想象它会如何。 我明天将打电话给甲骨文，以获得他们的反馈。
在我看来，这可能是一个这样的边缘案例，这只是我尝试的两个Web服务器产品的一个疏忽，但我无法想象有什么事情会持续很长时间而没有得到解决。 我肯定错过了什么。
对不起，这是很长的时间，但是，有什么想法？ :)这篇文章的“问题”部分是这样的：
您的反向代理默认应该为您更正主机：标题。 它不这样做是一个错误，应该报告给开发人员。
从RFC 7230第5.4节 ：
当一个代理接收到一个具有绝对forms的请求目标的请求时，代理必须忽略接收到的主机头字段（如果有的话），而代之以请求目标的主机信息。 转发这种请求的代理必须基于接收到的请求目标生成新的主机字段值，而不是转发接收到的主机字段值。
请注意，此RFC RFC 2616的以前版本不太具体。 它只是说 ：
HTTP / 1.1代理必须确保它转发的任何请求消息都包含一个合适的主机头字段，用于标识代理请求的服务。
你的代理行为不能说是符合旧的或新的规范。
同时，你的解决方法是好的，因为它引入了正确的行为。
我有同样的问题要解决，Acunetix报告这个漏洞 – 我没有一个反向代理，但我想出了相同的解决scheme，我明确地设置主机头在vHost，所以它总是我想要的。 但是再次运行扫描显示问题仍然存在。
我用邮递员和cURL来validation我的解决scheme，并指出恶意主机或X-Forwarded-Host头不再得到回应，但Acunetix仍然显示在那里的漏洞…
我实施了2个解决scheme
1）创build一个catchall vHost … 2）在我的服务器vHost中显式设置主机头
第1点是防止仅仅改变主机头，以防止Apache将请求传递给基于名字的vHost，第2点将X-Forwarded-Host修改分类。
那里还有什么？
Apache 2.4 Ubuntu 14.04.5