24

如果您将 api 调用绑定到对象的 id，是否可以简单地强制此 api 获取所有对象？如果您想到 MySQL，那么使用增量整数 ID 完全可以实现这一点。但是MongoDB呢？id可以猜吗？例如，如果你知道一个 id，是否很容易猜出其他（下一个、上一个）id？

谢谢！

4

2 回答 2

24

2019 年 1 月更新：如评论中所述，以下信息在3.2 版之前都是正确的。版本 3.4+更改了规范，以便将机器 ID 和进程 ID 合并为一个随机的 5 字节值。这可能会使找出文档的来源变得更加困难，但它也简化了生成过程并降低了冲突的可能性。

原答案：

对于塞尔吉奥的回答+1，就回答是否可以猜到它们而言，它们不是散列，它们是可预测的，因此只要有足够的时间，它们就可以“强制”。可能性取决于 ObjectID 的生成方式以及您如何猜测。为了解释，首先，请阅读此处的规范：

对象 ID 规范

然后让我们逐个分解：

  • 时间戳 - 只要您大致了解数据的生成时间，就可以完全预测
  • 机器 - 这是几个选项之一的 MD5 哈希，其中一些比其他选项更容易确定，但高度依赖于环境
  • PID - 同样，这里的值不是大量的，并且可以针对从已知来源生成的数据进行侦查
  • 增量 - 如果这是一个随机数而不是增量（两者都允许），那么它的可预测性较差

稍微扩展一下来源。ObjectID 可以通过以下方式生成：

  • MongoDB 本身（但可以迁移、移动、更新）
  • 驱动程序（在任何插入或更新数据的机器上）
  • 您的应用程序（如果您愿意，可以手动插入自己的 ObjectID）

所以，你可以做一些事情来让它们更难单独猜测，但是如果没有大量的深思熟虑和保护措施，对于一个正常的数据集，有效的 ObjectID 的范围应该很容易计算出来，因为它们都带有前缀时间戳（除非您以某种方式操纵它）。

于 2012-07-20T10:56:55.203 回答
17

Mongo 的 ObjectId 绝不是为了防止暴力攻击（或任何攻击，就此而言）。它们只是提供全球独特性。你不应该假设某个对象不能被用户访问，因为这个用户不应该知道它的 id。

为了实际保护您的资源，请使用其他技术。

如果您防御未经授权的访问，请在您的应用程序中放置一些授权逻辑（允许合法用户访问，拒绝其他所有人）。

如果您想阻止转储所有对象，请使用某种速率限制。如果适用，请结合授权。

可选读物：Eric Lippert 谈 GUID。

于 2012-07-20T10:28:35.237 回答