http-referer - 为什么网站需要引用 header (并且默默地失败)？

Question

我最近注意到一个非常古怪的趋势，我对此感到困惑。在过去的一两个月里，我开始注意到网站在没有引荐 header 的情况下出现故障。

作为背景:您当然会记得引用 header 被滥用于做一大堆事情的古老日子，从特征检测到一些被误导的安全外观。仍然有一些遗留站点依赖于它，但在大多数情况下，引用 header 已被降级为糟糕的设备检测。

想象一下，当不是一个，而是三个现代网站在没有引荐来源的情况下突然崩溃时，我会感到惊讶。

Codepen:笔预览和完整页面 View 刚刚中断 (i.imgur.com/3abXqsC.png)。但编辑器 View 完美运行。

Twitter:基本上每个交互功能都会中断。如果您尝试发推文、转发推文、收藏等，您会收到一个通用的非描述性错误 (i.imgur.com/E6tIKFo.png)。如果您尝试更新设置，它会完全拒绝 (403) (i.imgur.com/51e2d0M.png)。

Imgur:它无法上传任何东西(i.imgur.com/xCWpkGX.png)并最终放弃(i.imgur.com/iO2UlR6.png)。

这三个都是现代网站。 Codepen 自从我开始使用它就已经坏了，所以我不确定它是否总是这样，但 Twitter 和 Imgur 过去在没有推荐人的情况下工作得很好。事实上，我刚刚注意到 Imgur 崩溃了。

此外，所有这些都只生成非描述性错误消息，如果有的话，根本无法识别问题。前两次我花了很多试验和错误来弄清楚，现在我尝试将引用 header 作为第一件事。可是等等!还有更多!解除它们所需要的只是发送一个作为主机根的通用引荐来源网址(即 twitter.com、codepen.io、imgur.com)。您甚至不需要使用带有目录路径的实际 URL!

一个网站，我可以把它归结为糟糕的代码。但是，三个主要的现代网站——尤其是当它们曾经工作的时候——是一个巨大的头痛。

有其他人注意到这种趋势或知道 wtf 正在发生吗？

Answer 1

虽然Referer header 不会“增加安全性”，但它们可用于修剪来自调用请求的浏览器(按引用规则播放)的尝试。它不会使站点免受任何 HTTP 尝试的“安全”，但它是充当代理的浏览器(代表可能毫无戒心的用户运行)的公平过滤器。

以下是一些可能性:

可以防止被劫持(或钓鱼)用户，和/或对表单 POSTS(非幂等请求)的其他注入(inject)攻击，which are not constrained to Same-Origin Policy .

Some requests can leak a little bit of information, event with Same-Origin Policy .

限制第三方使用嵌入内容，例如 iframe、视频/图像和其他盗链。

也就是说，虽然它绝对不应该被视为最后一道防线(例如，它不应该取代正确的身份验证和 CSRF token )，但它确实有助于减少来自浏览器的不希望访问的一些暴露。