MongoDB: безопасно ли использовать идентификатор документа "публично"?

Ответ 1

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

Кроме этого, Epcylon right; нет ничего по своей сути небезопасно об экспонировании идентификаторов через URL-адреса. Конечно, это уродливое другое дело. Вы можете base64 их, чтобы сделать их короче (думал об этом сам), но тогда есть странный факт, что они все примерно наполовину...

Ответ 2

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

Сравните с столбцом типа Auto-ID в СУБД. Вы все время выставляете их наружу, я не знаю, почему я не делаю то же самое с идентификаторами MongoDB.

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

Ответ 3

Я думал, что mongodb _id был основан на дате, и вырезать адрес и другие вещи, которые вы, возможно, предпочтете сохранить конфиденциальными.

Если вы беспокоитесь, возможно, стоит зашифровать мангоиды и использовать результат в качестве идентификатора на стороне клиента (а затем без шифрования при возврате запросов).

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

Очевидно, что все еще важно проверить пользователя другими способами!

Ответ 4

Возможно, подумайте об этом как о проблеме конфиденциальности, чем безопасности.

Я столкнулся с той же проблемой. При хранении контента, предоставленного пользователями в каталогах, доступных в Интернете, на основе идентификатора, созданного Mongo, существует риск, что эти идентификаторы предсказуемы, что один пользователь может получить доступ к другому пользовательскому контенту.

Я думаю, что советы других - это правильный путь: зная, что URL-адрес личного содержимого для пользователя не должен быть достаточным для доступа к нему. Попытка доступа должна проверять, что соответствующий пользователь делает запрос.

Я намерен сделать это в Symfony2, сохранив содержимое пользователя вне веб-корня, а затем разрешив ему доступ через новый маршрут/контроллер, который перед передачей ответа будет проверять некоторую идентифицирующую информацию о пользователя.

Ответ 5

Это не более опасно, если использовать значение auto increment id из MySql. Это не нарушение безопасности в любом случае.

Ответ 6

• Если идентификатор ссылается на "незарегистрированный" контент, для которого требуется только ссылка - это проблема конфиденциальности.

• Если id указывает ссылку на контент, находящийся под логином пользователя, это не проблема.

Независимо от того, это MongoDb, SQL или любой другой идентификатор. Идентификатор является ключом к данным. Если этот ключ - это только то, что вам нужно, чтобы просмотреть контент, который вам не нужен, - проблема. Для такой ситуации - генерировать unguessable id.