使用片段标识符在 URL 中保存私有数据有多安全？

Question

我们知道 URL 本身并不是传递或存储信息的安全方式。太多的程序会对 URL 进行意外处理，甚至通过网络传送，一般来说，URL 并没有高度重视其隐私。

例如，过去我们看到过比特币钱包，它们依赖于对 URL 保密，但他们发现有太多方法可以让 URL（通过 Skype 发送，或通过电子邮件发送，甚至只是输入它进入 Google Chrome 多功能栏）将被远程服务器存储，并可能公开显示。

所以我认为 URL 作为携带任何私人数据的一种手段将被永远抛弃......尽管非常方便，但现在我看到一些使用 URL 片段的网站 - '# 之后的 URL 部分' - 作为一种“安全”存储。我认为期望谷歌不会解析片段并允许它显示在搜索结果中，因此不应发布数据。

但这似乎是您产品安全性的一个非常薄弱的​​基础。有一种方法可以安全地移动 URL 片段中的数据会带来巨大的好处，但我们真的可以依赖它吗？

所以，我真的很想了解......谁能解释一下，片段标识符的安全模型是什么？

Answer 1

Tyler Close 和其他为 Waterken 设计安全架构的人对此进行了相关研究。他们使用 URI 片段中不可猜测的字符串作为网络密钥：

\n\n

\n

如果超链接的目标主机与源主机不同，则通过标头泄漏权限承载 URLReferer仅在实践中才会出现问题，因此可能是恶意的。RFC 2616 预见到了此类信息泄露的危险，因此在第 15.1.3 节中提供了安全指南：

\n\n

\n

“由于链接的来源可能是私人信息或可能泄露其他私人信息源，\xe2\x80\xa6Referer如果引用页面是通过安全协议。”

\n

\n\n

不幸的是，客户已经严格执行了此指南，这意味着Referer如果引用页面和目标页面都使用 HTTPS，但由不同的主机提供服务，则会发送标头。

\n\n

如果不是因为对标头的使用提出了一个不相关但相当幸运的要求，那么对 Referer 标头的这种热情使用将为网络密钥概念的实现带来重大障碍Referer。RFC 2616 第 14.36 节规定了Referer标头的使用，规定：“URI 不得包含片段”。对已部署的 Web 浏览器的测试表明，此要求已得到普遍实现。

\n\n

将不可猜测的权限密钥放入片段段中会生成一个 https URL，如下所示：<https://www.example.com/app/#mhbqcmmva5ja3>。

\n\n

获取表示

\n\n

将密钥放在 URL 片段组件中可以防止通过Referer标头泄漏，但也会使取消引用操作变得复杂，因为片段也不会在 URL 中发送。Request-URIHTTP 请求中发送。使用 Web 2.0 的两个基石：JavaScript 和 XMLHttpRequest 可以克服这种复杂性。

\n

\n\n\n\n

所以，是的，您可以使用片段标识符来保存秘密，但如果您的应用程序容易受到 XSS 的影响，这些秘密可能会被窃取和泄露，并且片段标识符没有相当于 http-only cookie 的东西。

\n\n

我相信 Waterken 通过在运行任何应用程序代码之前从片段中删除秘密来缓解这一问题，就像许多敏感守护进程将其argv.

\n