在本节中，我们将更详细地研究如何确定一个网站是否容易受到HTTP Host头攻击。
1. 如何使用HTTP Host头测试漏洞
测试一个网站是否存在HTTP Host头漏洞，需要用到burp suite代理工具的Repeater和Intruder模块。
简而言之，您需要确定修改Host头后是否仍然能够将请求发送到目标应用。如果是，您可以使用Host头探测应用程序，并观察它对返回包的影响。
1.1 提供一个任意的Host头
当测试Host头注入漏洞时，第一步先修改Host值为任意的、无法识别的域名，观察服务端返回什么。
推荐使用burpsuite工具，因为其他代理工具可能认为host值就是目标服务器地址，当修改host为其他地址时，代理工具也把请求转发到修改后的host地址，而不是原始地址。在burpsuite中，目标URL显示在面板的顶部(Repeater和Proxy interception)或Intruder的“Target”标签。您可以通过单击铅笔图标手动编辑。
有时，即使提供了非原始的Host头，您仍然能够访问目标网站。这可能有很多原因。例如，服务器有时配置了默认或备选方案，以防它们收到无法识别的域名请求。如果你的被测目标恰好是默认的，那么你很幸运。在这种情况下，您可以开始研究应用程序对Host头做了什么，以及这种行为是否可被利用。
另一方面，由于Host头是网站工作的基本组成部分，篡改它通常意味着你根本无法到达目标应用程序。接收请求的前端服务器或负载均衡器可能不知道将其转发到哪里，从而返回类似“Invalid Host header”错误。如果您的目标通过CDN访问，这尤其可能。在这种情况下，您应该继续尝试下面列出的一些技术。
1.2 有缺陷的校验
您可能会发现，由于某种安全措施，您的请求被阻断，而不是接收到“Invalid Host header”响应。例如，一些网站将验证Host头是否与TLS握手中的SNI匹配。但这并不意味着它们不会受到Host头攻击。
你应该试着理解被测目标是如何解析Host头的。这有时会暴露出可以用来绕过验证的漏洞。例如，一些解析算法将省略Host头中的端口，这意味着只验证域名。如果还能够提供非数字端口，则可以保持域名不变，以确保能发送到目标应用程序，同时通过端口注入payload。
GET /example HTTP/1.1
Host: vulnerable-website.com:bad-stuff-here
有些网站通过域名匹配方式进行校验。在这种情况下，可以在原host前面加其他字符串来构造新域名绕过验证:
GET /example HTTP/1.1
Host: notvulnerable-website.com
或者，你可以利用一个你已经窃取到的不太安全的子域名:
GET /example HTTP/1.1
Host: hacked-subdomain.vulnerable-website.com
1.3 发送模糊请求
校验host的代码和易受攻击的代码通常位于不同的应用程序组件中，甚至位于不同的服务器上。通过确认和利用它们在检索Host头的方式上的差异，您可以发出一个包含多个不同host的模糊请求，观察服务端会用那个。
下面是如何构造模糊请求的几个示例。
1.3.1 注入重复的Host头
一种可能的方法是尝试添加重复的Host头。无可否认，这通常只会导致请求被阻断。但是，由于浏览器不太可能发送这样的请求，您可能偶尔会发现开发人员没有预料到这种情况。在这种情况下，可能会暴露一些有趣的信息。
不同的系统和技术将以不同的方式处理这种情况，但两个头中的一个被给予优先于另一个的情况是常见的，这实际上覆盖了它的值。当系统之间对使用哪个Host头产生分歧时，可利用这种分歧发起攻击。考虑以下请求:
GET /example HTTP/1.1
Host: vulnerable-website.com
Host: bad-stuff-here
例如前端优先使用第一个Host头，后端使用第二个头。在这种情况下，您可以使用第一个头来确保您的请求被路由到预期的目标，并使用第二个头将您的payload传递到服务端的代码中。
1.3.2 提供绝对URL
虽然HTTP请求行（即HTTP请求第一行，GET和HTTP/1.1中间部分）一般指定为相对路径，但许多服务器也支持绝对url的请求。
同时提供绝对URL和Host头导致的歧义也会导致不同系统之间的差异。正常情况下，请求行优先级要高，但在实践中，情况并非总是如此。您可以像利用重复的Host头一样利用这些差异。
GET https://vulnerable-website.com/ HTTP/1.1
Host: bad-stuff-here
注意，您可能还需要尝试不同的协议。服务器有时会根据请求行是否包含HTTP或HTTPS URL而表现不同。
1.3.3 添加换行
您还可以通过使用空格字符缩进HTTP头来发现奇怪的行为。有些服务器会将缩进的头解释为换行，因此，将其视为前一个头值的一部分。有些服务器则完全忽略缩进头。
由于这种情况的处理高度不一致，处理请求的不同系统之间经常会有差异。例如，考虑以下请求:
GET /example HTTP/1.1
Host: bad-stuff-here
Host: vulnerable-website.com
网站可能会阻止带有多个Host头的请求，但是你可以通过像这样缩进其中一个来绕过这个验证。如果前端忽略缩进的报头，该请求将被认为是到vulnerable-website.com的普通请求。现在，让我们假设后端忽略第一个host的前边空格，并在host头重复的情况下优先使用第一个。这种差异可能允许您通过“包装的”Host头传递任意值。
1.3.4 其他技巧
这只是众多发出危害或者模糊请求方式中的一小部分。例如，您还可以采用许多HTTP请求走私攻击的技术来构造Host头攻击。我将在专门的请求走私文章中更详细地介绍这一点。
1.4 注入host覆写头
即使您不能使用模糊请求覆写Host头，也有其他方法覆写而不改变host头。这包括通过其他几个HTTP头中的一个注入您的payload，这些头就是为这个目的而设计的，尽管是为更无害的用例而设计的。
正如我们已经讨论过的，网站经常通过某种中间系统访问，例如负载均衡或反向代理。在这种体系结构中，后端服务器接收到的Host头可能包含这些中间系统的域名。这通常与所请求的功能无关。
为了解决这个问题，前端可能会注入X-Forwarded-Host头，其中包含客户端最初请求的Host头的原始值。由于这个原因，当X-Forwarded-Host头出现时，许多框架都会引用它。即使没有使用此头的前端，您也可以观察到此行为。
有时可以使用X-Forwarded-Host注入恶意输入，同时绕过Host头本身的任何验证。
GET /example HTTP/1.1
Host: vulnerable-website.com
X-Forwarded-Host: bad-stuff-here
虽然x-forward-host是这种行为的实际标准，但你可能会遇到其他具有类似目的的头，包括:
X-Host
X-Forwarded-Server
X-HTTP-Host-Override
Forwarded
在Burp套件中，您可以使用Param Miner扩展的“Guess headers”功能，使用其扩展内置单词列表自动探测支持的头。
从安全的角度来看，需要注意的是，有些网站(可能甚至是您自己的网站)无意中支持这种行为。这通常是因为它们使用的某些第三方技术默认启用了其中一个或多个头。
2. 如何利用HTTP Host头攻击
一旦确定可以将任意主机名传递给目标应用程序，就可以开始寻找利用它的方法。在本节中，我们将提供一些您可以构造的常见HTTP Host头攻击的示例。
2.1 密码重置投毒
攻击者有时可以使用Host头进行密码重置投毒攻击。后面单独发文介绍。
2.2 通过Host头的Web缓存投毒
在探测潜在的Host报头攻击时，您经常会遇到看似脆弱的、不能直接利用的行为。例如，您可能会发现Host头回显在没有html编码的标签中，甚至在脚本导入中直接使用。由Host头引起的反射型客户端漏洞(如XSS)通常是不可利用的。攻击者没有办法迫使受害者的浏览器发出错误的host。
然而，如果目标使用web缓存，可以尝试web缓存投毒攻击，使其他用户访问，就有可能把这个无用的、反射型漏洞变成一个危险的、存储型漏洞。
要构造web缓存投毒攻击，您需要从服务器引出一个响应，响应中包含注入的payload。要做到这一点的难点是，保持缓存键的同时，仍映射到其他用户的请求。如果成功，下一步就是缓存这个恶意响应。然后，它将提供给任何试图访问该页面的用户。
独立缓存通常在缓存键中包含Host头，因此这种方法通常在集成的，应用级缓存上工作得最好。也就是说，前面讨论的技术有时可以使您毒害甚至独立的web缓存。
2.3 利用经典的服务器端漏洞
每个HTTP头可成为经典服务器端漏洞的攻击向量，Host头也不例外。例如，您应该对Host头进行常见的SQL注入测试。如果将host头的值传递到SQL语句中，就可以利用它。
2.4 访问限制功能
很明显，网站通常只允许内部用户访问某些功能。然而，一些网站的访问控制功能有缺陷，允许您通过简单修改host头绕过这些限制。这可能会增加其他漏洞的攻击面。
2.5 使用虚拟主机强制访问内部网站
公司有时会错误地将公开访问的网站和私有的内部网站托管在同一台服务器上。服务器通常具有公共和私有IP地址。由于内部主机名可能会解析为私有IP地址，这种情况不能总是通过查看DNS记录来检测到:
www.example.com: 12.34.56.78
intranet.example.com: 10.0.0.132
在某些情况下，内部站点甚至可能没有与之关联的公共DNS记录。尽管如此，攻击者通常可以访问任何服务器上的任何虚拟主机，只要他们能猜出主机名。如果他们通过信息披露等其他方式发现了隐藏的域名，他们可以直接提出请求。否则，他们可以使用Burp Intruder等工具，暴力破解虚拟主机。
2.6 Routing-based SSRF
有时还可以使用Host头发起高影响的routing-based SSRF攻击。这些有时被称为“主机头SSRF攻击”。
经典的SSRF漏洞通常基于XXE或可利用的业务逻辑，该业务逻辑将HTTP请求发送到来自用户可控制输入的URL。另一方面，Routing-based SSRF依赖于利用在许多基于云的架构中普遍存在的中间组件。这包括内部负载均衡器和反向代理。
尽管这些组件用于不同的目的进行部署，但从根本上讲，它们接收请求并将请求转发到相应的后端。如果它们没有安全地配置，将未经验证的Host头转发，则可能会将请求误路由到攻击者所选择的任意系统。
这些系统是理想的目标。他们处于特权网络位置，可以直接接收来自公共网络的请求，同时也可以访问大部分(如果不是全部的话)内部网络。这使得Host头成为SSRF攻击的强大矢量，潜在地将一个简单的负载均衡器转换为整个内部网络的网关。
您可以使用Burp Collaborator来帮助识别这些漏洞。如果您在Host头中提供了Collaborator服务器的域，随后接收到了从目标服务器发起的DNS查询记录，这表明有可能将请求路由到任意域。
确认了可以成功操纵中间系统将请求路由到任意公共服务器之后，下一步是看看是否可以利用此行为访问只针对内部的系统。为此，您需要识别目标内部网络中使用的私有IP地址。除了应用程序泄漏的任何IP地址外，您还可以扫描属于该公司的主机名，以查看是否有私有IP地址的解析。如果所有这些都失败了，您仍然可以通过简单地暴力破解标准私有IP范围来识别有效的IP地址，如：192.168.0.0/16。
2.7 通过畸形的请求行执行SSRF
自定义代理有时无法正确地校验请求行，这可能使您提供异常的、畸形的输入，从而导致不正确的结果。
例如，反向代理可能从请求行获取路径，在其前面加上http://backend-server，然后将请求路由到该上游URL。如果路径以/字符开头，这很好，但如果以@字符开头呢?
GET @private-intranet/example HTTP/1.1
最终的URL将是http://backend-server@private-intranet/example，大多数HTTP库将其解释为使用用户名backend-server访问private-intranet的请求。
原文：https://portswigger.net/web-security/host-header/exploiting
