1

首先，从幼稚的角度提出问题：

我有一个 Web 应用程序，其中包含一个产品的 URL，例如Products?id=123. 假设我有一个可以从Products?id=123&editable=true.

如果我认为没有人会尝试启用该editable参数，因此不需要任何进一步的安全机制来保护此页面，那就是obscurity 的安全性，这不是一个好主意，对吧？

-

在我的真实案例问题中，它稍微有点微妙：允许任何人知道我的管理 URL 是否有任何危险？例如，在使用 XSL 时，我想写：

<xsl:if test="/webAlbums/mode/@admin">
    (compute edit link)
</xsl:if>

但是对于潜在的攻击者来说，在“重要”页面中发现弱点不是更容易吗？

4

4 回答 4

1

默默无闻的安全根本算不上安全。不要指望它。

您应该建立一个身份验证系统，以防止人们通过实际安全性使用管理页面。

至于知道您的管理 URL 的人，只要您的管理页面受到保护并且 URL 中没有显示敏感数据（例如数据类型的内部表示、某些数据的内部 ID 等）就可以了）。

于 2010-10-24T07:13:35.593 回答
1

Daniel Miessler 在他的博客中给出了另一个回应元素，这是我在写这个问题时想到的，但无法表述：

  • 作为一个层的隐蔽性使得已经具有良好防御的系统更难成为目标，从而改善了其整体安全状况。
  • Security Through Obscurity意味着一旦成为目标，系统将毫无防御能力，即它的所有安全性都来自于保密。

隐藏未经身份验证的客户端的配置 URL在标准身份验证机制之上增加了一层安全性。

如果饼干不知道门在哪里，他们将不太可能尝试强迫它！

这就是他所做的，将其 SSHd端口更改为 24，端口扫描器将定位 SSH 服务器，但自动暴力脚本只会尝试默认的。

结果？一个周末后， 22 端口和 24 端口5攻击了18,000 次（他让两个端口都打开以允许比较）。

于 2014-11-20T08:36:58.360 回答
0

您实际上很幸运，因为您提出的实际上不是通过默默无闻的安全性，而是实际上是一种非常完善的安全技术，称为 Obscure URL。

要使其正常工作，您需要确保 URL 的一部分与强密码一样难以猜测。将它包含在哪里并不重要，只要页面不能被编辑，除非该部分是正确的。

不安全的例子：

Products?id=123&editable=true

安全示例：

Products?id=123&editable=true&edit-token=GgSkJSb6pvNT
Products?id=123&edit=GgSkJSb6pvNT
edit/GgSkJSb6pvNT/Products?id=123
GgSkJSb6pvNT/Products?id=123
于 2013-03-13T16:18:08.740 回答
0

我不做网络编程，所以我在这里可能有点离谱，但我认为有几件事需要考虑：

  • 就像任何其他身份验证系统一样，如果您在没有 HTTPS 的情况下访问管理页面，则页面请求（包含有效的“密码”）将以明文形式发送。

  • 除非另有配置，否则浏览器将保留管理页面的历史记录和缓存。这使得秘密 URL 更容易被攻击者甚至任何使用您的机器的人使用。

  • 与所有密码一样，如果秘密 URL 足够简单，那么它就有可能被暴力破解。像这样的东西&editable=true并没有让我觉得安全。

但如果处理得当，这应该与传统的身份验证系统一样安全。

于 2013-03-13T16:40:56.303 回答