Выявление идентификаторов базы данных - риск для безопасности?

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

Любые мнения или ссылки о том, почему это риск, или почему это не так?

EDIT: конечно, доступ ограничен, например. если вы не видите ресурс foo?id=123, вы получите страницу с ошибкой. В противном случае сам URL должен быть секретным.

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

EDIT (несколько месяцев спустя): моя текущая предпочтительная практика для этого - использовать UUIDS для идентификаторов и разоблачить их. Если я использую последовательные номера (обычно для производительности на некоторых БД) в качестве идентификаторов, мне нравится генерировать токен UUID для каждой записи в качестве альтернативного ключа и выставлять это.

Ответ 1

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

Вот несколько хороших правил:

Используйте защиту на основе ролей для контроля доступа к операции. Как это делается, зависит от платформы и структуры, которую вы выбрали, но многие поддерживают модель декларативной безопасности, которая автоматически перенаправляет браузеры на этап аутентификации, когда действие требует определенных полномочий.
Используйте программную защиту для контроля доступа к объекту. Это сложнее сделать на уровне структуры. Чаще всего это то, что вам нужно записать в ваш код и, следовательно, больше подвержено ошибкам. Эта проверка выходит за рамки проверки на основе ролей, гарантируя не только то, что у пользователя есть полномочия для операции, но также имеет необходимые права на конкретный объект, который изменяется. В системе на основе ролей легко проверить, что только менеджеры могут давать повышение, но помимо этого вам нужно убедиться, что сотрудник принадлежит к определенному менеджеру.
Для большинства записей базы данных достаточно условий 1 и 2. Но добавление непредсказуемых идентификаторов можно рассматривать как небольшую дополнительную страховку или "безопасность в глубину", если вы покупаете это понятие. Однако одно место, где непредсказуемые идентификаторы являются необходимостью, относится к идентификаторам сеанса или другим токенам аутентификации, где сам идентификатор аутентифицирует запрос. Они должны генерироваться криптографическим RNG.

Ответ 2

Это зависит от того, что означают идентификаторы.

Рассмотрите сайт, который по конкурентной причине не хочет публиковать, сколько у них членов, но с помощью последовательных идентификаторов, все равно показывает его в URL-адресе: http://some.domain.name/user?id=3933

С другой стороны, если они вместо этого использовали имя пользователя для входа: http://some.domain.name/user?id=some, они не раскрыли ничего, что пользователь сделал Уже знаю.

Ответ 3

Общая мысль идет по этим строкам: "Раскрывайте как можно меньше информации о внутренней работе вашего приложения для всех".

Отображение количества идентификаторов базы данных как раскрытие некоторой информации.

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

Ответ 4

Мы используем идентификаторы GUID для идентификаторов базы данных. Утечка их намного менее опасна.

Ответ 5

Несмотря на то, что риск безопасности данных является абсолютно безопасным безопасностью бизнес-аналитики, поскольку он предоставляет как размер данных, так и скорость. Я видел, как предприятия получают от этого вред и написали об этом анти-шаблоне в глубину. Если вы просто не строите эксперимент, а не бизнес, я бы настоятельно предложил сохранить ваши личные идентификаторы вне поля зрения общественности. https://blog.lightrail.com/prevent-business-intelligence-leaks-by-using-uuids-instead-of-database-ids-on-urls-and-in-apis-17f15669fd2e

Ответ 6

Если вы используете идентификаторы целых чисел в своем db, вы можете облегчить пользователям просмотр данных, которые им не следует, изменяя переменные qs.

например. пользователь может легко изменить параметр id в этом qs и увидеть/изменить данные, которые они не должны http://someurl?id=1

Ответ 7

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

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

Таким образом, мы используем синтетический локальный идентификатор сеанса, потому что он скрывает столько, сколько мы можем сойти с рук.

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