秘密 URL 真的安全吗？答案

【问题标题】：Are secret URLs truly secure?秘密 URL 真的安全吗？
【发布时间】：2011-01-28 21:40:03
【问题描述】：

我从来没有在我的系统中留下后门，但出于好奇，我想知道我是否留下了一个像 /x52d23r 这样的秘密 URL，它允许绕过某种安全性，这仅供我个人使用 --- 那会是在没有从我这里得到信息的情况下被第三方以某种方式发现？

例如，可以对秘密端口进行端口扫描和指纹识别，但可以对秘密 URL 执行相同的策略吗？

【问题讨论】：

我很想写一个长答案，但由于时间紧迫，我只想说，听听@Michael Irigoyen。有很多方法可以利用这个方案，有些是聪明的，有些是蛮力的。只是......不要这样做。
URI 用于资源识别，而不用于访问授权。
URL 最终会出现在您的日志文件（谁有权访问它们？）、配置文件中，可能会出现在您的浏览器书签、备份文件等中，然后……您忘记了它们（它们不像密码数据库那样安全相关，是吗？） - 直到有人为您找到它们。
我正在寻找比这个问题或其提供的答案更深入的内容。我提出了一个新问题，[如何在安全性和便利性之间取得最先进的平衡，生成一个“私有 URL”？][新问题]，而不是试图扩大这个问题的范围。 [新问题]：stackoverflow.com/q/12479398/168740
@Gumbo Facebook、Dropbox 和 Google Drive 均提供“任何拥有链接的人”共享权限，数百万人使用该权限在其通讯员之间保密文件。人们普遍认为这是安全的（鉴于网站是 HTTPS。）令人满意的答案应该承认这一点。

标签： security url

【解决方案1】：

使用“秘密 URL”通常是不安全的原因并不是因为它是“通过默默无闻的安全”。在信息论中，秘密 URL 与密码或私钥没有什么不同。密码和私钥是否被认为是一种糟糕的做法，因为它们是“通过默默无闻的安全”？没有。

那么难猜的 URL 和难猜的密码有什么区别呢？

不同之处在于 URL 的存储、显示和传输有无数不安全的地方和方式。例子：

在网络浏览器地址栏、历史记录和缓存中*
发送到其他站点的 HTTP Referer 标头*
在 Web 服务器访问日志中*
在代理和第 7 层防火墙访问日志中
在数据包转储中
在网络统计流量报告中（例如 AWSStats、Google Analytics）*

HTTPS 可以保护其中的一些，但不是全部（标有 * 的项目不受使用 HTTPS 的保护。）

在高度受控的环境中，难以猜测的 URL 可能是安全的。但在使用常见的网络浏览器、网络服务器和网络框架时，不应依赖难以猜测的 URL，除非没有其他选项存在（即使那样你也应该仔细考虑）。

【讨论】：

如果 URL 上有一个 ?token=abc 怎么办？就像 GitHub 在查看私有仓库中的文件时会自动执行的操作一样。
'?' 后面的任何内容被认为是一个参数，与 URL 相关的所有暴露点也适用于参数（包括 HTTP Referer 标头）。

【解决方案2】：

原答案：通过默默无闻的安全是应该永远被实践的东西。

我想对此进行扩展，因为我看到仍然有人提出秘密 URL 与密码没有什么不同的论点。我非常不同意这种比较。一个秘密 URL 和一个密码 do 有一个相似的特征：一个或多个特定的人知道它们。这就是相似性结束的地方。

密码强度

用一系列随机单词makes the password very strong and very hard to guess or brute force制作密码。
密码必须与用户名相结合，如果用户名不常见，这也可以提高安全性。
用户名和密码组合不会静态显示在屏幕上，也不会存储在浏览器的任何位置（除非您选择让浏览器“保存”您的登录凭据）。
可以在发生违规时更改密码，而无需更改系统的入口点。
良好的密码系统不会将它们以纯文本形式存储在文件系统中。

秘密网址的弱点

