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

Question

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

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

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

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

所以，我真的很想了解......任何人都可以解释一下，片段标识符的安全模型是什么？

Answer 1

Tyler Close 和其他为 Waterken 做安全架构的人对此进行了相关研究。他们在 URI 片段中使用不可猜测的字符串作为 web-keys :

This leakage of a permission bearing URL via the Referer header is only a problem in practice if the target host of a hyperlink is different from the source host, and so potentially malicious. RFC 2616 foresaw the danger of such leakage of information and so provided security guidance in section 15.1.3:

"Because the source of a link might be private information or might reveal an otherwise private information source, … Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol."

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

这种对 Referer header 的狂热使用会给 Web key 概念的实现带来重大障碍，如果不是因为一个不相关但幸运的是，对使用 Referer 的要求。 header 。 RFC 2616 第 14.36 节管理 Referer 的使用 header ，指出:“URI 不得包含片段。”已部署的 Web 浏览器的测试表明此要求已普遍实现。

将无法猜测的权限 key 放在片段段中会生成一个类似于以下内容的 https URL:<https://www.example.com/app/#mhbqcmmva5ja3> .

获取表示

将 key 放在 URL 片段组件中可防止通过 Referer 泄露 header 但也使取消引用操作复杂化，因为该片段也未在 Request-URI 中发送一个 HTTP 请求。使用 Web 2.0 的两个基石:JavaScript 和 XMLHttpRequest 可以克服这种复杂性。

---

所以，是的，您可以使用片段标识符来保存 secret ，但如果您的应用程序容易受到 XSS 攻击，这些 secret 可能会被窃取和泄露，并且片段标识符没有等效的仅限 http cookie。

我相信 Waterken 通过在以与许多敏感守护程序相同的方式运行任何应用程序代码之前从片段中删除 secret 来缓解这种情况 zero-out their argv .