秘密URL是否真的安全？
我从来没有在我的系统中留下后门，但出于好奇心，我想知道是否我留下了一个像/ x52d23r这样的秘密URL，允许绕过某种安全措施，而这只是我个人使用 – 第三方没有得到我的信息？
例如，秘密端口可以进行端口扫描和指纹识别，但是对于秘密URL可以使用相同的策略吗？
原来的答案：通过默默无闻的安全是不应该实行的。
我想对此进行扩展，因为我看到一些观点仍然认为秘密URL与密码没有区别。 我会高度不同意这种比较。 一个秘密的URL和一个密码确实有一个相似的特征：它们被一个或多个特定的人/人所了解。 那就是相似性结束的地方。
密码的强度
-
从一系列随机词组中产生密码使得密码非常强大，很难猜测或蛮力 。
-
密码必须与用户名相结合，如果用户名不常见，也可以提高安全性。
-
用户名和密码组合不会静态显示在屏幕上，也不会存储在浏览器的任何位置（除非您select让浏览器“保存”您的login凭据）。
-
在违规情况下可以更改密码，而无需将入口点更改为系统。
-
好的密码系统不会以纯文本的forms将它们存储在文件系统中。
秘密URL的弱点
-
除非在“隐身”，“私人”等模式中使用，否则URL将存储在本地历史logging/caching中。
-
url显示在浏览器窗口中，可以窥探到stream浪的眼睛。
-
如果秘密URL被泄露，您必须更改它并通知使用它的任何人。
-
URL在服务器上以纯文本forms存在，无论是作为真实的目录/文件还是作为重写（然而，重写可能在更高级别下）。
-
麦克·克拉克在回答中提到的其他一切。
它真正涉及到：
-
秘密URL只是通过默默无闻的方式来实践安全。 而已。
-
根据定义，密码可能是模糊的信息，但是在密码周围采取额外的努力，预防措施和保护措施可以增加安全性。 换句话说，密码是分层的，除了默默无闻之外，还通过其他方式来实践安全性。 这反过来使它们成为比简单的模糊URL更好的select。
build议：同时使用“秘密”URL和非常强大的用户名/密码组合。 不要只依赖一个“秘密”的URL。
切勿以默默无闻的方式实践安全措施。
使用“秘密URL”的原因通常是不安全的，不是因为它是“通过默默无闻的安全性”。 在信息理论中，秘密URL与密码或私钥没有区别。 密码和私钥是否被认为是一种不好的做法，因为它们是“通过默默无闻的安全”？ 没有。
那么难以猜测的URL和难以猜测的密码有什么区别呢？
不同之处在于无数的不安全的地方以及URL被存储，显示和传输的方式。 例子：
- 在Web浏览器地址栏，历史logging和caching中*
- 发送给其他网站的HTTP Referer头文件*
- 在Web服务器访问日志*
- 在代理和第7层防火墙访问日志中
- 在数据包转储
- 在网站统计数据stream量报告（如AWStats，谷歌分析）*
HTTPS可以保护其中的一部分，但并非全部（标有*的项目不受使用HTTPS保护）。
在高度控制的环境中，难以猜测的URL可能是安全的。 但是，当使用常见的网页浏览器，网页服务器和网页框架时，除非没有其他选项存在，否则不应该依赖于难以猜测的URL（即使这样你也应该仔细考虑）。
这不安全。
对于HTTPstream量，只要您使用它，您的秘密URL就会被公开。 在没有任何密码保护的情况下，侦听您networkingstream量的窃听者可以看到您发送的URL，然后访问相同的页面。
不好主意，因为：
- 有人可能会透露您的url获得本地访问您的系统/数据库/应用程序
- 有一天，一些pipe理员会公开你的访问日志文件，谷歌会find它们。
- 您将在您的服务器设置中迁移/升级某些内容，并忘记保护/隐藏这些url
我会说，如果你小心他们可以安全。 最大的安全漏洞是人们使用它。 它将被无意地分享或发布到谷歌将索引的地方。 为此devise，并适当使用它 – 就像Google文档“有这个链接的任何人”共享方法一样。
-
使用HTTPS
停止以明文forms发送的URL
如果点击HTTP链接， 不会设置引用标头
-
如果人们通过HTTP访问您的秘密URL，警告他们，立即改变它
-
这不是通过默默无闻的安全 – 这是对这个短语正常使用的误解。
“一个依靠默默无闻的安全系统可能会有理论或实际的安全漏洞，但其所有者或devise者认为这些漏洞是未知的，攻击者不可能find它们。
相比之下，你正在开放实施和devise。
当使用一个长的秘密URL（64个字符任何人？ 2000 – domain_length ？），与一个焦油坑结合使用时，我没有看到这个安全性低于平均密码。
我正打算在一个应用程序中使用它，我觉得人们会重视简单性高于安全性。
Waterkennetworking服务器是由惠普公司的安全人员围绕秘密（特别是密码不可猜测的）URL进行研究而devise的一个networking平台。
构build于其上的应用程序具有一些非常有趣的安全属性。
做得对，密码强的秘密URL可以提供高度的安全性。
ACLs不要从waterken团队的安全架构上发表论文。
将build议的防御与编译场景的基于能力的解决scheme进行比较，再假设一个类似Unix的系统：URL就像文件名; 而不可猜测的标记就像一个文件描述符，逼近了不可测性的能力的不可伪造性。 股票经纪人网站的合法页面首先打开股票购买资源，收到一个不可思议的秘密。 浏览器然后使用这个不可思议的秘密来写入股票购买资源。
那会不知不觉地被第三方发现呢？ 例如，秘密端口可以进行端口扫描和指纹识别，但是对于秘密URL可以采用相同的策略？
是。 你正在考虑作为一个人坐在电脑上inputURL到他们的浏览器的威胁。 实际情况是，攻击者使用在系统上执行侦察的自动化程序，并使用该信息来尝试各种攻击。 尝试使用随机URL对于自动化系统来说花费不大，而不是每秒可以产生数百个HTTP请求。 其次，正如其他人已经指出，一旦你使用的URL不再是秘密。 这些自动化程序监听互联网stream量并收集URL以尝试攻击。 只有你知道URL这个事实意味着没有其他人可以透露它的价值。 这并不妨碍技术手段泄露价值。
这实际上是一个非常合理的想法，如果你使用一个大的，随机生成的url 。 实际上有很多系统已经这样工作了。 例如，在Google文档中，您可以创build一个链接，任何具有该链接的人都可以编辑该文档。 这足够长，你永远无法猜测这个联系。 此外，密码重置链接基本上是这样的，除了（希望）只能使用一次。 （见下文）
你需要确保秘密不泄露。 这意味着使用https，不logging访问，或在其他api调用中返回秘密。
也就是说，正如许多评论者所说，一个URL被存储在你的计算机上的各种不安全的地方，但是如果一个对手有权访问你的计算机，你已经被搞砸了。 假设您的最终用户设备是安全的，这是非常典型的。
而且，任何秘密只是秘密成反比，有多less人知道它。 与其他需要访问的人分享url可能是诱人的。 一个更好的系统可能是让每个URL工作一次，但是添加一个cookie到用户的浏览器，这是实际的令牌。 基本上，就像密码重设stream程/电子邮件确认stream程，除了没有密码。
