URL 安全 - 什么被认为是安全且不可猜测的 URL？
我只是在想我当前网络项目的 URL。用户可以访问不同的资源，例如使用网站的图像。 URL 看起来像这样 http://localhost:2143/p/AyuducjPnfnjZGfnNdpAIumehLiWaYQKbZLMe ACUqgsYJfsqarTnDMRbwkIxWuDd
现在，我真的需要高性能，一种方法可能是省略用于身份验证的数据库的额外往返，而仅依赖 URL 不可猜测。
Google 通过 Picasa 网络相册来实现此目的，您可以将相册设置为私有或不公开。这可以保护相册，但不能保护照片本身。拍摄这张斯卡恩（丹麦）的照片； http://lh4.ggpht.com/_Um1gIFfF614/TQpVMvN3hPI/AAAAAAAAANRs /GY5DxrDPHUE/s800/IMG_4074.JPG，它实际上在私人相册中，但你们都可以看到它。
那么您对此有何看法？ 64 个字符长的随机字符串是否足够“安全”？还有其他方法吗？
假设我选择对每个资源请求进行身份验证。用户已登录到 somedomain.com 网站，他们可以在其中访问他们的相册。删除 cookie 以维持其身份验证。
现在，实际照片通过某种形式的 CDN 或存储服务在完全不同的 URL 上提供。
您将如何跨多个域维护身份验证？假设两个专辑的内容可以从不同的服务器传送。
I was just thinking about the URLs of my current web project. The user can access different resources, like images using a web site. The URLs look something like this http://localhost:2143/p/AyuducjPnfnjZGfnNdpAIumehLiWaYQKbZLMeACUqgsYJfsqarTnDMRbwkIxWuDd
Now, I really need high performance, and one way could be to omit the extra round trip to the database for authentication and just rely on the URL to be unguessable.
Google does this with Picasa Web Albums, you can make an album private or unlisted. This secures the album but not the photo itself. Take this photo of Skagen (Denmark); http://lh4.ggpht.com/_Um1gIFfF614/TQpVMvN3hPI/AAAAAAAANRs/GY5DxrDPHUE/s800/IMG_4074.JPG, it's actually in a private album, but you can all see it.
So what is your take on this? Is a 64 character long random string "secure" enough? Are there other approaches?
Let's say I choose to do authentication for each request to the resources. The users have logged in to the site on somedomain.com, where they access their, let's say photo albums. A cookie is dropped to maintain their authentication.
Now the actual photos are served through some form of CDN or storage service on a completely different URL.
How would you maintain authentication across multiple domains? Let's say the content of two albums could be delivered from to different servers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
算一下。从 62 个可能值（26+26+10：大写/小写/数字）的字母表中以加密方式随机选择的 64 个字符（不是 rand()！）将产生 5.16e+114 个可能值（62^64）。每秒尝试一百万个组合，需要 1.63e+101 年（比古戈尔还多）才能猜出代码。这可能已经足够好了。短一点的可能也不错。
Do the math. 64 characters chosen cryptographically randomly (NOT rand()!) from the alphabet of 62 possible values (26+26+10: caps/lowercase/numbers) will yield 5.16e+114 possible values (62^64). Trying a million combinations a second, it would take 1.63e+101 years (moar than a googol) to guess the code. It's probably good enough. A shorter one is probably pretty good too.
64 个字符 * 每个 6 位熵（Base-64 编码，对吗？）是一个 384 位密钥。如果密钥可以离线测试，那么按照今天的标准，这将被认为是相当弱的。只要密钥只能使用您的实时系统进行测试，它可能会非常有效，您还可以添加主动对策来阻止尝试许多错误密钥的客户端。
您可能面临更高的密钥通过服务器日志、浏览器日志、引用标头、透明代理等公开的风险。
64 characters * 6 bits of entropy each (Base-64 encoding, right?) is a 384-bit key. That would be considered quite weak by today's standards, if the key can be tested off-line. As long as the key can only be tested using your live system, it will probably be quite effective and you can also add active countermeasures to block clients that try many bad keys.
You're probably at much higher risk of the keys becoming public through server logs, browser logs, referrer headers, transparent proxies, etc.
仅使用“不可猜测”的 URL 肯定存在风险。这实际上取决于您想要保护什么类型的东西。以 picasa 为例，它们是受保护的照片，而不是银行记录，因此随机查询字符串就可以了。另外，您的网站越大，您将面临的攻击面就越大。如果只有一个页面，则可能需要进行大量扫描才能尝试找出正在使用的单个 URL，这是一回事。但是，如果您有数十万个这样的页面，那么攻击者更有可能“猜测”正确的页面。
所以，我并没有真正给你答案，只是对“不可猜测”的 url 方法的一些建议：不要这样做。这不安全。
干杯，
There is definitely a risk to only using an "unguessable" URL. It really depends on what sort of stuff you are trying to secure. Take picasa, they are photos that are being secured, not bank records, therefore a random query string is fine. Plus, the larger your website gets the larger attack surface you will open up. It is one thing if there is only one page, that could take a fair bit of scanning to try and figure out what single URL is in use. But if you have hundreds of thousands of pages like that, then attackers are far more likely to "guess" the right page.
So, I don't really have an answer for you, just some advice on the "unguessable" url approach: don't do it. It's not secure.
Cheers,
这是我的 2 美分。我有类似的问题。我们最初的方法是使用随机但唯一的名称重命名文件，并使用该名称的复杂密钥进行双向加密。但事情最终归结为这样一个事实：一旦 URL 落入某人手中，你就无法保证该内容的隐私。我们最终采用了基于数据库的身份验证路线。请参阅此处
编辑#1：
关于CDN问题，我不确定解决方案是什么。但即使 martona 所说的是正确的。 CDN 的目的之一是减少主服务器的负载，并且为每个资源 ping 回服务器可能不是一个好主意。
Here is my 2-cent. I had similar problem. Our intial approach was to rename the file with random but unique name and do a two way encryption with a complex key for that name. But the things eventually boiled down to the fact that once a URL is in someone's hand, you can't guarantee the stuff's privacy. We eventually went down to DB based authentication route. See here
Edit#1:
On CDN issue, I am not sure what the solution would be. But even if what martona is saying is correct. One of the purposes of CDN is to reduce load from your main servers, and pinging back to server for each resource is probably not a good idea.
不存在无法猜测的 URL，即使您第一次通过非 SSL 连接使用它，任何想要的人都可以通过 ISP、代理、缓存等看到它。您真的吗？希望您的用户/客户相信他们的私人照片“不可猜测”？
让 URL 变得不可猜测并不是一个很好的安全方法，除非您的唯一 URL 的有用性有时间限制（例如，它们是短暂的 URL）
There's no such thing as an unguessable URL, and even if there were the very first time you used it over a non-SSL connection it could be seen by anyone who wanted to, by ISPs and by proxies, caches, etc. Do you really want your users/customers to trust their private photos to "unguessability"?
Making URLs unguessable isn't a great approach to security, unless your unique URLs have a time limit on their usefulness (e.g. they're short-lived URLs)