请选择 进入手机版 | 继续访问电脑版

PortSwigger Academy | HTTP Host header attacks : HTTP Host头攻击

[复制链接]
奇奇女 发表于 2020-12-31 20:26:37 | 显示全部楼层 |阅读模式 打印 上一主题 下一主题
本文所在: https://blog.csdn.net/qq_42942594/article/details/110090787

文章目录




总结:

0.大概导致的问题: Web缓存中毒; 特定功能中的业务逻辑缺陷; 基于路由的SSRF; 经典的服务器端弊端,比方SQL注入
1.邮件重置暗码中毒:直接更改Host、设置X-Forwarded-Host、共同XSS或danling makeup
2.web缓存中毒:用Host感染cache,导致其他用户拿到被污染的响应。
3.如果目的被扫描到Host头攻击,可以试试sql注入等。
4.利用Host: localhost,主机头身份验证绕过.
5.在某些情况下,内部站点甚至大概没有与之关联的公共DNS记录。但是,攻击者通常可以访问他们有权访问的任何服务器上的任何虚拟主机,前提是他们可以推测主机名。如果他们通过其他方式(比方信息公开)发现了隐藏的域名,则只需直接提出请求即可。否则,他们可以使用Burp Intruder之类的工具,通过简单的候选子域单词列表对虚拟主机进行暴力破解。(这个可以试试)
6.有大概将一个简单的负载均衡器转变为通往整个内部网络的网关。您可以使用Burp Collaborator帮助识别这些弊端
1.什么是HTTP Host头攻击?

: What is the HTTP Host header?
从HTTP / 1.1开始,HTTP Host标头是必须的请求标头。 它指定客户端要访问的域名。 比方,当用户访问https://portswigger.net/web-security时,他们的欣赏器将组成一个包罗Host标头的请求,如下所示:
  1. GET /web-security HTTP/1.1Host: portswigger.net
复制代码
在某些情况下,比方当请求已由中介系统转发时,主机值大概会在到达预期的后端组件之前进行更改。 我们将在下面更详细地讨论这种情况。
2.HTTP Host标头的目的是什么?

: What is the purpose of the HTTP Host header?
HTTP Host标头的目的是帮助识别客户端想要与之通信的后端组件。如果请求不包罗Host标头,大概Host标头以某种方式格式不正确,则在将传入请求路由到预期的应用程序时大概会导致问题。
从汗青上看,这种歧义并不存在,因为每个IP所在只会托管单个域的内容。如今,很大程度上是由于基于云的解决方案和将许多相关体系布局外包的不停增长的趋势,通常可以在同一IP所在访问多个网站和应用程序。这种方法的遍及也部门是由于IPv4所在耗尽所致。
当可以通过同一IP所在访问多个应用程序时,最常见的原因是以下情况之一。
虚拟主机

: Virtual hosting
一种大概的情况是,单个Web服务器托管多个网站或应用程序。这大概是具有单个所有者的多个网站,但是也大概将具有差别所有者的网站托管在单个共享平台上。这种情况比以前少见,但在某些基于云的SaaS解决方案中仍然会发生。
无论哪种情况,只管这些差别的网站中的每一个都将具有差别的域名,但是它们都与服务器共享一个公共IP所在。以这种方式在单个服务器上托管的网站称为“虚拟主机”。
对于访问该网站的普通用户来说,虚拟主机通常与托管在其专用服务器上的网站是无法区分的。
通过中介路由流量

: Routing traffic via an intermediary
另一个常见的情况是,网站托管在差别的后端服务器上,但是客户端和服务器之间的所有流量都通过中介系统进行路由。这大概是一个简单的负载均衡器或某种反向代理服务器。在客户通过内容分发网络(CDN)访问网站的情况下,这种设置尤其广泛。
在这种情况下,纵然网站托管在单独的后端服务器上,它们的所有域名也都剖析为中间组件的单个IP所在。这带来了与虚拟主机相同的挑战,因为反向代理或负载均衡器需要知道将每个请求路由到的适当后端。
HTTP Host标头如何解决此问题?

