06月28, 2016

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

原文: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.0CSP 2.0 的支持,这两个版本都没有描述对 Referrer 策略的支持。但是,我们的测试结果再一次显示最新的 Chrome/Opera/Firefox 支持它,而 Edge/Safari 不支持。

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

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

英文原文:https://blog.fastmail.com/2016/06/20/everything-you-could-ever-want-to-know-and-more-about-controlling-the-referer-header/

本文链接:https://www.h5jun.com/post/everything-you-could-ever-want-to-know-and-more-about-controlling-the-referer-header-fastmail-blog.html

-- EOF --

Comments