web-dev-qa-db-ja.com

CouchDBを保護する方法

RestサービスとしてのCouchDBアクセスは安全ではないようです。データベースが公開されると、誰でもデータベースにアクセスしてドキュメントを削除/追加できます。

CouchDBを保護するためにどのような戦略がありますか？

securitycouchdbrestful-authentication
31
steveolyo

2009年以降、多くの変化があったので、ここで答えを出します。この答えは wikiのこのページ から引用されています。

CouchDBには_usersユーザーを定義する目的に役立つデータベース。ウィキから直接の要点は次のとおりです。

  • 匿名ユーザーは、新しいドキュメントのみを作成できます。
  • 認証されたユーザーは、自分のドキュメントのみを更新できます。
  • サーバーまたはデータベース管理者は、すべてのドキュメントにアクセスして更新できます。
  • サーバーまたはデータベースの管理者のみが、設計ドキュメントを作成し、ビューと_all_docsおよび_changesにアクセスできます。

次に、任意のデータベースに対して、名前またはロールでアクセス許可を定義できます。認証を実装する方法は、_sessionデータベース。有効なユーザー名とパスワードを_sessionDBに送信すると、認証Cookieが返されます。これは、CouchDB認証のいくつかのオプションの1つです。さらにいくつかのオプションがあります。

  • このオプション 少し古い1.0は数か月前でしたが、今日は1.2になっています。しかし、それはまだ非常によく概説されています。
  • そして これ 「決定的なガイド」から

また、使用している可能性のあるホスティングサービスに応じて、SSLを介したCouchへのアクセスを制限するオプションがあります。

Node、Couch、および水平方向に効果的にスケーリングする（サーバーを追加する）他のさまざまなテクノロジーの間には、そのように適切にスケーリングするアプリケーションを作成するために開発者に課せられる興味深い種類のプレッシャーまたはインセンティブがあります。しかし、それはすべて一緒に別の問題です。

19
Costa

現在セキュリティに関して実際に機能しているのは、CouchDB構成でこのようなものだけです。

[couch_httpd_auth]
require_valid_user=true
[admins]
admin = sekrit

これにより、すべてのCouchDBに基本HTTP認証が適用されます。これでさえ、クライアントライブラリでは十分にサポートされていません。 pythonたとえば、 パッチが適用されたライブラリ が必要です。

2番目のアプローチは、CouchDBの前にプロキシを配置し、プロキシに認証と承認の作業を行わせることです。 CouchDBのRESTful設計により、これは非常に簡単です。

他のすべてのアプローチは、これまで非常に実験的なものと見なす必要があります。

9
max

これは、元の質問とは少し異なる場合があります。 couchdbが完全なサーバーアプリのバックエンドストアにすぎない場合は、サーバーアプリが使用する特別なアカウントを作成し、couchdbにアクセスするためにそれらの認証情報を要求できます。

一方、JavaScriptクライアントを介して直接ヒットする純粋なカウチアプリは、安全を確保するために多くの注意が必要です。

リライトの使用はオプションではありません。書き換えを通じてドメインへのリクエストを強制するvhosts設定が必要です。

ルート*/_all_docsと/ */_ design/*を404ページに書き換えます。それ以外の場合、ユーザーはすべてのドキュメントを一覧表示したり、アプリ全体を入手したりできます。

汎用オブジェクトアクセス、つまり/ dbname /：idを、ユーザーがドキュメントの表示を許可されていない場合にアクセスを拒否できるショーに書き換えます。残念ながら、添付ファイルのドキュメントベースのアクセス制御に相当する回避策はありません。

Haproxyを使用して、_usersでGETリクエストをフィルタリングしました。外部の誰かがユーザーレコードを取得したり、すべてのユーザーを一覧表示したりする正当な理由はありません。ユーザーが登録できるようにしたいので、書き込みアクセスが必要です。現在、couchはデータベースへの読み取りアクセスをブロックすると同時に書き込みを許可することはできません。バグです。 haproxyのようなものでフィルタリングすることは、今のところ最善の回避策です。

独自のデータベースを使用して、_usersによって提供されるものに加えて連絡先情報を保持します。これにより、アクセスをより細かく制御できます。

validate_doc_updateは、許可されるべきではない書き込みを慎重に拒否する必要があります。

いずれの場合も、システムを理解している誰かがシステムを破壊し、それらの攻撃手段を封鎖するために何ができるかを想像する必要があります。

6
bmidgley

CouchDBは、Cookie、SSL、oauth、およびマルチユーザーを問題なく実行します。

Pythonの実際のコードは次のとおりです。

from couchdb import Server
s = Server("https://user:[email protected]:6984")

クッキーをリクエストしてください：もちろん、上下にエンコードされたURL

Server（）コンストラクターと_session POST bodyの両方で、最初のCookieを開始するには、資格情報を2回入力する必要があります。

code, message, obj = s.resource.post('_session',headers={'Content-Type' : 'application/x-www-form-urlencoded'}, body="name=user&password=password")
assert(code == 200)

これでCookieを受け取りました、それを抽出します

cookie = message["Set-Cookie"].split(";", 1)[0].strip()

ここで、pythonを終了し、再起動します

次に、サーバーオブジェクトをリクエストしますが、今回はユーザー名とパスワードを使用しません

s = Server("https://example.com:6984")

s.resource.headers["Cookie"] = cookie

はい、パスワードはありません。データベースにアクセスしてみてください。

db = s["database"]

オプションで、サーバー側で「永続的な」Cookieオプションを設定して、Cookieを長持ちさせます。

1
Michael R. Hines