信息安全 - 使用晦涩的 URL 来确保安全 - 吾爱随笔录

我的托管服务提供商提供通过 Web 界面管理的基础架构即服务 (IaaS) 产品，管理员可以在其中创建和销毁虚拟机。

要访问基于 Web 的管理门户，我需要登录到托管服务提供商的“服务台”（通过 HTTPS 的用户名和密码），然后单击生成的链接以访问 IaaS 管理门户（也是 HTTPS）。

该链接本身很可能是不可猜测的（它包括看起来像 md5 哈希和 2 个 GUID），但任何有权访问该 URL 的人都可以在几个小时内不受限制地访问 IaaS 门户（该链接似乎在那之后过期）。

我已经测试通过链接访问不限于我的特定 IP 地址。

简而言之，任何拥有该链接的人都可以删除所有虚拟机和我客户的数据，前提是他们可以在生成后的几个小时内访问它。

这对于 IaaS 门户之类的安全性是否不足（我的直觉说不）？我可以向托管服务提供商提出哪些具体问题？

编辑：我知道这个问题类似于Is include a secret GUID in an URL Security Through Obscurity? ，但这个问题与低级 HTTP 客户端有关，而不是浏览器，这会引入额外的问题，例如 URL 泄漏、浏览器历史记录、缓存等。

秘密 URL 的问题在于它们可以通过多种方式泄露。

图片、Javascript、样式表和字体可能会泄露您正在访问的网页的 URL。例如，如果您的机密页面包含类似的内容，<img src="http://example.com" />那么当您的浏览器抓取图像时，它可能会在 Referer 标头中包含机密页面的 URL。有一些用例（https 到 http 流量，或浏览器覆盖）会阻止浏览器发送标头，但通常，这是泄露您的秘密 URL 的常见方式。

虽然您可以在加载页面时查看自己的网络流量（使用 Chrome 或 Firefox 中的“网络配置文件”功能）以查看 URL 是否泄露，但主要担心的是页面中的任何更改都可能导致泄露。

泄露秘密 URL 的两个备受瞩目的案例包括Google Docs和Dropbox。

这对于 IaaS 门户之类的安全性是否不足？

正如我上面提到的，您可以使用浏览器的网络配置文件功能来测试页面是否泄漏了 URL。然而，最大的担忧是这个系统的脆弱性。与密码之类的东西不同，用户无法控制网页实现，并且在样式表中意外包含外部资源太容易了。这并不是说系统不安全，只是说它有点脆弱。

如果我使用的是 IaaS 门户，我会要求它们在容易泄露的 URL 之外包含额外的访问控制机制。