网站建设常规尺寸网站制作出名的公司

当前位置： 首页 > news >正文

网站建设常规尺寸,网站制作出名的公司,郑州网站排,做游戏网站用什么软件HTTP Host 标头攻击 —— HTTP Host header attacks 1. 什么是 HTTP Host 标头#xff1f;2. 什么是 HTTP Host 标头攻击#xff1f;3. HTTP Host 标头漏洞是如何产生的#xff1f;4. 如何测试 HTTP Host 标头漏洞4.1 提供任意 Host 标头4.2 检查有缺陷的验证4.3 发送不明… HTTP Host 标头攻击 —— HTTP Host header attacks 1. 什么是 HTTP Host 标头2. 什么是 HTTP Host 标头攻击3. HTTP Host 标头漏洞是如何产生的4. 如何测试 HTTP Host 标头漏洞4.1 提供任意 Host 标头4.2 检查有缺陷的验证4.3 发送不明确的请求4.4 注入主机覆盖标头 5. 如何利用 HTTP Host 标头漏洞5.1 密码重置中毒5.2 Web 缓存中毒5.3 利用经典的服务器端漏洞5.4 Host标头身份验证绕过5.5 使用虚拟主机暴力破解访问内部网站5.6 基于路由的 SSRF5.7 连接状态攻击5.8 基于格式错误的请求行的 SSRF 6. 防止 HTTP Host 标头攻击的方法 1. 什么是 HTTP Host 标头 HTTP Host 标头是自 HTTP/1.1 起的必需请求标头。它指定客户端要访问的域名。例如当用户访问 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 标头来确定预期的后端并相应地转发请求。 2. 什么是 HTTP Host 标头攻击 HTTP Host 标头攻击利用易受攻击的网站这些网站以不安全的方式处理 Host 标头的值。如果服务器隐式信任 Host 标头并且无法正确验证或转义它则攻击者可能能够使用此输入注入操纵服务器端行为的有害负载。涉及将有效负载直接注入 Host 标头的攻击通常称为“Host 标头注入”攻击。 现成的 Web 应用程序通常不知道它们部署在哪个域上除非在设置过程中在配置文件中手动指定。当他们需要知道当前域时例如要生成电子邮件中包含的绝对 URL他们可能会求助于 Host 标头中检索域 a hrefhttps://_SERVER[HOST]/supportContact support/aheader 值还可用于网站基础设施的不同系统之间的各种交互。 由于 Host 标头实际上是用户可控制的因此这种做法可能会导致许多问题。如果输入没有正确转义或验证则 Host 标头是利用一系列其他漏洞的潜在载体最明显的是 Web 缓存中毒特定功能中的业务逻辑缺陷基于路由的 SSRF典型的服务器端漏洞例如 SQL 注入 3. HTTP Host 标头漏洞是如何产生的 HTTP Host 标头漏洞通常是由于错误地假设标头不是用户可控制的而引起的。这会在 Host 标头中创建隐式信任并导致其值验证不充分或转义即使攻击者可以使用 Burp Proxy 等工具轻松修改它。 即使 Host 标头本身得到了更安全的处理根据处理传入请求的服务器的配置也可能通过注入其他标头来覆盖 Host。有时网站所有者不知道这些标头默认受支持因此它们可能不会受到相同级别的审查。 事实上其中许多漏洞的出现不是因为编码不安全而是因为相关基础设施中一个或多个组件的配置不安全。出现这些配置问题的原因是 Web 站点将第三方技术集成到其架构中而不一定了解配置选项及其安全影响。 4. 如何测试 HTTP Host 标头漏洞 要测试网站是否容易受到 HTTP Host 标头的攻击您需要一个拦截代理例如 Burp Proxy以及 Burp Repeater 和 Burp Intruder 等手动测试工具。 简而言之您需要确定是否能够修改 Host 标头并且仍然能够使用您的请求到达目标应用程序。如果是这样您可以使用此标头来探测应用程序并观察这对响应的影响。 4.1 提供任意 Host 标头 在探测 Host 标头注入漏洞时第一步是测试当您通过 Host 标头提供任意的、无法识别的域名时会发生什么情况。 一些拦截代理直接从 Host 标头派生目标 IP 地址这使得这种测试几乎是不可能的;您对标头所做的任何更改都只会导致请求被发送到完全不同的 IP 地址。但是Burp Suite 会准确地保持 Host 标头和目标 IP 地址之间的分离。这种分离允许您提供所需的任何任意或格式错误的 Host 标头同时仍确保将请求发送到预期目标。 Tip 目标 URL 显示在面板顶部对于 Burp Repeater 和Proxy interception或 Burp Intruder 的“Target”目标选项卡上。您可以通过点击铅笔图标手动编辑目标。 有时即使您提供了意外的 Host 标头您仍然能够访问目标网站。这可能有多种原因。例如服务器有时会配置默认或回退选项以防它们收到不认识的域名请求。如果您的目标网站恰好是默认网站那么您很幸运。在这种情况下您可以开始研究应用程序对 Host 标头执行的作以及此行为是否可被利用。 另一方面由于 Host 标头是网站运行方式的基本组成部分因此篡改它通常意味着您根本无法访问目标应用程序。收到您的请求的前端服务器或负载均衡器可能根本不知道将其转发到何处从而导致某种类型的“Invalid Host header”错误。如果您的目标通过 CDN 访问则尤其可能出现这种情况。在这种情况下您应该继续尝试下面概述的一些技术。 4.2 检查有缺陷的验证 您可能会发现您的请求由于某种安全措施而被阻止而不是收到 “Invalid Host header” 响应。例如某些网站将验证 Host 标头是否与 TLS 握手的 SNI 匹配。这并不一定意味着它们不受 Host 标头攻击。 您应该尝试了解 Web 站点如何解析 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 标头解析错误的内容。 4.3 发送不明确的请求 验证主机的代码和对主机执行易受攻击的操作的代码通常驻留在不同的应用程序组件中甚至位于不同的服务器上。通过识别和利用它们检索 Host 标头的方式中的差异您可以发出一个不明确的请求该请求似乎具有不同的主机具体取决于正在查看它的系统。 以下是如何创建不明确请求的几个示例。 注入重复的 Host 标头 一种可能的方法是尝试添加重复的 Host 标头。诚然这通常只会导致您的请求被阻止。但是由于浏览器不太可能发送此类请求因此您偶尔可能会发现开发人员没有预料到这种情况。在这种情况下您可能会暴露一些有趣的行为怪癖。 不同的系统和技术会以不同的方式处理这种情况但通常会优先考虑两个 Headers 中的一个从而有效地覆盖其值。当系统对哪个标头是正确的标头存在分歧时这可能会导致您可以利用的差异。请考虑以下请求 GET /example HTTP/1.1 Host: vulnerable-website.com Host: bad-stuff-here假设前端优先使用 Headers 的第一个Host实例但后端优先使用后一个Host实例。在这种情况下您可以使用第一个标头来确保将请求路由到预期目标并使用第二个标头将有效负载传递到服务器端代码中。 提供绝对 URL 尽管请求行通常指定所请求域上的相对路径但许多服务器也被配置为理解对绝对 URL 的请求。 同时提供绝对 URL 和 Host 标头所导致的歧义也可能导致不同系统之间的差异。正式地说在路由请求时应优先考虑请求行但在实践中情况并非总是如此。您可以利用这些差异的方式与利用重复的 Host 标头大致相同。 GET https://vulnerable-website.com/ HTTP/1.1 Host: bad-stuff-here请注意您可能还需要尝试不同的协议。服务器的行为有时会有所不同具体取决于请求行是包含 HTTP 还是 HTTPS URL。 添加换行 您还可以通过使用空格字符缩进 HTTP 标头来发现古怪的行为。一些服务器会将缩进的 Headers 解释为换行因此将其视为前一个 Headers 值的一部分。其他服务器将完全忽略缩进的 Headers。 由于此案例的处理高度不一致因此处理您的请求的不同系统之间经常会出现差异。例如请考虑以下请求 GET /example HTTP/1.1Host: bad-stuff-here Host: vulnerable-website.com该网站可能会阻止具有多个 Host 标头的请求但您可以通过像这样缩进其中一个标头来绕过此验证。如果前端忽略了缩进的 header则该请求将作为vulnerable-website.com 请求处理。现在假设后端忽略了前导空格并在重复的情况下优先于第一个 Headers。这种差异可能允许您通过 “wrapped” Host 标头传递任意值。 其他技术 这只是发出有害、模棱两可的请求的众多可能方法中的一小部分。例如您还可以采用许多 HTTP 请求走私技术来构建 Host 标头攻击。请查阅专门的HTTP请求走私的相关内容。 4.4 注入主机覆盖标头 即使您无法使用不明确的请求覆盖 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-HostX-Forwarded-ServerX-HTTP-Host-OverrideForwarded Tip 在 Burp Suite 中你可以使用 Param Miner 参数挖掘器扩展的“猜测标头”功能通过其广泛的内置单词列表自动探测受支持的标头。 从安全角度来看请务必注意某些网站甚至可能是您自己的网站无意中支持此类行为。这通常是因为在它们使用的某些第三方技术中默认启用了这些标头中的一个或多个。 5. 如何利用 HTTP Host 标头漏洞 一旦您确定可以将任意主机名传递给目标应用程序您就可以开始寻找利用它的方法。 5.1 密码重置中毒 密码重置中毒是一种技术攻击者通过这种技术操纵易受攻击的网站生成指向其控制下的域的密码重置链接。可以利用此行为来窃取重置任意用户密码所需的秘密令牌并最终破坏他们的帐户。 密码重置如何工作 几乎所有需要登录的网站都实现了允许用户在忘记密码时重置密码的功能。有几种方法可以做到这一点具有不同程度的安全性和实用性。最常见的方法之一是这样的 用户输入其用户名或电子邮件地址并提交密码重置请求。该网站检查此用户是否存在然后生成一个临时的、唯一的、高熵的令牌该令牌与后端的用户帐户相关联。该网站会向用户发送一封电子邮件其中包含用于重置其密码的链接。用户的唯一重置令牌作为查询参数包含在相应的 URL 中 https://normal-website.com/reset?token0a1b2c3d4e5f6g7h8i9j当用户访问此 URL 时网站会检查提供的令牌是否有效并使用它来确定正在重置的帐户。如果一切正常则用户可以选择输入新密码。最后令牌被销毁。 与其他一些方法相比此过程足够简单且相对安全。但是它的安全性依赖于以下原则只有目标用户才能访问其电子邮件收件箱因此才能访问其唯一令牌。密码重置中毒是一种窃取此令牌以更改其他用户密码的方法。 如何构建密码重置中毒攻击 如果发送给用户的 URL 是基于可控输入如 Host 头动态生成的则有可能构建如下重置密码中毒攻击 攻击者根据需要获取受害者的电子邮件地址或用户名并代表他们提交密码重置请求。在提交表单时他们拦截生成的 HTTP 请求并修改 Host 标头使其指向他们控制的域。在此示例中我们将使用 evil-user.net。受害者直接从该网站收到一封真正的密码重置电子邮件。这似乎包含一个用于重置其密码的普通链接并且至关重要的是它包含与其帐户关联的有效密码重置令牌。但是URL 中的域名指向攻击者的服务器 https://evil-user.net/reset?token0a1b2c3d4e5f6g7h8i9j如果受害者点击此链接或以其他方式获取例如通过防病毒扫描程序获取密码重置令牌将被传送到攻击者的服务器。攻击者现在可以访问易受攻击网站的真实 URL并通过相应的参数提供受害者被盗的令牌。然后他们将能够将用户的密码重置为他们喜欢的任何密码然后登录他们的帐户。 例如在真正的攻击中攻击者可能会通过首先使用虚假的泄露通知来预热受害者从而增加受害者点击链接的可能性。 即使您无法控制密码重置链接您有时也可以使用 Host 标头将 HTML 注入敏感电子邮件。请注意电子邮件客户端通常不执行 JavaScript但其他 HTML 注入技术如悬挂标记攻击可能仍然适用。 5.2 Web 缓存中毒 在探测潜在的 Host 标头攻击时您经常会遇到看似易受攻击但无法直接利用的行为。例如您可能会发现 Host 标头反映在响应标记中没有 HTML 编码甚至直接在脚本导入中使用。反射的客户端漏洞如 XSS通常由 Host 标头引起时不可利用。攻击者无法强制受害者的浏览器以有用的方式发出错误的Host。 但是如果目标使用 Web 缓存则有可能通过说服缓存向其他用户提供中毒响应将这个无用的反射漏洞变成危险的存储漏洞。 要构建网页缓存中毒攻击你需要从服务器引出一个反映注入有效载荷的响应。挑战在于在保留一个仍将映射到其他用户请求的缓存键的同时做到这一点。如果成功下一步是让这个恶意响应被缓存。然后它将被提供给任何试图访问受影响页面的用户。 独立缓存通常在缓存键中包含 Host 标头因此此方法通常最适合集成的应用程序级缓存。也就是说前面讨论的技术有时甚至可以使您毒害独立的 Web 缓存。 5.3 利用经典的服务器端漏洞 每个 HTTP 标头都是利用经典服务器端漏洞的潜在载体Host 标头也不例外。例如您应该尝试通过 Host 标头进行常用的 SQL 注入探测技术。如果将标头的值传递到 SQL 语句中则可能会利用此漏洞。 5.4 Host标头身份验证绕过 访问受限功能 出于相当明显的原因网站通常将某些功能的访问权限限制为仅内部用户。但是某些网站的访问控制功能做出了有缺陷的假设允许您通过对 Host 标头进行简单的修改来绕过这些限制。这可能会为其他漏洞暴露更大的攻击面。 5.5 使用虚拟主机暴力破解访问内部网站 公司有时会犯错误将可公开访问的网站和私有的内部站点托管在同一台服务器上。服务器通常同时具有公共 IP 地址和私有 IP 地址。由于内部主机名可能解析为私有 IP 地址因此仅通过查看 DNS 记录并不总是能检测到这种情况 www.example.com: 12.34.56.78 intranet.example.com: 10.0.0.132在某些情况下内部站点甚至可能没有与之关联的公有 DNS 记录。尽管如此攻击者通常可以访问他们有权访问的任何服务器上的任何虚拟主机前提是他们能够猜到主机名。如果他们通过其他信息泄露等其他方式发现了隐藏的域名他们可以直接提出请求。否则他们可以使用 Burp Intruder 等工具使用候选子域的简单单词列表来暴力破解虚拟主机。 5.6 基于路由的 SSRF 有时还可以使用 Host 标头来发起影响较大的基于路由的 SSRF 攻击。这些有时被称为“Host标头 SSRF 攻击”。 经典的服务器端请求伪造SSRF漏洞通常基于可扩展标记语言外部实体XXE或可利用的业务逻辑这些逻辑会向源自用户可控制输入的 URL 发送 HTTP 请求。另一方面基于路由的 SSRF 依赖于利用在许多基于云的架构中普遍存在的中间组件。这包括内部负载均衡器和反向代理。 虽然这些组件被部署用于不同的目的但从根本上说它们接收请求并将其转发到适当的后端。如果它们被不安全地配置为基于未经验证的 Host 标头转发请求那么它们可能会被操纵将请求错误路由到攻击者选择的任意系统。 这些系统是极好的攻击目标。它们处于特权网络位置允许直接从公共网络接收请求同时也能访问大部分如果不是全部内部网络。这使得主机头成为服务端请求伪造SSRF攻击的有力载体有可能将一个简单的负载均衡器转变为通往整个内部网络的网关。 您可以使用 Burp Collaborator 来帮助识别这些漏洞。如果您在 Host 标头中提供协作者的域并随后收到来自目标服务器或其他路径内系统的 DNS 查询则表明您可以将请求路由到任意域。 在确认您可以成功纵中间系统以将您的请求路由到任意公共服务器之后下一步是查看是否可以利用此行为来访问仅限内部的系统。为此您需要确定目标内部网络上正在使用的私有 IP 地址。除了应用程序泄露的任何 IP 地址外您还可以扫描属于该公司的主机名以查看是否有任何主机名解析为私有 IP 地址。如果所有其他方法都失败了您仍然可以通过简单地暴力破解标准私有 IP 范围如 192.168.0.0/16来识别有效的 IP 地址。 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 到 10.255.255.255 的所有 IP 地址。 5.7 连接状态攻击 出于性能原因许多 Web 站点会使用同一客户端在多个请求/响应周期中重复使用连接。实现不佳的 HTTP 服务器有时基于一个危险的假设工作即某些属性例如 Host 标头对于通过同一连接发送的所有 HTTP/1.1 请求都是相同的。对于浏览器发送的请求来说这可能是正确的但对于从 Burp Repeater 发送的一系列请求来说情况不一定如此。这可能会导致许多潜在问题。 例如您可能偶尔会遇到仅对通过新连接收到的第一个请求执行彻底验证的服务器。在这种情况下您可以通过发送一个看似无辜的初始请求然后通过同一连接跟进您的恶意请求来绕过此验证。 许多反向代理使用 Host 标头将请求路由到正确的后端。如果它们假设连接上的所有请求都针对与初始请求相同的主机则可以为许多 Host 标头攻击提供有用的向量包括基于路由的 SSRF、密码重置中毒和缓存中毒。 5.8 基于格式错误的请求行的 SSRF 自定义代理有时无法正确验证请求行这可能会让您提供不寻常的、格式错误的输入从而产生不幸的结果。 例如反向代理可能会从请求行获取路径为其添加http://backend-server然后将请求路由到该上游 URL。如果路径以 / 字符开头这很好用但如果以 字符开头呢 GET private-intranet/example HTTP/1.1生成的上游 URL 将是http://backend-serverprivate-intranet/example大多数 HTTP 库将其解释为使用用户名backend-server访问private-intranet的请求。 6. 防止 HTTP Host 标头攻击的方法 保护绝对 URL 当您必须使用绝对 URL 时您应该要求在配置文件中手动指定当前域并引用此值而不是 Host 标头。例如这种方法将消除密码重置中毒的威胁。 验证 Host 标头 如果必须使用 Host 标头请确保正确验证它。这应该包括根据允许的域白名单进行检查并拒绝或重定向对无法识别的主机的任何请求。您应该查阅框架的文档以获取有关如何执行此操作的指导。例如Django 框架在配置文件中提供了 ALLOWED_HOSTS 选项。此方法将减少您遭受 Host 标头注入攻击的风险。 不要支持 Host override 标头 还需要检查确保你不支持可能用于构造这些攻击的其他标头特别是X-Forwarded-Host。请记住这些标头可能在默认情况下是受支持的。 将允许的域列入白名单 为了防止对内部基础设施进行基于路由的攻击您应该将负载均衡器或任何反向代理配置为仅将请求转发到允许的域白名单。 小心仅限内部的虚拟主机 使用虚拟主机时您应该避免将仅限内部的网站和应用程序与面向公众的内容托管在同一台服务器上。否则攻击者可能能够通过 Host 标头操作访问内部域。