: How does the HTTP Host header solve this problem?
在这两种情况下,都依赖于Host标头来指定预期的收件人。一个常见的类比是向居住在公寓楼中的或人发送一封信的过程。整个修建物具有相同的街道所在,但是在该街道所在反面有许多差别的公寓,每套公寓都需要以某种方式吸收正确的邮件。解决此问题的一种方法就是简单地在所在中包罗公寓号码或收件人的名字。对于HTTP消息,Host标头起类似的作用。
当欣赏器发送请求时,目的URL将剖析为特定服务器的IP所在。当该服务器吸收到请求时,它参考主机头来确定预期的后端并相应地转发该请求。
3.什么是HTTP主机标头攻击?

: What is an HTTP Host header attack?
HTTP主机标头攻击利用易受攻击的网站,这些网站以不安全的方式处理惩罚主机标头的值。如果服务器隐式信任Host标头,但未能正确验证或转义它,则攻击者大概能够使用此输入来注入有害的有效负载,以利用服务器端的行为。涉及直接将有效负载注入主机标头的攻击通常称为“主机标头注入”攻击。
现成的Web应用程序通常不知道它们摆设在哪个域上,除非在安装过程中在设置文件中手动指定了该域。比方,当他们需要知道当前域以生成电子邮件中包罗的绝对URL时,他们可以求助于Host头中的域:
[url=https://_SERVER['HOST']/support]接洽支持[/url]
标头值还可以用于网站基础布局的差别系统之间的各种交互。
由于Host标头实际上是用户可控制的,因此这种做法大概导致许多问题。如果没有正确地对输入进行转义或验证,则Host标头是利用一系列其他弊端的潜在载体,最明显的是:


  • Web缓存中毒
  • 特定功能中的业务逻辑缺陷
  • 基于路由的SSRF
  • 经典的服务器端弊端,比方SQL注入
4.HTTP Host标头弊端如何产生?

: How do HTTP Host header vulnerabilities arise?
HTTP主机标头弊端通常是由于错误的假设而造成的,即该标头不可由用户控制。纵然攻击者可以使用Burp Proxy之类的工具轻松地修改主机标头,这也会在Host标头中创建隐式信任,并导致其验证或转义不敷。
纵然可以更安全地处理惩罚Host标头自己,详细取决于处理惩罚传入请求的服务器的设置,也可以通过注入其他标头来覆盖Host。有时,网站所有者不知道默认情况下支持这些标头,因此,它们大概不会受到相同级别的审查。
实际上,这些弊端中的许多弊端并不是由于编码不安全,而是由于相关基础架构中一个或多个组件的设置不安全。因为网站将第三方技能集成到其体系布局中,而不必相识设置选项及其安全隐患,所以大概会出现这些设置问题。
5.利用HTTP主机标头弊端 : ↓

: Exploiting HTTP Host header vulnerabilities
到现在为止,您应该已经对HTTP Host标头有了一个很好的相识。对于渗透测试者和Bug赏金猎人,我们创建了一些其他指南,指导您如何自行识别和利用这些弊端。我们还提供了一些故意易受攻击的LABS,以便您可以训练其中的一些技能。
见下一部门.
6.如何防止HTTP主机标头攻击

: How to prevent HTTP Host header attacks
为防止HTTP主机头攻击,最简单的方法是制止在服务器端代码中完全使用主机头。仔细查抄每个URL是否真的需要是绝对的。您通常会发现您可以只使用相对URL。这个简单的更改可以帮助您特别防止Web缓存中毒弊端。
防止HTTP主机标头攻击的其他方法包罗:
掩护绝对网址

: Protect absolute URLs
当必须使用绝对URL时,应要求在设置文件中手动指定当前域,并引用此值而不是Host标头。比方,这种方法将消除暗码重置中毒的威胁。
验证主机头

: Validate the Host header
如果必须使用Host标头,请确保正确验证它。这应该包罗对照允许的域白名单查抄它,以及拒绝或重定向对无法识别的主机的任何请求。您应查阅框架文档以获取有关执行此利用的指导。比方,Django框架在设置文件中提供了ALLOWED_HOSTS选项。这种方法将淘汰您遭受主机标头注入攻击的风险。
不要支持主机替代标题

: Don’t support Host override headers
同样重要的是要查抄您是否支持大概用于构造这些攻击的其他标头,尤其是X-Forwarded-Host。请记着,默认情况下大概支持这些功能。
将允许的域名列入白名单

: Whitelist permitted domains
为了防止对内部基础布局进行基于路由的攻击,应将负载均衡器或任何反向代理设置为仅将请求转发到允许域的白名单。
注意仅限内部使用的虚拟主机

: Be careful with internal-only virtual hosts
使用虚拟托管时,应制止将面向内部的网站和应用程序与面向公众的内容托管在同一服务器上。否则,攻击者大概可以通过主机标头利用来访问内部域。
  如何识别和利用HTTP Host标头弊端: How to identify and exploit HTTP Host header vulnerabilities:
1.如何使用HTTP Host标头测试弊端

: How to test for vulnerabilities using the HTTP Host header
要测试网站是否容易受到HTTP Host标头的攻击,您将需要拦截代理(比方Burp Proxy)和手动测试工具(比方Burp Repeater和Burp Intruder)。
简而言之,您需要确定您是否能够修改Host标头,而且仍然能够根据您的请求到达目的应用程序。如果是这样,则可以使用此标头来探测应用程序,并观察它对响应有什么影响。
提供一个任意的主机头

: Supply an arbitrary Host header
在探查主机头注入弊端时,第一步是测试当您通过主机头提供任意的、无法识别的域名时会发生什么。
一些拦截代理直接从Host标头获取目的IP所在,这使得这种测试险些不大概。您对标头所做的任何更改都只会导致将请求发送到完全差别的IP所在。但是,Burp Suite可以准确地维护主机标头和目的IP所在之间的分隔。这种分隔允许您提供所需的任何任意或格式错误的Host标头,同时仍然确保将请求发送到预期的目的。
  提示:
目的URL显示在面板顶部(用于Burp转发器和代理拦截)或Burp Intruder中的“ Target”选项卡上。您可以通过单击铅笔图标手动编辑目的。
有时,纵然您提供了意外的Host标头,您仍然仍然可以访问目的网站。这大概是出于多种原因。比方,有时服务器会设置为默认或后备选项,以防它们收到无法识别的域名请求。如果您的目的网站可巧是默认网站,那么您很幸运。在这种情况下,您可以开始研究应用程序使用Host标头执行的利用以及此行为是否可利用。
另一方面,由于Host标头是网站工作方式的根本组成部门,因此对其进行窜改通常意味着您将根本无法访问目的应用程序。收到您的请求的前端服务器或负载均衡器大概根本不知道将请求转发到那边,从而导致某种“无效的主机头”错误。如果通过CDN访问目的,则尤其大概发生这种情况。在这种情况下,您应该继续实验下面概述的一些技能。
查抄验证错误

: Check for flawed validation
您大概会发现由于某种安全步伐而阻止了您的请求,而不是收到“Invalid Host header”响应。比方,某些网站将验证Host标头是否与TLS握手中的SNI相匹配。这并不一定意味着它们不受Host标头攻击。
您应该实验相识网站如何剖析Host标头。有时,这大概会发现可用于绕过验证的弊端。比方,某些剖析算法将从Host标头中省略端口,这意味着仅域名被验证。如果您还能够提供非数字端口,则可以保持域名稳定,以确保您可以到达目的应用程序,同时还可以通过该端口注入有效负载。
  1. GET /example HTTP/1.1Host: vulnerable-website.com:bad-stuff-here
复制代码
其他站点将实验应用匹配逻辑以允许任意子域。在这种情况下,您可以通过注册一个以与白名单中的字符相同的字符序列末了的任意域名来完全绕过验证:
  1. GET /example HTTP/1.1Host: notvulnerable-website.com
复制代码
别的,您可以利用已担当到粉碎的安全性较低的子域:
  1. GET /example HTTP/1.1Host: hacked-subdomain.vulnerable-website.com
复制代码
有关常见域验证缺陷的更多示例,请检察我们的内容,以规避常见的SSRF防御和Origin标头剖析错误。
发送含糊的请求

: Send ambiguous requests
验证主机的代码和对其进行脆弱处理惩罚的代码通常位于差别的应用程序组件中,甚至位于单独的服务器上。通过识别和利用它们在检索主机标头方面的差异,您可以发出暗昧其词的请求,该请求似乎具有差别的主机,详细取决于正在检察的系统。
下面仅是一些示例,说明您如何能够创建不明确的请求。
注入重复的主机头

: Inject duplicate Host headers
一种大概的方法是实验添加重复的Host标头。诚然,这通常只会导致您的请求被阻止。但是,由于欣赏器不太大概发送此类请求,因此您有时大概会发现开辟人员没有预推测这种情况。在这种情况下,您大概会袒露一些有趣的行为怪癖。
差别的系统和技能将以差别的方式处理惩罚这种情况,但是通常会给两个标头之一优先于另一个标头,从而有效地覆盖其值。当系统差别意哪个标头是正确的标头时,这大概导致您大概会利用差异。思量以下请求:
  1. GET /example HTTP/1.1Host: vulnerable-website.comHost: bad-stuff-here
复制代码
假设前端将优先级设置为标头的第一个实例,但后端优先选择最终实例。在这种情况下,您可以使用第一个标头来确保将请求路由到预期的目的,并使用第二个标头将有效负载通报到服务器端代码中。
提供一个绝对URL

: Supply an absolute URL
只管请求行通常在请求的域上指定相对路径,但是许多服务器也设置为相识对绝对URL的请求。
同时提供绝对URL和Host标头导致的歧义也大概导致差别系统之间的差异。正式地,在路由请求时,应优先思量请求行,但实际上并非总是如此。您大概会以与重复的Host标头相同的方式利用这些差异。
  1. GET https://vulnerable-website.com/ HTTP/1.1Host: bad-stuff-here
复制代码
请注意,您大概还需要实验差别的协议。有时,服务器的行为会有所差别,详细取决于请求行包罗HTTP照旧HTTPS URL。
添加换行

: Add line wrapping
您还可以通过缩进带有空格字符的HTTP标头来发现古怪的行为。某些服务器会将缩进的标头表明为换行,因此将其视为前一个标头值的一部门。其他服务器将完全忽略缩进的标头。
由于这种情况的处理惩罚方式非常不一致,因此处理惩罚您的请求的差别系统之间通常会存在差异。比方,思量以下请求:
  1. GET /example HTTP/1.1 Host: bad-stuff-hereHost: vulnerable-website.com
复制代码
该网站大概会阻止带有多个主机标头的请求,但是您可以通过缩进其中的一个缩略来绕过此验证。如果前端忽略缩进的标头,则该请求将作为对弱势网站的普通请求进行处理惩罚。现在,假设后端忽略前导空间,而且在重复的情况下将优先处理惩罚第一个标头。这种差异大概使您可以通过“包装的”主机标头通报任意值。
其他本事

: Other techniques
这只是发出有害的,暗昧其词的请求的许多大概方式的一小部门。您还可以采用多种HTTP请求走私技能来构造主机标头攻击。
注入主机覆盖头

: Inject host override headers
纵然您不能使用歧义的请求覆盖Host标头,也有其他方法可以覆盖它的值,同时保持原样。这包罗通过旨在满意此目的而设计的其他几个HTTP标头之一注入有效负载,纵然对于更多无辜的用例也是如此。
正如我们已经讨论的那样,通常可以通过某种中间系统(比方负载均衡器或反向代理)访问网站。在这种体系布局中,后端服务器吸收的Host标头大概包罗这些中间系统之一的域名。这通常与请求的功能无关。
为相识决此问题,前端可以注入X-Forwarded-Host标头,其中包罗来自客户端初始请求的Host标头的原始值。因此,当存在X-Forwarded-Host标头时,许多框架将改为引用它。纵然没有前端使用此标头,您也大概会观察到此行为。
有时您可以使用X-Forwarded-Host注入恶意输入,同时绕过Host标头自己的任何验证。
  1. GET /example HTTP/1.1Host: vulnerable-website.comX-Forwarded-Host: bad-stuff-here
复制代码
只管X-Forwarded-Host是此行为的事实上的尺度,但是您大概会遇到其他具有类似目的的标头,包罗:


  • X-Host
  • X-Forwarded-Server
  • X-HTTP-Host-Override
  • Forwarded
  提示:
在Burp Suite中,您可以使用Param Miner扩展的“ Guess headers”功能,使用其广泛的内置单词表来自动探查受支持的标题。
从安全角度来看,必须注意一些网站,甚至大概是您自己的网站,无意中支持这种行为。这通常是因为这些标头中的一个或多个在默认情况下在某些第三页中启用
2.如何利用HTTP Host标头

一旦确定可以将任意主机名通报给目的应用程序,就可以开始寻找利用它的方法。
在本节中,我们将提供一些您大概能够构造的常见HTTP Host标头攻击的示例。我们还创建了一些故意易受攻击的网站,以便您可以相识这些弊端的工作原理并将所学内容进行测试。
攻击者有时可以使用Host标头进行暗码重置中毒攻击。要相识有关此技能的更多信息,并使用我们的LABS亲自实验,请检察下面的专用主题。
暗码重置中毒


暗码重置如何工作?

险些所有需要登录的网站还实现了允许用户忘记暗码重设暗码的功能。有几种方法可以实现此目的,并具有差别程度的安全性和实用性。最常见的方法之一是这样的:
1.用户输入其用户名或电子邮件所在,然后提交暗码重设请求。
2.该网站查抄该用户是否存在,然后生成一个暂时的,唯一的,高熵令牌,该令牌与后端的用户帐户相关联。
3.该网站向用户发送一封电子邮件,其中包罗用于重置其暗码的链接。用户的唯一重置令牌作为查询参数包罗在相应的URL中:
https://normal-website.com/reset?token=0a1b2c3d4e5f6g7h8i9j
4.当用户访问此URL时,网站将查抄提供的令牌是否有效,并使用它来确定要重置哪个帐户。如果一切都符合预期,则可以为用户提供输入新暗码的选项。最后,令牌被销毁。
5.与其他方法相比,此过程足够简单且相对安全。但是,其安全性依赖于以下原则:只有目的用户才气访问其电子邮件收件箱,从而可以访问其唯一令牌。暗码重置中毒是窃取此令牌以更改另一个用户暗码的方法。
如何构造暗码重置中毒攻击

如果发送给用户的URL是基于可控输入(比方Host标头)动态生成的,则大概会构成如下的暗码重置中毒攻击:
1.攻击者根据需要获取受害者的电子邮件所在或用户名,并代表他们提交暗码重置请求。提交表单时,他们将拦截生成的HTTP请求并修改Host标头,使其指向他们控制的域。在此示例中,我们将使用evil-user.net。
2.受害人直接从网站上收到真实的暗码重置电子邮件。这似乎包罗用于重置其暗码的普通链接,而且至关重要的是,包罗与他们的帐户相关联的有效暗码重置令牌。但是,URL中的域名指向攻击者的服务器:
https://evil-user.net/reset?token=0a1b2c3d4e5f6g7h8i9j
3.如果受害者单击此链接(或以其他方式(比方,通过防病毒扫描程序获取),则暗码重置令牌将被通报到攻击者的服务器。
4.攻击者现在可以访问易受攻击的网站的真实URL,并通过相应的参数提供受害者的被盗令牌。然后,他们将能够将用户的暗码重置为所需的暗码,然后登录到其帐户。
比方,在实际攻击中,攻击者大概会实验通过首先使用伪造的违规通知对受害者进行预热来提高受害者单击链接的大概性。
纵然您无法控制暗码重置链接,有时也可以使用Host标头将HTML注入敏感的电子邮件中。请注意,电子邮件客户端通常不执行JavaScript,但是其他HTML注入技能(如dangling markup attacks悬挂标志攻击)大概仍然适用。
LAB: Basic password reset poisoning

在这个实验室里你只需要把Host改成your-exploit-server的所在

然后检察your-exploit-server日志即可得到目的的重置暗码token
LAB: Password reset poisoning via middleware

在这个实验室里你只需要把X-Forwarded-Host改成your-exploit-server的所在

然后检察your-exploit-server日志即可得到目的的重置暗码token
LAB: Password reset poisoning via dangling markup


在这个实验室里你只需要把Host 改为:Host: ac4c1f641f959ad780b84e6300a700d0.web-security-academy.net:'
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则


专注素材教程免费分享
全国免费热线电话

18768367769

周一至周日9:00-23:00

反馈建议

27428564@qq.com 在线QQ咨询

扫描二维码关注我们

Powered by Discuz! X3.4© 2001-2013 Comsenz Inc.( 蜀ICP备2021001884号-1 )