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

Question

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

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

РЕДАКТИРОВАТЬ: конечно, доступ ограничен, например, если вы не видите ресурс foo?id=123, вы получите страницу с ошибкой. В противном случае сам URL должен быть секретным.

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

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

Answer 1

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

Вот несколько хороших правил, которым нужно следовать:

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

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

Answer 7

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

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

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

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