2

我观看了 DEFCON，它完全致力于 NoSQL，尤其是 CouchDB。他们观察到一些攻击向量，例如访问客户端库（伪 SQL 透明层）、访问 db 和暴力密钥。（以无模式方式）、json/视图注入。如果我直接从 Internet 访问 db，并在 db 验证、身份验证中使用。这样会不会降低我的数据库的安全性？

不幸的是，由于缺乏使用 CouchDB 的经验，因此无法进行准确的分析，亲爱的同事，请相信您的意见。

谢谢你。

4

3 回答 3

4

不，我不会这样做。

我觉得 CouchDB 的安全性不够精细，不足以使其适合发布在互联网上。没有办法让“一些”数据通过，而不是全部。在普通的 SQL DB 上，您可以限制某些表等。但不能在 Couch 中。作为无模式和文档存储，文档就是文档就是文档，无论它是“秘密”还是“重要”。

这是一个很好的后端，但不是在狂野的互联网上。

于 2012-08-09T17:31:47.120 回答
0

直接访问任何基于 Web 的数据库都是自找麻烦，但我想这取决于您的设计......

使用 CouchDB，您可以选择为每个用户提供他们自己的数据库，这将缓解某些问题。您还可以更改“直接”CouchDB 用户的读/写权限。

可以在此处找到这两种技术的详细说明： 基于每个数据库的 CouchDB 授权

于 2012-08-29T12:22:01.557 回答
0

在我看来，任何人都可以直接将 couchDB 与您的前端一起使用，而无需设计中间后端服务。我想强调你至少需要做的事情。虽然我不是专家，但也应该三思而后行。

  • 在 couchdb 中为具有所需角色的应用程序的每个用户创建用户。
  • 当然，您应该只将此用户作为成员添加到数据库中，这样他们就无法修改包含验证数据的设计文档。
  • 在我的场景中，我希望用户只能访问他/她自己的文档。为此，我们有验证文档，以便我可以检查内置 _users 数据库中的用户文档是否具有他/她被授权的 documentId。如果是这样，他可以写入文档或修改它。当然，他只能修改现有的，我可以通过比较文档的_id来验证，它必须与以前相同。

所以，我想，如果用户只能读写自己的文档，那是安全的。但是，您必须自己在数据库中创建此类用户，或者使用安全 API 来使用管理员密码修改设计文档并添加到 _users 数据库。另一个想法是创建一个管理仪表板来接受用户创建请求。您当然可以为自己创建一个管理员用户，每当有人创建帐户时，您只需单击“允许”即可使用您在 couchDB 中创建的管理员用户对 _users 数据库进行一些更改。

于 2021-08-15T10:14:57.393 回答