除非在“隐身”、“私人”等模式下使用，否则 URL 将存储在您的本地历史记录/缓存中。
URL 会显示在浏览器窗口中，并且可能会被迷惑的眼睛看到。
如果秘密 URL 被泄露，您必须更改它并通知任何使用它的人。
URL 以纯文本形式存在于服务器某处，无论是作为真实目录/文件还是作为重写（但是，重写可能会下降到更高的级别）。
@Mike Clark 在his answer 中提到的所有其他内容。

真正归结为：

秘密 URL 只是通过默默无闻来实践安全。就是这样。
根据定义，密码可能是模糊信息，但围绕密码采取的额外努力、预防措施和保护措施在此之上增加了安全级别。换句话说，密码是分层的，并且通过其他方式实现安全性除了模糊性。这反过来又使它们成为比简单的隐藏 URL 更好的选择。

建议：同时使用“秘密”网址和非常强大的用户名/密码组合。不要依赖仅“秘密”网址。

切勿将隐晦作为唯一的保障措施。

【讨论】：

我认为有时这个短语是断章取义的（但在这种情况下不是）。密码是安全的，因为它们是模糊的，与加密密钥一样。如果论文是公开的、清晰的和免费的，那么这些安全工具将毫无价值。如果您可以保证您的资源是模糊的，并且您有一种机制来衡量和响应访问此资源的尝试，那么您的情况与使用用户名/密码没有任何不同。例如，如果在三个错误的 URL 请求后，你将一个 IP 列入黑名单，你就基本实现了密码系统。
在这种情况下，这不是一个好主意。我认为 Michael Irigoyen 对您的问题有正确的答案。
-1 滥用“通过默默无闻的安全”一词。该术语中提到的模糊性是算法的模糊性，而不是强密码、密钥或秘密的模糊性。
所有安全都是通过默默无闻的。 URL 不够隐蔽（与密码相比）
Security Through Obscurity 隐藏了机制或实现细节——这与仅使用密码短语的开放式架构不同。这是一个理论概念，在这里并没有真正的帮助。因此，如果您在网站上声明“存在秘密 URL”，则不是 STO，但如果您不这样做，则可以说是。

【解决方案3】：

我会说，如果你小心的话，它们是安全的。最大的安全漏洞是使用它的人。它会在无意中被共享或发布到 Google 将其编入索引的地方。为此进行设计并适当地使用它 - 就像 Google 文档中的“任何知道此链接的人”共享方法一样。

使用 HTTPS

停止以纯文本形式发送的 URL

Doesn't set referrer headers 如果他们点击 HTTP 链接

如果有人通过 HTTP 访问您的秘密 URL，请警告他们并立即更改它
它是not security through obscurity - 这是对正常用法的误解。

“一个依赖于安全的系统通过默默无闻可能有理论或实际的安全漏洞，但它的所有者或设计师认为缺陷是未知的，而且攻击者不太可能找到它们。”

相比之下，您对实施和设计持开放态度。

当与长秘密 URL（64 个字符？2000 - domain_length?）结合使用 tar-pit 时，我认为这并不比普通密码安全。

我计划在我认为人们更看重简单性而非安全性的应用中使用它。

【讨论】：

【解决方案4】：

它不安全。

对于 HTTP 流量，您的秘密 URL 将在您使用它时有效地公开。如果没有任何密码保护，窃听您的网络流量的窃听者可以看到您发送的 URL，然后访问同一页面。

【讨论】：

在使用 HTTPS 时会被加密。
@Gumbo：是的，这是一个很好的观点 +1。我猜你可以使用 HTTPS 来保护 URL 的秘密，但是恕我直言，这仍然是个坏主意。想象一下，如果您不小心忘记在 https 上输入“s”...哎呀！
首先，他们必须对所有使用的 URL 进行排序，以及人们多久坐在网络上收听您访问的所有 URL。通常他们会寻找某些东西，例如 .gov 链接、HTTP 身份验证传输、POST/GET 数据——对吗？只是扮演魔鬼的拥护者，我同意你的担心。
@Dexter：即使没有人在积极收听，您访问的所有页面的 URL 也可能会记录在多个数据库中。例如，法律要求许多国家/地区的 ISP 记录其客户在线所做的事情，而在那些没有要求的国家/地区，我敢打赌，很多人都会这样做。
另一个非常好的变体：如果页面包含指向外部站点（例如 google.com）的链接，则单击该链接会通过“Referer”发送“秘密”URL标头（直接发给 Google）。

