如何降低MongoDB对象的可猜测性？

我正在运行一个应用程序，该应用程序的公共可用资源位于

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

这些资源需要公开访问（而不是在登录之后），但是我正试图减少黑客暴力强迫ObjectID并随意删除它们的可能性

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

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

http://application.com/resource/**ObjectID**？key=**key**

甚至

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

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

<强>我意识到在保证隐私的意义上这并不是真正的保护，因为如果中间有人嗅到URL，他们可以访问资源。< /强>我只是想阻止某人从蛮力的对象。

---

这种方法可行且有效吗？

首先，在这里很难看到你的目标。资源应该是可公开访问的，同时您担心有人会猜到资源的位置。如果您将猜测应用程序中的objectid会导致问题的原因包括在内，可能会更好

我假设您正在尝试执行一些共享服务，允许交换数据（如通过文件共享的dropbox），并且您基本上试图保护ObjectID后面的数据

---

在这种情况下，您概述的方式没有问题，因此我将添加另一种方法：创建您自己的objectid（一些随机生成的长字符串）。一个潜在的问题是，它们可能会发生冲突，但此事件将非常罕见，因此，如果您将其包装为try-catch和redo-on-fail，您应该可以。

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

我不会关注你的ID是否可以被蛮力猜测，而是会关注检测和缓解任何蛮力攻击的方法。这消除了让对手有足够的时间尝试所有可能的组合（无论您的ID格式如何，这种方法都可以工作）的问题

例如，检测暴力攻击的明显特征可能包括：

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

虽然有很多不同的策略和对策要考虑，但是一个有帮助的起点是OWASP关于./P>的信息。 这些资源需要公开访问（而不是在登录之后），但是我正试图减少黑客暴力强迫ObjectID并随意删除它们的可能性

如果资源是公共的，那么对手可能有一种更容易找到它们的方法：抓取公共页面并获取链接的资源。在这种情况下，您仍然可以应用反爬网策略，但如果您希望避免影响合法用户，这些策略将变得更加棘手。例如，来自特定IP的大量有效请求可能表示公司或ISP代理，而不是有人试图滥用您的服务。智能爬虫还可以模拟用户模式（请求之间的延迟、请求URL中的随机性等等），以尝试破坏任何保护

作为起点，请参见：