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

Question

Мне действительно нравятся автоматически генерируемые идентификаторы MongoDB.Они действительно полезны.

Однако можно ли их использовать публично?

Допустим, есть коллекция постов и страница / posts, которая принимает параметр id (что-то вроде / posts / 4d901acd8df94c1fe600009b) и отображает информацию о ней.

Таким образом, пользователь / хакер будетзнать реальный идентификатор объекта документа.Это нормально или небезопасно?

Спасибо

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

Больше не небезопасно использование значения автоприращения id из MySql.Это не нарушение правил безопасности.