【解决方案5】：

不是好主意，因为：

有人可能会透露您的网址正在获取对您的系统/数据库/应用程序的本地访问权限
有一天，某些管理员会将您的访问日志文件公开，Google 会找到它们。
您将在服务器设置中迁移/升级某些内容，而忘记保护/隐藏这些 url

【讨论】：

我从没想过愚蠢的未来管理员场景。好点子。

【解决方案6】：

Waterken 网络服务器是一个网络平台，由惠普安全专家围绕秘密（特别是加密不可猜测的）URL 进行研究而设计。

因此，基于它构建的应用程序具有一些非常有趣的安全属性。

做得对，加密强度高的秘密 URL 可以提供高级别的安全性。

ACLs Don't 是 waterken 团队关于其安全架构的论文。

将建议的防御与编译场景的基于能力的解决方案进行比较，然后再一次假设一个类 Unix 系统：URL 就像文件名；不可猜测的令牌就像一个文件描述符，用不可猜测性来近似能力的不可伪造性。来自的合法页面券商网站首开购股资源，收到一个无法猜测的秘密。浏览器然后使用这个无法猜测的秘密写入股票购买资源。

【讨论】：

【解决方案7】：

如果您使用随机生成的大 url，这实际上是一个非常合理的想法。有很多系统实际上已经像这样工作了。例如，在 google 文档中，您可以创建一个链接，任何拥有该链接的人都可以编辑该文档。它足够长，以至于您永远无法猜测该链接。此外，密码重置链接基本上就是这样，除了它们（希望）只能使用一次。（见下文）

您需要确保机密不会泄露。这意味着使用 https，而不是记录访问，或在其他 api 调用中返回秘密。

也就是说，正如上述许多评论者所提到的，URL 存储在您计算机上的各种不安全位置，但如果对手可以访问您的计算机，您就已经被搞砸了。假设您的最终用户设备是安全的，这很典型。

此外，任何秘密都只是秘密与知道它的人数成反比。与需要访问权限的其他人共享 URL 可能很诱人。一个更好的系统可能是让每个 URL 工作一次，但在用户的浏览器中添加一个 cookie，这是实际的令牌。基本上，就像密码重置流程/电子邮件确认流程一样，除了没有密码。

【讨论】：

【解决方案8】：

在没有从我这里得到信息的情况下，第三方会以某种方式发现吗？例如，可以对秘密端口进行端口扫描和指纹识别，但可以对秘密 URL 执行相同的策略吗？

是的。您认为威胁是一个人坐在计算机前，将 URL 输入到他们的浏览器中。现实情况是，攻击者使用自动化程序对系统执行侦察并使用该信息尝试各种攻击。对于自动化系统而言，尝试随机 URL 的成本比每秒产生数百个 HTTP 请求的成本低。其次，正如其他人所指出的，一旦您使用 URL，它就不再是秘密。这些自动化程序侦听互联网流量并收集 URL 以尝试攻击。只有您知道 URL 的事实意味着没有其他人可以泄露它的价值。不妨碍技术手段泄露价值。

【讨论】：

您建议使用蛮力，如果 URL 足够长，这显然行不通。这就是为什么即使你聚集了十亿台计算机，每台计算机每纳秒可以尝试十亿次，你也无法暴力破解足够长的密码。

【解决方案9】：

猜测对应于 16 个字节的 ascii 十六进制字符串提出了猜测 128 位 AES 密钥的挑战 - 这被认为是不可能的。

【讨论】：