简短的回答。是的，使用异地Referer: 标头阻止请求可能有一些安全优势，但我不建议您实施它。可用性成本是巨大的，并且超过了任何安全收益。

我觉得，作为安全专业人员，我们的工作不仅仅是推荐人们应该实施的防御措施——它也是确定人们不应该实施的防御措施。这是一个，在我个人看来。

背景。根据最初的问题，提供对相关背景的回顾并更准确地阐明您可能正在考虑的具体防御措施听起来可能会有所帮助。

您似乎正在考虑检查Referer:传入请求中的标头。大多数现代浏览器Referer:在大多数请求上设置标头以列出触发此请求或包含此链接的前一页的 URL。有些请求不带Referer:标头；一个例子是前一页是通过 HTTPS 的，那么浏览器将不会设置Referer:标题。

重要的是要知道Referer:标头不是为安全而设计的，并且不能被信任。有许多攻击会导致浏览器忽略Referer:标头。还有一些攻击可用于针对某些浏览器来伪造Referer:标头（使浏览器发送带有Referer:攻击者选择的欺骗标头的请求）。因此，大多数安全人员建议不要将Referer:标头作为您的主要安全线。

同样重要的是要知道Referer:标头不能保证包含在内，有时会被阻止。标Referer:头具有隐私含义：它可用于跟踪网络上的人。有些人认为他们的浏览器经常告诉站点 B 他们只是在站点 A 的某个特定页面上，这侵犯了他们的隐私。因此，有些人将他们的浏览器配置为阻止Referer:标头的传输。此外，一些公司防火墙和代理会去掉Referer:标头，以避免将机密或专有信息泄露给外部网站。

原始 RFC (RFC 2068) 声明Referer:标头不是强制性的，并明确建议浏览器应为用户提供一种禁用Referer:标头传输的方法。

由于所有这些原因，一部分合法请求只是不包含Referer:标头。

现在，我怀疑您提出了两种可能的防御措施之一：

1. 严格的Referer检查。您在您的网站上指定一个指定的登录页面。如果您的网站收到带有标头的请求，该Referer:标头引用不在您网站上的任何 URL，或者收到没有Referer:标头的请求，则服务器会立即响应并重定向到您的着陆页。

2. 松散的Referer检查。与上述相同，除了Referer:允许没有标头的请求（它们不会触发重定向）。

从安全角度来看， 松散的 Referer 检查没有任何意义：攻击者可以通过多种 方式触发受害者的浏览器发出请求并抑制Referer:. 所以我假设您正在考虑是否实施严格的Referer检查。

安全优势。那么，严格的Referer检查是否具有潜在的安全优势？是的。他们包括：

• CSRF 防御。严格的引用检查使得跨站点请求伪造攻击变得更加困难，因为其他站点无法将用户引导到登录页面以外的任何地方。

• XSS 防御。严格的引用检查可以使反射型 XSS 攻击更加困难，因为其他站点无法欺骗受害者的浏览器访问易受攻击的 URL。

• 点击劫持和框架。我不知道严格的推荐人检查是否有助于防止点击劫持或被陷害。我必须把它留给其他人。

不过，有一些警告。对于这些风险中的每一个，都有更好的防御措施。例如，对于 CSRF 防御，使用反 CSRF 令牌。对于 XSS 防御，不要在您的软件中引入 XSS 漏洞；使用具有上下文相关自动转义的模板系统；等等。对于点击劫持和框架，使用经过时间考验的框架破坏技术。

可用性成本。在整个站点中启用严格的推荐人检查会产生一些主要的可用性成本。这些包括：

• 它可以防止深度链接。它可以防止人们链接到您网站上的页面。这意味着您不会获得其他人向您发送的流量，因为他们链接到您网站上的精彩内容。

• 它可以防止深度书签。它可以防止您的用户为登录页面以外的任何内容添加书签。从用户的角度来看，这很烦人。

• 它阻止了一些用户。一些用户将无法使用您的网站，因为他们使用了阻止Referer:标头的隐私机制，或者因为他们位于去除Referer:标头的公司防火墙之后，等等。这会减少您的潜在用户群。此外，一些阻止Referer:标题的人是最精通技术的用户，他们可能是您的早期采用者，他们可能会将您的网站传播给其他人；您不想不必要地阻止他们使用您的网站。

全面的。所以，当我看到这个时，我看到了一些可疑的安全优势和主要的可用性成本。此外，所有这些安全优势都可以通过其他不损害可用性的方式获得，只需使用标准安全机制即可。因此，我不建议您采用严格的referer检查。