在一个不起眼的目录中发布的网站是否与被放置在登录名后面相当安全?

信息安全 验证 朦胧 网站 秘密分享
2021-08-15 14:11:39

假设我为包含机密商业信息的客户创建了一个微型网站。我们需要将其放置在客户可以访问的位置,以便他们批准发布。

如果我们将此微型网站置于登录后,我们保证没有人可以偶然发现内容并对其进行破坏。但是,如果我们将其发布到一个未公开的、未编制索引的目录,其名称与上述密码的“强度”相同,该怎么办?为了争论,“未公开和未索引”意味着它不会被手动或自动链接到/从任何地方,或被同一域上的任何网站搜索索引。它也不会放在它自己的子域中,因此 DNS 抓取不是问题。

我最初的直觉认为这只是默默无闻的安全性,并且由于有人可能会绊倒它,因此安全性要低得多。但是,仔细想想,我不太确定。以下是我的理解:

  • 即使对密码和 URL 都使用字典弱的双字字符串,仍然有数十亿个可猜测的选项。将它放在 URL 中并不会神奇地减少该列表。
  • 登录页面可以具有蛮力保护,因此攻击者可以乐观地进行 20 次猜测尝试。URL 猜测必须被服务器的 DoS 或垃圾邮件保护捕获,并且如果您预计会发生攻击,则可能允许产生 200 404 次猜测 - 对于数十亿选项仍然没有统计意义。
  • 登录页面是从网站链接的——它是攻击者可以攻击的可见墙。这是证据表明存在值得攻击的东西。然而,猜测 URL 是盲目的。它需要在正确的域(和子域)上,并且相信即使经过数以万计的错误猜测,你仍然会发现一些东西。
  • URL 更容易被外部索引/爬取。然而,大多数受人尊敬的蜘蛛不会“猜测”网站,它们只是跟随链接。恶意“猜测”蜘蛛将被与第 2 点相同的 DoS/垃圾邮件保护捕获。

据我所知,两者之间唯一有意义的区别是想象中的安心。URL 可能被绊倒的可能性让人感到紧张,而登录让事情变得安全,尽管根据上述几点它们看起来是可比的。不过,URL 选项仍然感觉应该不那么安全。我没有考虑什么?


编辑:出现了很多有效的人为错误问题。这个问题的灵感来自于一个客户端,该客户端实现了一定程度的防人安全 - 通过密钥卡、屏幕调光器、5 分钟睡眠超时、社交媒体停电等进行 vpn 登录。对于这个问题,请假设没有公共网络访问权限,也没有偶然的违规行为喜欢看肩膀或“哎呀!我发布了推特的链接!”。我正在寻找一个更系统的答案,或者至少比“人类搞砸”更令人满意的答案。


编辑 2:感谢您指出可能的重复. 恕我直言,我认为每个问题都有其价值。该问题专门解决了图像安全问题,并深入研究了保护和编码该数据的替代方法(例如 base64 编码)。这个问题更具体地解决了保密与默默无闻的概念,并将其应用于为什么登录优于独立于所讨论数据类型的 URI。此外,我认为那里接受的答案并没有像@SteveDL 下面的精彩答案那样深入或彻底地解释我的特定问题。

4个回答

我将在一个稍微抽象一点的层面上扩展一点,说明为什么经过身份验证的公共空间比隐藏的未受保护空间更可取。其他答案都非常好,并列出了应该更好地避免的多种攻击。

每个受过正规培训的人都应该听说过开放设计安全原则它指出,系统不得依赖其设计和实现的细节对其功能保密。这告诉我们关于秘密密码和秘密 URL 的什么信息?

密码是身份验证机密。它们为被挑战实体所知,该实体将它们提供给挑战实体以进行身份​​验证。双方都需要一种存储形式和一个通信渠道。窃取密码需要妥协三者中的任何一个。通常:

  1. 用户必须被困或被迫泄露密码
  2. 服务器必须被黑客入侵,才能显示密码的散列版本
  3. 用户和服务器之间的通道的机密性必须受到损害

请注意,有很多方法可以加强身份验证,首先是添加具有不同存储要求和传输通道的附加身份验证因素,因此具有不同的攻击通道(权限分离原则)。

我们已经可以得出结论,晦涩的 URL 不能比密码更好,因为在密码的所有攻击向量中,URL 要么是已知的(2 和 3),要么是可获取的(1)。

另一方面,晦涩的 URL被更普遍地操纵。这在很大程度上是由于 Internet 生态系统中的多个自动和手动实体定期处理 URL 的事实。URL 的保密性依赖于它被隐藏在视线中,这意味着它必须由所有这些第三方处理,就好像它是公开的、已知的商品一样,将它暴露在所有人的眼前。这会导致多个问题:

  • 可以存储、传输和复制这些晦涩的 URL 的向量要多得多
  • 传输通道不需要保密
  • 存储空间不需要保密或完整性保护,或监控数据泄漏
  • 复制的 URL 的生命周期基本上不受原始客户端和服务器主体的控制

