Раскрытие идентификаторов баз данных - угроза безопасности?

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

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

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

РЕДАКТИРОВАТЬ: если URL-адрес является секретным, он, вероятно, будет содержать сгенерированный токен с ограниченным сроком службы, например, действительный в течение 1 часа и может использоваться только один раз.

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

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

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

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

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

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

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

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

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

Раскрытие идентификатора базы данных считается раскрытием некоторой информации.

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

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

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

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

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

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

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

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