Javascript Meteor的ACL有mongo注射问题吗？

“输入验证”下的Meteor文档说明：

Meteor允许您的方法和发布函数接受 任何JSON类型。（事实上，Meteor的wire协议支持EJSON，一种 JSON的扩展，还支持其他常见类型，如日期 JavaScript的动态类型表示您不需要 声明应用程序中每个变量的精确类型，但是 通常有助于确保客户端传递的参数 方法和发布函数的类型与您期望的类型相同

Meteor提供了一个轻量级库，用于检查参数和 其他值是您期望的类型。只需开始你的工作 带有check（用户名、字符串）或 支票（办公室，{建筑物：字符串，房间：编号}）。支票电话将被取消 如果其参数属于意外类型，则引发错误

Meteor还提供了一种简单的方法来确保您的所有方法 和发布函数验证其所有参数。快跑流星 添加审核参数检查和任何 跳过检查其任何参数将失败，并出现异常

mongo注入问题在安全谈话中有更详细的解释：

因此，我的问题是：

在调用Mongo之前必须进行

检查

，否则可能会将不受信任的JS对象发送到db中，从而打开Mongo注入漏洞-是的，应该在应用程序中添加

审核参数检查

，以防止出现这种情况

这必须在所有mongo操作上完成，而不仅仅是在

find

-不确定

如果1）或2）为真，那么这如何转化为使用ACL样式的数据库访问规则（

collection.allow

/

collection.deny

），其中对mongo api的调用不通过手动

check

调用过滤，而是留给客户端-您可以将

检查

添加到允许/拒绝功能中，但这取决于2）是否以及何时需要执行此操作

---

在服务器上检查

允许

和

拒绝

规则，然后再让客户端查询运行。您完全可以在客户端和服务器上的允许/拒绝函数中使用

check

。您不在客户端上编写允许读取的规则，而是在发布函数中使用

check

对。如果盲目地信任客户机传递给方法调用的值，那么可能会发生各种不好的事情

这进入了理论，可能很少有人能给你一个直接的答案，那么为什么要冒险呢？为了安全起见，我强烈建议添加到所有项目中

关于

allow

和

deny

，

find

调用在这里没有风险，因为数据已经在客户端上（可能您的发布功能应该已经发布了正确的文档）。我认为这种情况下的风险更多地与坏数据有关，而不是与安全性有关。只需在规则中添加

check

调用就很容易了。例如：

---

---

如果文档不符合模式，则无法从客户端插入新帖子。

谢谢：）问题，当您说“您绝对可以使用”时，您的意思是“您应该/必须绝对使用”还是“您应该这样做，但在x、y、z的情况下为什么要费事”，meteor.com或各种在线教程中的示例都没有执行垃圾邮件检查，因此我想知道执行此操作的指导原则是什么？如果需要，可以使用检查，我建议使用检查，因为这是检查值类型的一种非常简单的方法。但是，您可能还需要执行check无法单独执行的其他验证—字段长度、用户id、唯一性等。重要的是，您的允许/拒绝规则足够强大，可以根据您的业务规则将查询缩小到仅受信任的查询。是否使用check来实现这一点取决于您——毕竟check是用JavaScript编写的，没有它，您什么都做不了。这很有用，为什么需要检查字段长度？Ddos防护或仅用于基本数据验证？仅用于基本数据验证，具体取决于您的业务规则。例如，StackOverflow将注释限制为600个字符。GitHub只允许您创建尽可能多的私有存储库。游戏只允许你的武器携带一定数量的弹药。可能您不想检查字段长度，但这取决于您的具体需要。好的，是的，这不用说我希望：）我想知道验证是否存在安全隐患，是否可以通过集合插入任意大的数据集。插入并危害数据库稳定性？（如果是这样，那么这种验证是你必须做的，而不是你应该做的）非常好的答案！因此，基本上，要使meteor安全，还应该定期添加

审核参数检查

，而不仅仅是删除

不安全的

和

自动发布

？然而，据我从软件包描述中所知，它并没有包括allow/deny中的

check

，但我想这可以归结为2的正确答案）：）你明白了-删除这2个，然后添加1，这样就可以在安全性上有一个坚实的开端。是，审核参数检查不强制您在允许/拒绝规则中使用

check

。

Posts.allow({
  insert: function(userId, doc) {
    check(doc, {
      _id: String,
      message: String,
      createdAt: Date
    });
    return true;
  }
});