简而言之,当您需要公开处理秘密时,所有控制的可能性都会立即消失。仅当第三方无法理解某件事时,您才应该将某件事隐藏在显而易见的地方。以 URL 为例,该 URL 只有在可以理解的情况下才能在整个 Internet 生态系统(包括您的客户端的浏览器、各种 DNS 服务器和您自己的 Web 服务器)中起作用,因此必须以某种格式保存您的对手可以使用它来寻址您的服务器。

总之,尊重开放式设计原则。

由于我们是在理论上讨论,以下是仅凭随机 URL 不足以保护机密数据的几个原因:

  • URL 可以加书签。
  • URL 记录在浏览器历史记录中(公共信息亭)。
  • URL 显示在地址栏中(肩部冲浪者)。
  • 记录 URL(想想 3rd 方代理)。
  • URL 可以通过 Referrer 标头泄露

我不清楚你的一些要点。

你是说这个潜在的网络服务器/网站/平台确实有目录模糊保护,还是这是假设的?

即便如此,它也不能防止我上面提到的项目。

然而,猜测 URL 是盲目的。它需要位于正确的域(和子域)上

然而,大多数受人尊敬的蜘蛛不会“猜测”网站,它们只是跟随链接'

认为主要搜索引擎不值得尊敬是一个合理的立场,但这并没有改变他们所做的不仅仅是跟随链接的事实。特别是,搜索引擎可以并且确实枚举了 DNS 条目,因此仅存在子域就是一种风险。

尽管人们发誓他们从未从任何地方链接到它,而且 Google 也不会返回任何链接到该网站的页面,但很多东西最终都会出现在 Google 上。

除此之外,人们通常不会将 URL 视为机密,并且 URL 会出现在服务器、浏览器和代理日志等各种地方。与密码相比,URL 对更多的浏览器扩展也是可见的,并被更多的浏览器扩展使用。如果“隐藏”站点有传出链接,则 URL 很可能出现在Referer:标题中。

还有一个风险是,由于配置错误,指向隐藏站点的链接会出现在非隐藏位置,例如,如果隐藏站点托管在提供本地搜索工具的站点上。

登录页面是从网站链接的——它是攻击者可以攻击的可见墙。这是证据表明存在值得攻击的东西。

那没有意义。使用像样的软件和随机生成的密码,没有值得追求的攻击面。相比之下,隐藏目录甚至看起来都不值得攻击,它看起来像是对公众开放的东西。

秘密 URL 尤其容易受到风险,因为如果 URL 意外泄露并且搜索引擎发现它,整个网站内容将通过该搜索引擎暴露。密码不会像灾难性那样失败:如果密码泄露,仍然需要有人自愿采取行动才能开始下载数据,它不会自动启动一个将其发布给所有人看的机器。

我同意其他答案,即这是一个坏主意,仅仅是因为人们(=> 开发人员 => 记录信息的应用程序)不认为 URL 是私有的,因此有很多不同的方式可能会泄露密钥。然而,您正确认识到的是,密码本质上是一种通过默默无闻的安全形式。从概念上讲,您提出的方案没有任何问题。唯一的问题是由于您提出的方案是以非预期方式滥用系统这一事实。

即使对密码和 URL 都使用字典弱的双字字符串,仍然有数十亿个可猜测的选项。将它放在 URL 中并不会神奇地减少该列表。

没错,但它也不会使它更安全。

登录页面可以具有蛮力保护,因此攻击者可以乐观地进行 20 次猜测尝试。URL 猜测必须被服务器的 DoS 或垃圾邮件保护捕获,并且如果您预计会发生攻击,则可能允许产生 200 404 次猜测 - 对于数十亿选项仍然没有统计意义。

如果您预计会受到攻击,您可能会将其限制为针对您的应用程序类型的蛮力保护的最佳实践。所以确实,如果做得好,它不会更糟,但它肯定不会更好,而且可能会更糟,因为你将不得不做更多的定制工作。

登录页面是从网站链接的——它是攻击者可以攻击的可见墙。这是证据表明存在值得攻击的东西。然而,猜测 URL 是盲目的。它需要在正确的域(和子域)上,并且相信即使经过数以万计的错误猜测,你仍然会发现一些东西。

绝对正确,出于这个原因,我看到一些公司将他们的 Intranet 登录页面隐藏在稍微不可预测的 URL 上。有什么可以依靠的吗?当然不。是否可以阻止某些低调的攻击者?确实。

然而,无论哪种方式,与第一段中描述的大权衡相比,这仅提供有限的好处。

URL 更容易被外部索引/爬取。然而,大多数受人尊敬的蜘蛛不会“猜测”网站,它们只是跟随链接。恶意“猜测”蜘蛛将被与第 2 点相同的 DoS/垃圾邮件保护捕获。

蜘蛛的唯一问题是它们可能会在链接 URL 的某个地方找到一个随机缓存,并以一种更容易被其他人找到的方式对其进行索引。随机猜测确实不是问题。