如何降低MongoDB ObjectID的可猜测性？

Question

MongoDB ObjectIDs are guessable.

我正在运行一个位于

的公共资源的应用程序

http://application.com/resource/**ObjectID**

这些资源需要公开访问（不在登录后面），但我正在努力减少黑客强行使用ObjectID并随意抓取它们的机会。

我的想法是在每个MongoDB文档中包含一个随机生成的密钥，以便在发出请求时可以匹配它。例如：

http://application.com/resource/**ObjectID**/**Key** http://application.com/resource/**ObjectID**?key=**Key**

甚至

http://**Key**.application.com/resource/**ObjectID**

如果密钥与文档中存储的密钥不匹配，则服务器将返回404。

我意识到这不是保护隐私意义上的真正保护，因为如果中间有人嗅探网址，他们就可以访问资源。我只是想阻止某人强制执行ObjectIDs。

这种方法是否可行有效？

Answer 1

在您在ObjectID生成中引用的原始答案的上下文中，guessable由“给定足够的时间”限定。

我不会关注你的身份证是否可以通过蛮力来猜测，而是考虑检测和减轻任何暴力攻击的方法。这消除了让对手有足够时间尝试所有可能组合的方面（无论您的ID格式如何，这种方法都可以工作）。

例如，用于检测暴力攻击的明显签名可能包括：

• 来自特定IP地址的大量404请求
• 对增量ObjectID的连续请求（应该很少见）
• 无效的ObjectID（如果攻击者不知道预期的格式）

需要考虑许多不同的策略和对策，但有用的出发点是OWASP关于Blocking Brute Force Attacks的信息。

  

这些资源需要公开访问（不在登录后面），但我正在努力减少黑客强行使用ObjectID并随意抓取它们的机会。

如果资源是公开的，攻击者可以更容易地找到它们：抓取公共页面并获取链接的资源。在这种情况下，您仍然可以应用反爬行策略，但如果您想避免影响合法用户，则这些策略会变得更加棘手。例如，来自特定IP的大量有效请求可能表示公司或ISP代理，而不是试图滥用您的服务的人。智能抓取工具还可以模仿用户模式（请求之间的延迟，请求网址中的随机性，......），以便尝试击败任何保护措施。

作为起点，请参阅：Anti-crawling Techniques。

Answer 2

首先，很难在这里看到你的目标。资源应该是公共可访问的，同时您担心某人可以猜测资源的位置。如果您在应用程序中猜测ObjectID会导致问题，可能会更好。

我假设你正在尝试做一些允许交换数据的共享服务（比如通过文件共享的dropbox），你基本上试图保护ObjectID背后的数据。

在这种情况下你所概述的方式没有问题，所以我将添加另一种方法：创建你自己的objectIDs（一些随机生成的长字符串）。一个潜在的问题是它们可能会发生碰撞，但是这个事件真的很少见，所以如果你将它包装成try catch并重做失败，你应该没问题。