Question

我正在关注eventedmind的流星教程。我们将待办事项收集信息放在lib/collections/todos.js中。该应用程序是用铁生成的。

当我在浏览器中加载应用程序时，我可以清楚地看到源文件夹下的文件夹。它看起来像：

Todos = new Mongo.Collection('todos');

// if server define security rules
// server code and code inside methods are not affected by allow and deny
// these rules only apply when insert, update, and remove are called from untrusted client code

if (Meteor.isServer) {
  // first argument is id of logged in user. (null if not logged in)
  Todos.allow({
    // can do anythin if you own the document
    insert: function (userId, doc) {
      return userId === doc.userId;
    },

    update: function (userId, doc, fieldNames, modifier) {
      return userId === doc.userId;
    },

    remove: function (userId, doc) {
      return userId === doc.userId;
    }
  });

  // The deny method lets you selectively override your allow rules
  // every deny callback must return false for the database change to happen
  Todos.deny({
    insert: function (userId, doc) {
      return false;
    },

    update: function (userId, doc, fieldNames, modifier) {
      return false;
    },

    remove: function (userId, doc) {
      return false;
    }
  });
}

我的问题是这是否会提出安全威胁？如果javascript文件存储在lib目录中，它是否可以被客户端劫持？

Answer 1

永远不要使用Meteor.isServer。而是将您的服务器方法放在/server下。代码 not 提供给客户。

我不同意补救措施，即将插入移动到服务器比在客户端上插入更安全。毕竟，登录用户只需打开控制台并键入Meteor.call('addPost', new_post_fields)（在检查postsCollection中的文档后对模式进行反向工程），服务器将很乐意执行该操作。通过方法调用进行插入的成本是您丢失延迟补偿，这是Meteor的主要优点之一。您的应用程序会感到迟钝，因为您的插入都需要服务器往返才能在UI中反映出来。

让我更具体地回应补救措施'评论：

如果您的方法代码在/ lib中，它将对客户端和服务器都可见，并且将在每个位置运行一次，并具有延迟补偿。它可以在客户端上修改，但不能在服务器上修改。但可以看出。
如果您的方法代码位于/ server中，则只有服务器可以看到它，并且将在没有延迟补偿的情况下运行。

可以使用任何参数从客户端的控制台调用Meteor.call（）。您的方法代码需要防止此类攻击。

我建议至少在服务器上使用允许/拒绝规则以及aldeed:simple-schema来控制收藏中的内容。

meteor - lib文件夹中的发布规则是否存在安全风险？

1 个答案: