【译】关于控制 Referer 你想要知道的一切（和更多的）

发表于 5年以前 | 总阅读数：1422 次

原文：http://www.zcfy.cc/article/692

本文是一篇技术文章，目的是对其他有安全意识的网页应用实现者提供有用的参考资料。普通的 FastMail 用户也能读一读，也许可以找点乐子，但也可以忽略它。这篇文章无关你的 FastMail 账号或者 email 软件。

什么是 Referer 头

Referer 头可以追溯到 HTTP 协议的起源，它可能是 HTTP 协议中第一个被拼写错误的标准头。HTTP 规范是这样描述它的：

Referer[sic] 请求头字段允许由客户端指定资源的 URI 来自于哪一个请求地址，这对服务器有好处（应该是 "referrer" 这个字段拼错了）。Referer 请求头让服务器能够拿到请求资源的来源，可以用于分析用户的兴趣爱好、收集日志、优化缓存等等。同时也让服务器能够发现过时的和错误的链接并及时维护。

[sic] 是拉丁文里「原文如此」的意思。很多其他标准在表述 HTTP 中的 Referer 请求头时，都会加上 [sic]，避免引起读者误解。----译者注

Referer 有许多合法的用例，例如找到你网站上的死链、追踪错误或者找到用户是通过哪些搜索条件找到你的网站的。它也可以被用来增强安全性：检查 Referer 头是一个阻止跨站请求伪造的办法。

尽管如此，有时候，对于一个网站来说，由于涉及隐私和安全问题，防止 referrer 泄漏很重要。例如，我们会设法保持 FastMail 网页应用的 URL 比较干净和可读性强，然而这却意味着有时候 URL 中可能包含一些半私人的信息，而这些信息你并不想泄漏。比如，你正在考虑突然行动来收购 ACME 公司，你可能会创建一个叫做"ACME 公司收购"的文件夹专用于邮件沟通，而如果你在文件夹里发起一个交流，URL 将会是：

https://www.fastmail.com/mail/ACME_Inc_Acquisition/{threadId}-{messageId}

假设你在其中一封邮件里点击了一个链接到 ACME 公司的网站----如果 referrer 被泄漏，网站日志将显示出有人有一个文件夹叫做"ACME 公司收购"（如果有人想看）。不是一个很严重的泄漏，但依然是我们希望能避免的。

从安全的角度出发，"保密" URL 目前被经常用于访问内容的身份验证。这个 URL 包含一个随机或者加密签名的 token，因此它不会被猜测出来，但是如果得知了这个 URL，你就能访问到内容。例如，许多管理用户文件（比如附件）的服务将文件存放在与主服务独立的域名下，按这么设计，任何包含授权的 cookies 不会被发送，因此一个保密 URL 经常被用来替代 cookies 保证只有合法的用户才能访问到内容。尽管如此，如果用户从附件中的一个链接跳到其他网站，那个网站现在可以利用 Referer 头来下载附件，尽管这个附件本该是私有的。

所以如果你遇到这种情况，为了保护隐私和安全性，一个网站想要移除 Referer 头，该怎么做到呢？

为一个单独的链接移除 referrer

HTML5 添加了一大堆有用的新值到 rel 属性上，其中有一个值是 noreferrer（是的，这一次拼写对了）。当这个属性被添加上之后，用户请求该链接资源时，浏览器不设置 Referer 头。WebKit（Chrome/Safari）早在 2009 年就支持了这个值，Firefox 到 2014 年才支持它，而直到最近它才被 Microsoft Edge 支持（但不是任何版本的 IE 都支持）。

这意味着如果你的网站的主要用户都使用最新版本的浏览器，noreferrer 已经被广泛支持了。对于旧的浏览器，你可以通过一些小技巧来降级处理，具体做法是用 JavaScript 打开一个新的标签页，然后在其中输出一个 refresh 标签来加载实际你想要在这个标签页中加载的 url：

var newWindow = window.open( "", "_blank" );
    newWindow.document.write(
        "<META HTTP-EQUIV="refresh" content="0; url=" + url + "">"
    );

这也会移除 referrer（但是它强制你在新标签页中打开链接）。

为整个网页的每个链接移除 referrer

一个链接一个链接地应用上面的策略基本上也能用了，但这么做很容易漏掉一些，而且不总是实际可行，它是否可行，取决于你的网页是如何生成的。在许多场景下，你希望应用策略到整个网页。因此我们还得再用一些黑科技。

在线 HTML 规范引入了一个新的 <meta name="referrer"> 标签，在网页上添加它可以设置一个全局的策略。这个 meta 允许设置的值是一组语义化的可扩展的集合，它们定义在Referrer 策略规范文档中，已经成为了 W3C 的工作草案。规范里面支持更多可扩展的策略，包括 same-origin（只在同域请求时才发送 referrer）以及 origin-when-cross-origin（当发起一个跨域请求时，referrer 只包含域名，不包含具体路径）。

根据标准，你也可以通过发送 Referrer-Policy 响应头来设置策略，有时候比使用标签有用得多（例如当返回第三方内容，而你不想修改内容的时候），这么做也更符合其他安全策略的写法，它们也通常通过 HTTP 响应头来设置。

尽管如此，虽然（非常有用也通常正确的）Can I Use 网站将 Chrome 和 Fixfox 归于完全支持 referrer 策略的浏览器，但我们的测试结果显示它们只支持不那么有用的 meta 标签方式，而不支持响应头。也许 Can I Use 网站的数据已经过时了，因为规范已经更新。Edge 和 Safari 也只支持 meta 标签，而且是一个旧的规范草案，只支持一些更受限的策略值。

这还不是全部。Referrer 策略也可以通过 Content-Security-Policy(CSP) 响应头来设置。令人困惑的是，这被定义于 CSP 规范的 1.1 版本中，但是在 2 或 3 版中不存在。我们只能假定它被废弃了，替换为新的（也还未被支持的）Referrer-Policy 响应头。CSP 1.1 中允许的策略与旧的 <meta> 策略规范一致，这对"废弃论"提供了支持。再一次令人困惑的是，其中的值不是用单引号标记的，不同于 CSP 其他的关键字例如 'self'。Can I Use 只列出对 CSP 1.0 和 CSP 2.0 的支持，这两个版本都没有描述对 Referrer 策略的支持。但是，我们的测试结果再一次显示最新的 Chrome/Opera/Firefox 支持它，而 Edge/Safari 不支持。

顺便提一句，这个策略一开始就没有被开发成一个响应头似乎很奇怪，因为那样明显能比 <meta> 标签带来更大的好处（事实上那样确实有用得多，因为如果是响应头，你也可以使用一个 http-equiv 标签来插入策略）。

不管怎样，看起来最终浏览器为了这个重要的安全问题实现了一系列解决方案，但是目前的情况对开发者来说不理想。在每个链接使用 rel="noreferrer" 被广泛支持了，<meta name="referrer"> 标签的过时规范也被广泛支持，而如果这两个都不支持，那么 Content-Security-Policy 也支持一部分用户，但这不是全部用户。至于这是否足够了，你得基于你应用的安全模型做出判断。不过，了解你可选择的方法是重要的第一步！