Meteor对ACL有mongo注入问题吗？

Question

"输入验证"下的Meteor docs http://docs.meteor.com/#dataandsecurity说:

Meteor允许您的方法和发布函数接受任何JSON类型的参数.(事实上​​,Meteor的有线协议支持EJSON,它是JSON的扩展,它还支持其他常见类型,如日期和二进制缓冲区.)JavaScript的动态类型意味着您不需要在应用程序中声明每个变量的精确类型,但通常有助于确保客户端传递给方法和发布函数的参数属于您期望的类型.

Meteor提供了一个轻量级库,用于检查参数和其他值是否是您期望的类型.只需使用check(用户名,字符串)或check(office,{building:String,room:Number})等语句启动函数.如果其参数是意外类型,则检查调用将引发错误.

Meteor还提供了一种简单的方法来确保所有方法和发布函数都验证其所有参数.只需运行meteor add audit-argument-checks和任何跳过检查其任何参数的方法或发布函数都会失败并出现异常.

在安全性讲座中更详细地解释了mongo注入问题:https://www.meteor.com/blog/2013/08/02/meteor-devshop-6-devshop-live-security-meteor-ui

所以我的问题是:

1. check在调用Mongo之前必须做什么,或者冒险将不受信任的JS对象发送到db中,从而可能会导致Mongo注入漏洞？- 是的,应该audit-argument-checks在他的应用程序中加入以防止这种情况发生
2. 这必须在所有mongo行动上完成,而不仅仅是在find？- 不确定
3. 如果1)或2)是真的,那么这又如何转化为使用ACL式数据库访问规则(collection.allow/ collection.deny),其中对mongo api的调用不是通过手动check调用过滤而是留给客户端？- 你可以添加check到允许/拒绝功能,但它取决于2)是否和何时需要

Answer 1

1. 是.如果您盲目地信任客户端传递给方法调用的值,则会发生各种不良事件.
2. 这进入理论,可能很少有人能给你一个直接的答案,那么为什么要承担风险呢？我强烈建议为所有项目添加audit-argument-checks以确保安全.
3. 关于allow和deny,find呼叫在这里没有风险,因为数据已经在客户端上(可能你的发布功能应该已经发布了正确的文档).我认为这种情况下的风险与坏数据有关,而与安全性有关.只需check在规则中添加调用就足够了.例如:

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

如果文档不符合架构,则无法从客户端插入新帖子.