CouchDB和Cloudant安全性

Question

我们在生产中使用了CouchDB ，主要是在受控环境中构建应用程序。 大多数情况下，我们使用中间件库直接调用couchdb/cloudant ，因此避免直接（前端JavaScript调用直接到CouchDB/Cloudant ）。

出于安全原因，很明显，对于经过身份验证的CouchDB数据库：
http://{username}:{password}@IPAddress:Port/DB
或者对于cloudant：
https://{username}:{password}@username.cloudant.com/DB ，如果直接通过JavaScript进行调用，今天浏览器中的开发人员工具可以让一个人实现此调用，因此可以完全访问您的数据库。

在中间件处理时，附件通常很痛苦。 有利的是使云量处理附件的高速缓存和服务直接到前端，从而减轻了我们的中间件。 但是，在网络上和庞大的受众群体中，直接调用我们的云端环境非常棘手。

我们首先为所有附件设置了一个单独的cloudant帐户，这样一个inquisitive boy不会篡改我们用户的实际元数据或信息。 因此，他们可以访问的唯一cloudant帐户是附件，因为我们正在对我们的数据库进行直接的JavaScript调用。

问题：我们如何找到隐藏云环境的用户名和密码的方式，从而允许我们安全地对云端进行直接JavaScript调用？ 我们的基础架构完全在云端，因此我们没有代理和东西可以使用。 我们听说过Url缩短服务，CDN等，但我们还没有找到一个非常确定的解决方案。

Answer 1

尝试使用_session端点。 这将设置cookie身份验证。

Answer 2

我们如何找到隐藏云环境的用户名和密码的方式，从而允许我们安全地对云端进行直接的JavaScript调用？

据我所知，如果不使用中间件或某种代理，你就无法做到这一点。 但这并不意味着我们完全没有防御能力。 couchdb给了我们一些长矛来戳戳inquisitive boy :)

所以你做的一件好事就是使附件数据库分开。 你没有在你的问题中提到你是否使用couchdb授权方案，所以我假设你不是。 因此，第一步是在couchdb _users数据库中创建用户，然后将其指定为附件数据库中的成员。 更多细节在这里和这里 。

完成此步骤后，您应该在附件数据库上拥有一个成员。 我们想要一个成员而不是一个管理员的原因是成员没有写入或读取设计文档的权限。

这是一个开始，但它还不够，因为一个成员仍然可以通过_all_docs阅读，那就是那里的dos攻击。 所以我们现在面临的问题是我们目前正在做这件事

https：//开头{用户名}：{}密码@ username.cloudant.com / DB

一个非常好的举措是改变它

https：//开头{用户名}：{}密码@ someurl.com /

这两者有什么区别？ 它隐藏了数据库的位置，使得访问内置方法更加困难。 这可以通过vhosts配置和一些重写规则来完成 。 一些非常好的东西也在Caolan的博客上

有了这个，你有两件事要做。

1. 缠扰者 inquisitive boy将无能为力。

2. 他无法通过直接电话获取未知文件的内容。 他只能通过您设置的规则访问您的数据库。

仍然不是100％安全，但就读取级别的安全性而言它是可以的。 希望这可以帮助。