Мне очень нравится, что MongoDB автоматически генерирует идентификаторы. Они действительно полезны.
Однако можно ли использовать их публично?
Скажем, есть коллекция сообщений и страница /posts, которая принимает id paramater (что-то вроде /posts/ 4d901acd8df94c1fe600009b) и отображает информацию об этом.
Таким образом, пользователь/хакер узнает идентификатор реального объекта документа. Все в порядке или не безопасно?
Спасибо
Sez здесь, автоматически сгенерированные идентификаторы включают трехбайтовый идентификатор машины (предположительно хэш MAC-адреса). Не исключено, что кто-то может разобраться в вашей внутренней сети, сравнивая эти три байта в разных идентификаторах, но если вы не работаете в Пентагоне, который, похоже, не стоит беспокоиться (вы, скорее всего, будете уязвимы для что-то более скучное, как неправильно сконфигурированный Apache).
Кроме этого, Epcylon right; нет ничего по своей сути небезопасно об экспонировании идентификаторов через URL-адреса. Конечно, это уродливое другое дело. Вы можете base64 их, чтобы сделать их короче (думал об этом сам), но тогда есть странный факт, что они все примерно наполовину...
У меня нет опыта работы с MongoDB в производственной среде, поэтому не принимайте мой ответ как правду, но я не могу себе представить, почему это не должно быть безопасным.
Сравните с столбцом типа Auto-ID в СУБД. Вы все время выставляете их наружу, я не знаю, почему я не делаю то же самое с идентификаторами MongoDB.
Как всегда, безопасность должна заключаться в проверке ввода и не позволяя никому находиться рядом с вашей базой данных без надлежащей защиты. Делайте это правильно, и не имеет значения, знают ли они, как выбрать конкретный объект в вашей базе данных, поскольку они все еще ничего не могут с ним сделать.
Я думал, что mongodb _id был основан на дате, и вырезать адрес и другие вещи, которые вы, возможно, предпочтете сохранить конфиденциальными.
Если вы беспокоитесь, возможно, стоит зашифровать мангоиды и использовать результат в качестве идентификатора на стороне клиента (а затем без шифрования при возврате запросов).
Если ключ шифрования частично основан на некотором уникальном атрибуте рассматриваемого пользователя или сеанса, это затрудняет пользователям доступ к контенту, если он не должен.
Очевидно, что все еще важно проверить пользователя другими способами!
Возможно, подумайте об этом как о проблеме конфиденциальности, чем безопасности.
Я столкнулся с той же проблемой. При хранении контента, предоставленного пользователями в каталогах, доступных в Интернете, на основе идентификатора, созданного Mongo, существует риск, что эти идентификаторы предсказуемы, что один пользователь может получить доступ к другому пользовательскому контенту.
Я думаю, что советы других - это правильный путь: зная, что URL-адрес личного содержимого для пользователя не должен быть достаточным для доступа к нему. Попытка доступа должна проверять, что соответствующий пользователь делает запрос.
Я намерен сделать это в Symfony2, сохранив содержимое пользователя вне веб-корня, а затем разрешив ему доступ через новый маршрут/контроллер, который перед передачей ответа будет проверять некоторую идентифицирующую информацию о пользователя.
Это не более опасно, если использовать значение auto increment id из MySql. Это не нарушение безопасности в любом случае.
Если идентификатор ссылается на "незарегистрированный" контент, для которого требуется только ссылка - это проблема конфиденциальности.
Если id указывает ссылку на контент, находящийся под логином пользователя, это не проблема.
Независимо от того, это MongoDb, SQL или любой другой идентификатор. Идентификатор является ключом к данным. Если этот ключ - это только то, что вам нужно, чтобы просмотреть контент, который вам не нужен, - проблема. Для такой ситуации - генерировать unguessable id.