HTTP Host header attacks
在本节中，我们将讨论错误的配置和有缺陷的业务逻辑如何通过 HTTP Host 头使网站遭受各种攻击。我们将概述识别易受 HTTP Host 头攻击的网站的高级方法，并演示如何利用此方法。最后，我们将提供一些有关如何保护自己网站的一般建议。
什么是 HTTP Host 头
从 HTTP/1.1 开始，HTTP Host 头是一个必需的请求头，其指定了客户端想要访问的域名。例如，当用户访问 https://portswigger.net/web-security 时，浏览器将会发出一个包含 Host 头的请求：
GET /web-security HTTP/1.1 Host: portswigger.net
在某些情况下，例如当请求被中介系统转发时，Host 值可能在到达预期的后端组件之前被更改。我们将在下面更详细地讨论这种场景。
HTTP Host 头的作用是什么
HTTP Host 头的作用就是标识客户端想要与哪个后端组件通信。如果请求没有 Host 头或者 Host 格式不正确，则把请求路由到预期的应用程序时会出现问题。
历史上因为每个 IP 地址只会托管单个域名的内容，所以并不存在模糊性。但是如今，由于基于云的解决方案和相关架构的不断增长，使得多个网站和应用程序在同一个 IP 地址访问变得很常见，这种方式也越来越受欢迎，部分原因是 IPv4 地址耗尽。
当多个应用程序通过同一个 IP 地址访问时，通常是以下情况之一。
虚拟主机
一种可能的情况是，一台 web 服务器部署多个网站或应用程序，这可能是同一个所有者拥有多个网站，也有可能是不同网站的所有者部署在同一个共享平台上。这在以前不太常见，但在一些基于云的 SaaS 解决方案中仍然会出现。
在这种情况下，尽管每个不同的网站都有不同的域名，但是他们都与服务器共享同一个 IP 地址。这种单台服务器托管多个网站的方式称为“虚拟主机”。
对于访问网站的普通用户来说，通常无法区分网站使用的是虚拟主机还是自己的专用服务器。
通过中介路由流量
另一种常见的情况是，网站托管在不同的后端服务器上，但是客户端和服务器之间的所有流量都会通过中间系统路由。中间系统可能是一个简单的负载均衡器或某种反向代理服务器。当客户端通过 CDN 访问网站时，这种情况尤其普遍。
在这种情况下，即使不同的网站托管在不同的后端服务器上，但是他们的所有域名都需要解析为中间系统这个 IP 地址。这也带来了一些与虚拟主机相同的挑战，即反向代理或负载均衡服务器需要知道怎么把每个请求路由到哪个合适的后端。
HTTP Host 头如何解决这个问题
解决上述的情况，都需要依赖于 Host 头来指定请求预期的接收方。一个常见的比喻是给住在公寓楼里的某个人写信的过程。整栋楼都是同一个街道地址，但是这个街道地址后面有许多个不同的公寓房间，每个公寓房间都需要以某种方式接受正确的邮件。解决这个问题的一个方法就是简单地在地址中添加公寓房间号码或收件人的姓名。对于 HTTP 消息而言，Host 头的作用与之类似。
当浏览器发送请求时，目标 URL 将解析为特定服务器的 IP 地址，当服务器收到请求时，它使用 Host 头来确定预期的后端并相应地转发该请求。
什么是 HTTP Host 头攻击
HTTP Host 头攻击会利用以不安全的方式处理 Host 头的漏洞网站。如果服务器隐式信任 Host 标头，且未能正确验证或转义它，则攻击者可能会使用此输入来注入有害的有效负载，以操纵服务器端的行为。将有害负载直接注入到 Host 头的攻击通常称为 "Host header injection"（主机头注入攻击）。
现成的 web 应用通常不知道它们部署在哪个域上，除非在安装过程中手动配置指定了它。此时当他们需要知道当前域时，例如要生成电子邮件中包含的 URL ，他们可能会从 Host 头检索域名：
<a href="https://_SERVER['HOST']/support">Contact support</a>
标头的值也可以用于基础设施内不同系统之间的各种交互。
由于 Host 头实际上用户可以控制的，因此可能会导致很多问题。如果输入没有正确的转义或验证，则 Host 头可能会成为利用其他漏洞的潜在载体，最值得注意的是：
- Web 缓存中毒
- 特定功能中的业务逻辑缺陷
- 基于路由的 SSRF
- 典型的服务器漏洞，如 SQL 注入
HTTP Host 漏洞是如何产生的
HTTP Host 漏洞的产生通常是基于存在缺陷的假设，即误认为 Host 头是用户不可控制的。这导致 Host 头被隐式信任了，其值未进行正确的验证或转义，而攻击者可以使用工具轻松地修改 Host 。
即使 Host 头本身得到了安全的处理，也可以通过注入其他标头来覆盖 Host ，这取决于处理传入请求的服务器的配置。有时网站所有者不知道默认情况下这些可以覆盖 Host 的标头是受支持的，因此，可能不会进行严格的审查。
实际上，许多漏洞并不是由于编码不安全，而是由于相关基础架构中的一个或多个组件的配置不安全。之所以会出现这些配置问题，是因为网站将第三方技术集成到其体系架构中，而未完全了解配置选项及其安全含义。
利用 HTTP Host 头漏洞
详细内容请查阅本章下文。
如何防御 HTTP Host 头攻击
防御 HTTP Host 头攻击最简单的方法就是避免在服务端代码中使用 Host 头。仔细检查下每个 URL 地址是否真的绝对需要，你经常会发现你可以用一个相对的 URL 地址替代。这个简单的改变可以帮助你防御 web 缓存中毒。
其他防御措施有：
保护绝对的 URL 地址
如果你必须使用绝对的 URL 地址，则应该在配置文件中手动指定当前域名并引用此值，而不是 Host 头的值。这种方法将消除密码重置中毒的威胁。
验证 Host 头
如果必须使用 Host 头，请确保正确验证它。这包括对照允许域的白名单进行检查，拒绝或重定向无法识别的 Host 的任何请求。你应该查阅所使用的框架的相关文档。例如 Django 框架在配置文件中提供了 ALLOWED_HOSTS 选项，这将减少你遭受主机标头注入攻击的风险。
不支持能够重写 Host 的头
检查你是否不支持可能用于构造攻击的其他标头，尤其是 X-Forwarded-Host ，牢记默认情况下这些头可能是被允许的。
使用内部虚拟主机时要小心
使用虚拟主机时，应避免将内部网站和应用程序托管到面向公开内容的服务器上。否则，攻击者可能会通过 Host 头来访问内部域。
如何识别和利用 HTTP Host 头漏洞
在本节中，我们将更仔细地了解如何识别网站是否存在 HTTP Host 头漏洞。然后，我们将提供一些示例，说明如何利用此漏洞。
如何使用 HTTP Host 头测试漏洞
要测试网站是否易受 HTTP Host 攻击，你需要一个拦截代理（如 Burp proxy ）和手动测试工具（如 Burp Repeater 和 Burp intruiter ）。
简而言之，你需要能够修改 Host 标头，并且你的请求能够到达目标应用程序。如果是这样，则可以使用此标头来探测应用程序，并观察其对响应的影响。
提供一个任意的 Host 头
在探测 Host 头注入漏洞时，第一步测试是给 Host 头设置任意的、无法识别的域名，然后看看会发生什么。
一些拦截代理直接从 Host 头连接目标 IP 地址，这使得这种测试几乎不可能；对报头所做的任何更改都会导致请求发送到完全不同的 IP 地址。然而，Burp Suite 精确地保持了主机头和目标 IP 地址之间的分离，这种分离允许你提供所需的任意或格式错误的主机头，同时仍然确保将请求发送到预期目标。
有时，即使你提供了一个意外的 Host 头，你仍然可以访问目标网站。这可能有很多原因。例如，服务器有时设置了默认或回退选项，以处理无法识别的域名请求。如果你的目标网站碰巧是默认的，那你就走运了。在这种情况下，你可以开始研究应用程序对 Host 头做了什么，以及这种行为是否可利用。
另一方面，由于 Host 头是网站工作的基本部分，篡改它通常意味着你将无法访问目标应用程序。接收到你的请求的反向代理或负载平衡器可能根本不知道将其转发到何处，从而响应 "Invalid Host header" 这种错误。如果你的目标很可能是通过 CDN 访问的。在这种情况下，你应该继续尝试下面概述的一些技术。
检查是否存在验证缺陷
你可能会发现你的请求由于某种安全措施而被阻止，而不是收到一个 "Invalid Host header" 响应。例如，一些网站将验证 Host 头是否与 TLS 握手的 SNI 匹配。这并不意味着它们对 Host 头攻击免疫。
你应该试着理解网站是如何解析 Host 头的。这有时会暴露出一些可以用来绕过验证的漏洞。例如，一些解析算法可能会忽略主机头中的端口，这意味着只有域名被验证。只要你提供一个非数字端口，保持域名不变，就可以确保你的请求到达目标应用程序，同时可以通过端口注入有害负载。
GET /example HTTP/1.1 Host: vulnerable-website.com:bad-stuff-here
某些网站的验证逻辑可能是允许任意子域。在这种情况下，你可以通过注册任意子域名来完全绕过验证，该域名以白名单中域名的相同字符串结尾：
GET /example HTTP/1.1 Host: notvulnerable-website.com
或者，你可以利用已经泄露的不安全的子域：
GET /example HTTP/1.1 Host: hacked-subdomain.vulnerable-website.com
有关常见域名验证缺陷的进一步示例，请查看我们有关规避常见的 SSRF 防御和 Origin 标头解析错误的内容。
