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％安全，但就讀取級別的安全性而言它是可以的。 希望這可以幫助。