CouchDB and Cloudant Security

本文关键字：Security Cloudant and CouchDB 更新时间：2023-09-26

我们在生产中使用了CouchDB，主要是在受控环境中构建应用程序。大多数时候，我们使用中间件库对couchdb/cloudant进行直接调用，从而避免了直接调用（前端JavaScript直接调用CouchDB/Cloudant）。

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

附件在中间处理时通常会很痛苦。让cloudant直接将附件的缓存和服务处理到前端是有利的，从而减轻了我们的中间件的负担。然而，在网络上，面对庞大的受众，直接打电话到我们多云的环境是很棘手的。

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

问题：我们如何找到一种方法来隐藏cloudant环境的用户名和密码，从而允许我们安全地对cloudant进行直接的JavaScript调用？我们的基础设施完全在云端，所以我们没有代理和其他东西可以使用。我们听说过Url缩短服务，CDN e.t.c.，但是，我们还没有想出一个真正决定性的解决方案。

尝试使用会话端点（_session endpoint）。这将设置cookie身份验证。

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

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

因此，您所做的一件好事是将附件数据库分离。你在问题中没有提到你是否使用了couchdb授权方案，所以我假设你没有。因此，第一步是在couchdb _users数据库中创建一个用户，然后将其分配为附件数据库中的成员。更多详细信息，请点击此处。

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

这是一个开始，但这还不够，因为成员仍然可以通过_all_docs进行读取，这就是dos攻击。所以我们现在面临的问题是，我们现在这样做

https://｛用户名｝：{password}@username.cloudant.com/数据库

一个非常好的举措是将其更改为

https://｛用户名｝：{password}@someurl.com/

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

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

~~跟踪程序~~inquisitive boy将不知道呼叫的去向。
他不可能通过直接打电话来获取未知文件的内容。他只能通过您设置的规则访问您的数据库。

仍然不是100%安全，但就读取级别的安全性而言还可以。希望这能有所帮助。