Как защитить CouchDB

Ответ 1

С 2009 года многое изменилось, поэтому я собираюсь ответить на этот вопрос. Этот ответ сделан из этой страницы в вики.

CouchDB имеет базу данных _users, которая служит для определения пользователей. Вот суть прямо из вики:

• Анонимный пользователь может создать только новый документ.
• Аутентифицированный пользователь может обновить только собственный документ.
• Администратор сервера или базы данных может получать доступ и обновлять все документы.
• Только администраторы серверов или баз данных могут создавать проектные документы и просматривать представления и _all_docs и _changes.

Затем для любой конкретной базы данных вы можете определять разрешения по имени или роли. Способ аутентификации осуществляется через базу данных _session. Отправка правильного имени пользователя и пароля в базу данных _session возвращает куки файл проверки подлинности. Это один из нескольких вариантов проверки подлинности CouchDB. Есть еще несколько вариантов:

• Эта опция немного устарела 1.0, это было несколько месяцев назад, на сегодняшний день мы на 1.2. Но это все еще очень хорошо описано.
• И этот из "Окончательного руководства"

Кроме того, в зависимости от того, какую службу хостинга вы используете, у вас будет возможность ограничить доступ к кушетке через SSL.

Между Node, Couch и множеством других технологий, которые эффективно масштабируются горизонтально (добавление большего количества серверов), возникает интересный тип давления или стимула для разработчиков, чтобы приложения так хорошо масштабировались. Но это отдельный вопрос все вместе.

Ответ 2

Единственное, что действительно работает в настоящее время в плане безопасности, - вот что-то подобное в вашей конфигурации CouchDB.

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

Это ставит базовый HTTP-запрос на все CouchDB. Даже это не очень удобно в клиентских библиотеках. Для python, например. вам нужна исправленная библиотека.

Второй подход заключается в том, чтобы поставить прокси перед CouchDB и позволить прокси выполнять работу по аутентификации и авторизации. Благодаря дизайну CouchDB RESTful это довольно просто.

Все другие подходы должны быть рассмотрены до сих пор очень экспериментальными.

Ответ 3

Это может немного отличаться от вашего первоначального вопроса. Если ваш couchdb является только внутренним хранилищем для полного серверного приложения, вы можете создать специальную учетную запись для приложения сервера и использовать эти учетные данные для доступа к couchdb.

С другой стороны, приложение с чистым кушеткой, которое люди попадают прямо через клиент javascript, нуждается в большой заботе, чтобы быть в безопасности.

Использование перезаписи не является необязательным. Вам нужна конфигурация vhosts, которая заставляет ваши запросы пересылать ваш домен.

Перепишите маршруты */_ all_docs и /*/_ design/* на страницу 404. В противном случае пользователи могут перечислить каждый документ или получить все ваше приложение.

Переписать общий доступ к объекту, т.е. /dbname/: id, чтобы показать, что может запретить доступ, если пользователю не разрешено видеть документ. К сожалению, не существует эквивалентного метода обхода решения для доступа к вложениям на основе doc.

Мы использовали haproxy для фильтрации запросов GET на _users. У кого-то извне нет законной причины, чтобы получить запись пользователя или перечислить всех ваших пользователей. Мы хотим, чтобы пользователи могли зарегистрироваться, поэтому нам нужен доступ на запись. В настоящее время кушетка не может блокировать доступ для чтения к db и одновременно допускать запись. Это ошибка. Фильтрация с помощью чего-то вроде haproxy - наш лучший способ решения проблемы.

Используйте свою собственную базу данных, чтобы сохранить контактную информацию, которая в дополнение к тому, что предоставляется _users. Это позволяет больше контролировать доступ.

validate_doc_update должен тщательно отклонять любые записи, которые не должны быть разрешены.

В каждом случае вам нужно представить, что может понять тот, кто понимает систему, чтобы подорвать его и заблокировать эти возможности атаки.

Ответ 4

По состоянию на февраль 2013 года (и CouchDB 1.2) модель безопасности CouchDB выглядит недостаточно гибкой для меня. Хотя придерживаться этого не будет плохо и может сэкономить вам много времени, если вы не заботитесь о безопасности слишком много, что не применимо, если вы собираетесь заниматься производством для реальных пользователей.

В последнем случае вы должны пойти с отдельным промежуточным программным обеспечением проверки подлинности. Это дает возможность осуществлять выборочную аутентификацию относительно легко. Будь то OAuth, Cookies или SSL, у вас будет полный контроль над ним, а повторная аутентификация сторонних служб (или ваших собственных собственных механизмов) выглядит относительно простой. Говоря о безопасности, я бы также заботился о DoS-атаках, и, похоже, вы не сможете ограничить количество запросов на CouchDB с помощью самого CouchDB.

Вам также понадобится ваш собственный уровень из-за отсутствия явной поддержки авторизации для каждого документа (подробнее см. this). Прекрасным примером является поддержание мобильного приложения с большим количеством пользователей, которые не обмениваются данными друг с другом. TouchDB идеально подходит для этого, но тогда вы, вероятно, не создадите отдельную базу данных для каждого пользователя на бэкэнд с CouchDB, потому что это не идеально масштабируемо. С помощью отдельного промежуточного программного обеспечения вы можете проверить специальное поле в документе, который идентифицирует пользователя, которому принадлежит этот документ, или использовать любой другой ACL, который вы хотите.

Я бы не подумал о каких-либо проблемах с производительностью в реальном приложении до того, как проблемы безопасности не будут решены. Таким образом, даже развертывание nginx для перезаписи URL-адресов намного лучше, чем развертывание fenceless CouchDB на общедоступном сервере. Кроме того, производительность с nginx будет незначительной.

Ответ 5

CouchDB делает файлы cookie, SSL, oauth и многопользовательских пользователей просто прекрасными:

Вот некоторый фактический код в python:

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

Запросить файл cookie: url, закодированный выше и ниже, конечно

Вам нужно дважды ввести учетные данные, чтобы начать работу с первым файлом cookie Как в конструкторе Server(), так и в теге _session POST

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

Yay, нет пароля, попробуйте получить доступ к базе данных:

db = s["database"]

Опционально установите параметр "постоянный" cookie на стороне сервера, чтобы сделать файл cookie более длинным.

Ответ 6

Вы читали документацию CouchDB http://couchdb.apache.org/docs/overview.html? В нем есть раздел "Безопасность и проверка", в котором рассматриваются некоторые из ваших проблем.