隐蔽性安全：URL 怎么样？
首先，从天真的角度来看这个问题：
我有一个 Web 应用程序，其中包含一个产品的 URL，例如 Products?id=123。假设我有一个可从 Products?id=123&editable=true 访问的管理页面。
如果我认为没有人会尝试启用 editable 参数，因此不需要任何进一步的安全机制来保护此页面，这就是模糊安全，并且这不是一个好主意，对吧？
-
在我的实际案例中，问题稍微微妙一些：允许任何人知道我的管理 URL 是否有任何危险？例如，在使用 XSL 时，我想写：
<xsl:if test="/webAlbums/mode/@admin">
(compute edit link)
</xsl:if>
但是对于潜在的攻击者来说，找到“重要”页面中的弱点不是更容易吗？
first of all, the question from a naive point of view:
I've got a WebApplication with a URL to a product like Products?id=123. Let's say I've got an administration page reachable from Products?id=123&editable=true.
If I consider that no one will ever try to enable the editable parameter, and thus don't need any further security mechanism to protect this page, that's security by obscurity, and that's not a good idea, right?
-
In my real case problem, it's slightly more subtle: is there any danger in allowing anyone to know my administration URLS? for instance, while working with XSL, I would like to write:
<xsl:if test="/webAlbums/mode/@admin">
(compute edit link)
</xsl:if>
but wouldn't it be easier for a potential attacker to find a weakness in 'important' pages?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
通过默默无闻实现的安全根本就不是安全。不要指望它。
您应该建立一个身份验证系统，通过实际的安全性来防止人们使用管理页面。
至于知道您的管理 URL 的人，只要您的管理页面受到保护并且 URL 中没有显示敏感数据（例如数据类型的内部表示、某些数据的内部 ID 等）就应该没问题。 ）。
Security through obscurity is barely security at all. Don't count on it.
You should make an authentication system that prevents people from using the admin page through actual security.
As for people knowing your admin URLs, it should be fine as long as your admin page is protected and there is no sensitive data being shown in the URL (such as the internal representation of a data type, the internal ID of some data, etc).
Daniel Miessler 在他的博客中给出了回应的另一个要素，这也是我在写问题时想到的但无法制定：
对未经身份验证的客户端隐藏配置 URL 在标准身份验证机制之上添加了一层安全性。
如果黑客不知道门在哪里，他们就不太可能尝试强行打开它！
这就是他通过改变所做的事情将 SSHd 端口设置为 24，端口扫描器将找到 SSH 服务器，但自动暴力破解脚本只会尝试默认端口。
结果？一个周末后，端口 22 上发生了 18,000 次攻击，端口 24 上发生了 5 次攻击（他打开了这两个端口以进行比较）。
Daniel Miessler gives another element of response in his blog, the one I had in mind when I wrote the question but couldn't formulate:
Hiding configuration URLs from unauthenticated clients adds a layer of security, on top of standard authentication mechanisms.
If crackers don't know where the door is, they will be less likely to try to force it!
That's what he does by changing its SSHd port to 24, port scanner will locate the SSH server, but automatic brute-force scripts will only try the default one.
Results? after a weekend, 18,000 attacks on port 22 and 5 on port 24 (he let both ports open to permit the comparison).
你实际上很幸运，因为你提出的实际上不是隐匿性安全，而是一种名为 Obscure URL 的完美安全技术。
为了使其发挥作用，您需要确保 URL 的一部分像强密码一样难以猜测。只要页面无法编辑（除非该部分正确），将其包含在何处并不重要。
不安全示例：
安全示例：
You are actually in luck, as what you are proposing is actually not security by obscurity, but actually a perfectly sound security technique called Obscure URL.
To make it work, you need to make sure a part of the URL is as hard to guess as a strong password. It doesn't really matter where you include it, as long as the page cannot be edited unless that part is correct.
Insecure example:
Secure examples:
我不做网络编程，所以我在这里可能有点离谱，但我认为有一些事情需要考虑：
就像任何其他身份验证系统一样，如果您在没有 HTTPS 的情况下访问管理页面，页面请求（包含有效的“密码”）以明文形式发送。
除非进行其他配置，否则浏览器将保留管理页面的历史记录和缓存。这使得攻击者甚至使用您计算机的任何人都更容易使用秘密 URL。
与所有密码一样，如果秘密 URL 足够简单，则很可能会被暴力破解。像
&editable=true这样的东西在我看来并不安全。但如果处理得当，这应该和传统的身份验证系统一样安全。
I don't do web programming, so I may be a bit off-base here, but I think there are a few things to consider:
Just like any other authentication system, if you access the admin page without HTTPS, the page request (which contains the effective "password") is being sent in the clear.
Unless configured to do otherwise, browsers will retain history and cache for the the admin page. This makes the secret URL more available to attackers or even anyone who uses your machine.
As with all passwords, if the secret URL is simple enough, there is a reasonable possibility that it could be brute forced. Something like
&editable=truedoesn't strike me as secure.But if handled properly, this should be just as secure as a conventional authentication system.