URL安全性 - 什么被认为是一个安全且难以猜测的URL？

Question

我正在考虑我的当前网络项目的URL。用户可以通过网站访问不同的资源，如图像。URL看起来像这样：http://localhost:2143/p/AyuducjPnfnjZGfnNdpAIumehLiWaYQKbZLMeACUqgsYJfsqarTnDMRbwkIxWuDd。

现在，我真的需要高性能，一种方法是省略对数据库的身份验证的额外往返，并仅依赖于URL无法猜测。

谷歌使用Picasa Web相册实现此功能，您可以将相册设为私有或未列出。这样可以保护相册但不能保护照片本身。以丹麦斯卡恩（Skagen）的这张照片为例; http://lh4.ggpht.com/_Um1gIFfF614/TQpVMvN3hPI/AAAAAAAANRs/GY5DxrDPHUE/s800/IMG_4074.JPG，它实际上在一个私人相册中，但是您们都可以看到它。

那么你对此有什么看法？64个字符长的随机字符串足够“安全”吗？还有其他方法吗？

---

假设我选择为每个资源请求进行身份验证。用户已登录到somedomain.com上的网站，在那里他们访问他们的照片相册。放置了一个cookie来维护他们的身份验证。

现在，实际的照片是通过完全不同的URL提供的某种形式的CDN或存储服务提供的。

如何在多个域之间维护身份验证？假设两个相册的内容可以从两个不同的服务器交付。

- Christian Sparre

---

以下评论来自Martona： - Marc Gravell

如果存储服务可以与进行身份验证的 Web 服务器访问同一个数据库服务器，那就很简单了。一种方法是在身份验证后在 Web 服务器上生成一个单次使用的令牌（例如 64 个字符），并将其放入数据库中。然后，您将用户重定向到包含令牌的 URL 的存储服务器。存储服务器在数据库中查找该令牌，如果检查通过，则在浏览器上删除其自己的会话 cookie。存储服务器可以通过 Web 服务器公开的 Web 服务访问数据库。无需直接连接。 - Marc Gravell

Answer 1

做个简单的数学计算。从62种可能的值（26个大写字母、26个小写字母和10个数字）中，以密码学方式随机选择64个字符（不能使用rand()函数！），将得到5.16e+114种可能的值（62^64）。即使每秒尝试一百万种组合，也需要1.63e+101年（比谷歌还多）才能猜出密码。这应该足够安全了。一个长度较短的密码也可能足够安全。

- martona

---

正如Stefan H在他的回答中指出的那样...各有所好。这个URL本身相当难以猜测。但它是一个在浏览器地址栏中显示、保存在历史记录中等等的URL。因此，这真的取决于你想做什么。 - martona

Answer 2

64个字符*每个6位熵（Base-64编码，对吗？）等于384位密钥。如果该密钥可以离线测试，则按今天的标准，它将被认为相当薄弱。只要该密钥只能使用您的实时系统进行测试，它可能非常有效，并且您还可以添加主动对策来阻止试图使用多个错误密钥的客户端。

通过服务器日志、浏览器日志、引用程序标头、透明代理等，您很可能面临密钥公开的更高风险。

- Ben Voigt

---

384 位元組對於密鑰（本質上）而言，並不是「相當薄弱」。相反地，它比你所需要的要更強大。一個 384 位元組的 RSA 密鑰確實非常薄弱，但那不是 384 位元組的純隨機性... 相距甚遠。您關於其他方面的觀點是正確的。 - martona

@martona：是的，我认为你说得对。即使是硬件加速器的集群，也可能无法每秒处理2^60个组合（如果有离线测试的话，而且不应该有）。猜测并不是一种需要担心的攻击方式。 - Ben Voigt

Answer 3

只使用“无法猜测”的URL肯定存在风险，这取决于您要保护的内容类型。以Picasa为例，它们保护的是照片而不是银行记录，因此随机查询字符串就足够了。此外，您的网站规模越大，攻击面也会越大。如果只有一个页面，那么需要扫描很长时间才能找到正在使用的单个URL。但是，如果像这样有成千上万个页面，攻击者更有可能“猜中”正确的页面。

所以，我没有确切的答案，只是对“无法猜测”的URL方法提出一些建议：不要这样做，这不安全。

祝好！

- Stefan H

Answer 4

不存在无法猜测的URL，即使有，第一次在非SSL连接上使用时也可以被任何想要的人、ISP、代理、缓存等看到。您真的希望用户/客户将他们的私人照片交给“无法猜测性”吗？

除非您的唯一URL具有有限的有效期（例如，它们是短暂的URL），否则使URL不可猜测并不是一个很好的安全方法。

- Martin Peck

Answer 5

这是我的意见。我曾经遇到过类似的问题。我们最初的方法是将文件重命名为随机但唯一的名称，并使用复杂的密钥进行双向加密。但最终问题归结为一旦URL落入某人手中，就无法保证内容的隐私性。最终，我们采用了基于数据库的身份验证路线。请参见此处。

编辑#1： 关于CDN问题，我不确定解决方案是什么。但即使martona所说的正确，CDN的目的之一是减轻主服务器的负载，每个资源都返回服务器可能不是一个好主意。

- Nishant