URL安全性 - 什么被认为是安全的无法访问的URL？

Question

我只是考虑当前网络项目的网址。用户可以访问不同的资源，例如使用网站的图像。网址看起来像http://localhost:2143/p/AyuducjPnfnjZGfnNdpAIumehLiWaYQKbZLMeACUqgsYJfsqarTnDMRbwkIxWuDd

现在，我真的需要高性能，一种方法可能是省略数据库的额外往返以进行身份​​验证，只需依赖URL即可。

Google使用Picasa Web Albums执行此操作，您可以将相册设为私有或不公开。这可以保护相册，但不能保护照片本身。拍摄斯卡恩（丹麦）的这张照片; http://lh4.ggpht.com/_Um1gIFfF614/TQpVMvN3hPI/AAAAAAAANRs/GY5DxrDPHUE/s800/IMG_4074.JPG，它实际上是在私人相册中，但你们都可以看到它。

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

---

假设我选择对每个资源请求进行身份验证。用户已经登录somedomain.com上的网站，他们在那里访问他们，比如说相册。删除cookie以保持其身份验证。

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

您如何跨多个域维护身份验证？假设两张专辑的内容可以从不同的服务器发送。

Answer 1

算一算。从62个可能值（26 + 26 + 10：大写/小写/数字）的字母表中加密选择的64个字符（NOT rand（）！）将产生5.16e + 114个可能的值（62 ^ 64）。每秒尝试一百万次组合，猜测代码需要1.63e + 101年（比googol咆哮）。这可能足够好了。较短的一个也可能很不错。

Answer 2

没有不可取的URL这样的东西，即使你第一次在非SSL连接上使用它，任何想要通过ISP和代理，缓存等的人都可以看到它。

使URL不可取是一种很好的安全方法。

Answer 3

64个字符*每个6位熵（Base-64编码，对吗？）是384位密钥。如果可以离线测试密钥，那么按今天的标准来看，这将被认为是相当薄弱的。只要密钥只能使用您的实时系统进行测试，它可能会非常有效，您还可以添加有效的对策来阻止尝试许多坏密钥的客户端。

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

Answer 4

仅使用“不可取”的网址肯定存在风险。这实际上取决于你想要保护的东西。拍摄picasa，它们是受保护的照片，而不是银行记录，因此随机查询字符串很好。此外，您的网站越大，您将打开更大的攻击面。如果只有一个页面，可能需要进行一些扫描才能尝试找出正在使用的单个URL，这是一回事。但如果你有数十万这样的网页，那么攻击者就更有可能“猜测”正确的网页。

所以，我真的没有给你一个答案，只是对“不可取”的网址方法提出了一些建议：不要这样做。这不安全。

干杯，

Answer 5

这是我的2美分。我有类似的问题。我们的初始方法是使用随机但唯一的名称重命名文件，并使用该名称的复杂密钥进行双向加密。但事情最终归结为这样一个事实，即一旦某个URL出现在某人手中，就无法保证这些东西的隐私。我们最终归结为基于数据库的身份验证路由。见here

编辑＃1： 在CDN问题上，我不确定解决方案是什么。但即使martona所说的是正确的。 CDN的目的之一是减少主服务器的负载，并且为每个资源ping回服务器可能不是一个好主意。