我们知道网址本身并不是传递或存储信息的安全方式。太多程序会对URL执行意外处理，甚至通过网络发送，一般来说，URL不会受到高度重视。
过去我们见过比特币钱包，它依赖于保持URL的秘密，但他们发现很难通过URL（通过Skype发送，或通过电子邮件发送，或者即使只是将其输入谷歌浏览器omnibar）也会被远程服务器存储，并可能公开显示。
所以我认为URL会永远被遗弃作为携带任何私人数据的手段......尽管非常方便，但现在我已经看到一些使用URL片段的网站 - 之后的URL部分'＃' - 作为一种'安全'存储。我认为期望Google不会解析片段并允许它显示在搜索结果中，因此不应发布数据。
但这似乎是产品安全性的一个相当薄弱的基础。有一种方法可以安全地移动URL片段中的数据，但我们真的可以依赖它吗？
所以，我真的很想理解......任何人都可以解释一下，片段标识符的安全模型是什么？
答案 0 :(得分：4)
如果超链接的目标主机与源主机不同，那么通过
Referer标头泄漏许可承载URL只是一个问题，因此可能是恶意的。 RFC 2616预见到信息泄露的危险，因此在第15.1.3节中提供了安全指导：“因为链接的来源可能是私人信息，或者可能显示其他私人信息来源，...如果引用页面是，则客户端不应在（非安全）HTTP请求中包含
Referer标头字段使用安全协议进行转移。“不幸的是，客户已在信中实施了此指南，这意味着如果引荐页面和目标网页都使用HTTPS，但由不同的主机提供服务，则会发送
Referer标头。这种对Referer标题的热情使用将对实现web-key概念构成重大障碍，因为它不是针对使用
Referer标题的一个无关的，而是幸运的要求。 RFC 2616的第14.36节管理Referer标头的使用，声明：“URI绝不能包含片段。”对已部署的Web浏览器的测试表明，此要求通常已实施。将不允许的权限密钥放入片段中会生成一个https URL，其类似于：
<https://www.example.com/app/#mhbqcmmva5ja3>。获取表示
将密钥放在URL片段组件中可防止通过
Referer标头泄漏，但也会使取消引用操作复杂化，因为片段也不会在HTTP请求的Request-URI中发送。使用Web 2.0的两个基石克服了这种复杂性：JavaScript和XMLHttpRequest。
所以，是的，您可以使用片段标识符来保存秘密，但是如果您的应用程序容易受到XSS攻击，那么这些秘密可能会被窃取和泄露，而且片段标识符也没有相应的http-only cookie。
我相信Waterken通过在运行任何应用程序代码之前从片段中移除秘密来缓解这种情况，其方式与许多敏感守护程序zero-out their argv相同。
答案 1 :(得分：0)
＃之后的部分不比URL的任何其他部分更安全。唯一的区别是它可以从Web服务器访问日志中省略。但是Web服务器不是威胁。
只要您将密码存储在URL或其他可以公开的地方，它就是不安全的。这就是我们发明密码的原因，因为它们应该只存在于人们头脑中。
问题不在于找到一种在URL中存储秘密的方法。 这是不可能的，因为正如你所说：可能会成为公众。如果你需要的只是URL，并且它是公共的，那么没有人关心原始数据是什么。 Bacuse他们有他们需要的东西，URL。因此，仅依靠URL进行身份验证就是.. moronic。
问题是以安全的方式存储您的秘密，并创建安全的系统。