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


134

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

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

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

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

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

Ответы:


109

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

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

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

27
ИМО, добавление непредсказуемых идентификаторов является подходом «безопасность через неясность» и может привести к ложному чувству безопасности. Лучше сосредоточиться на (1) и (2) и убедиться, что ваш контроль доступа надежный.
Stucampbell

4
Использование криптографического ГСЧ определенно не «безопасность через неизвестность». Злоумышленник не приблизился к угадыванию идентификаторов объектов, даже если знает, как вы их генерируете. Безопасность через неясность означает, что если алгоритм, который вы используете, будет обнаружен, его можно будет использовать. Это не относится к хранению секретов, таких как ключи или внутреннее состояние ГСЧ.
erickson

1
@stucampbell Возможно, но это не значит, что вам вообще не следует использовать непредсказуемые идентификаторы. Ошибки случаются, поэтому непредсказуемые идентификаторы - дополнительный механизм безопасности. Кроме того, контроль доступа - не единственная причина их использования: предсказуемые идентификаторы могут раскрыть конфиденциальную информацию, такую ​​как количество новых клиентов в течение определенного периода времени. Вы действительно не хотите разглашать такую ​​информацию.
user247702

1
@Stijn, вы не можете сказать, что я «действительно не хочу» раскрывать, сколько у меня клиентов. Я имею в виду, что у McDonald's есть огромная вывеска, на которой написано, что они обслужили 10 миллиардов гамбургеров. Это вовсе не угроза безопасности, это предпочтение. Кроме того, вам необходимо войти в систему, прежде чем вы увидите какие-либо URL-адреса в большинстве приложений, где мы все равно будем беспокоиться об этом. Таким образом, мы будем знать, кто собирает данные.
Уэйн Блосс

1
Одна вещь, о которой я не упоминал в этом разговоре, заключается в том, что с точки зрения устранения неполадок и простоты использования может быть очень удобно, если идентификатор будет отображаться в URL-адресе, чтобы помочь направить пользователей к определенному ресурсу или дать им возможность чтобы точно сказать, какой ресурс они просматривают. В основном вы можете избежать проблем с бизнес-аналитикой, запустив автоматическое приращение с более высокого значения, просто чтобы предложить одну идею.
Chockomonkey

47

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


4
Наконец, разумный ответ, приносящий другие аспекты, кроме угрозы безопасности.
peceps 01

2
Это должен быть принятый ответ. Если вы предполагаете, что злоумышленник может обойти вашу безопасность (что вы всегда должны делать), вы не захотите просто передать такую ​​информацию.
Криил

@Kriil Им даже не нужно обходить вашу безопасность. Им просто нужно создать учетную запись!
Питер

32

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

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

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


2
если вы используете последовательные идентификаторы, вы правы, но если нет, то это ничего не раскрывает
orip

@orip: Как я уже сказал, это зависит от того, что кто-то может обнаружить, изучив несколько идентификаторов. Есть закономерность? Могут ли они использовать эту информацию для получения информации, которой они не собирались располагать?
некоторые

@John: Спасибо за редактирование. Английский не мой родной язык :)
некоторые

6
Я сделал именно это: использовал последовательные идентификационные номера, чтобы определить размер пользовательской базы конкурента.
Мика

3
Они повсюду. Многие магазины используют порядковый номер в качестве идентификатора заказа. Разместите один заказ в один день, а один в другой - и вы знаете, сколько заказов они получили за этот период. Даже если вы не знаете, сколько денег стоят заказы, вы все равно получите представление о том, насколько хорошо идет бизнес.
некоторые

25

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

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

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


1
Доступ к ресурсам, которые они не должны видеть - только если я не проверяю разрешения (что я делаю, иначе у меня другая проблема с безопасностью). Раскрытие информации о «внутреннем устройстве» - это как раз мой вопрос. Почему это проблема?
orip

8
@orip: Все дело в максимальной безопасности. Если вы из тех программистов, которые не ошибаются, это не проблема. В противном случае раскрытие меньшего количества деталей затруднит использование вашего кода, если (когда) вы действительно сделаете ошибки. Само по себе вы правы, безопасности это не добавляет.
Адам Беллер,

@ Адам: поверхностная безопасность может быть хуже, чем отсутствие безопасности. Без безопасности вы явны, с поверхностной безопасностью можно подумать, что она добавляет что-то существенное.
orip

16

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


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

6
Это приводит к снижению производительности. Смотрите здесь
Jeshurun

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

Вы используете эти GUID также в html-коде в качестве атрибутов идентификатора для идентификации пользователей, комментариев, сообщений? Чтобы указать, по какой ссылке перешел пользователь или какой пост он хочет прокомментировать?
trzczy

7

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

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


7
Если я не проверяю разрешения, у меня другая проблема с безопасностью.
orip

но ответ точен: «может»
Сеун Осева

1
Вопрос не в том, будете ли вы проверять разрешения. Это если новый сотрудник, которого вы не знаете, проверит разрешения.
Брайан Уайт

@BrianWhite - вот почему вам нужен процесс проверки кода, чтобы вы могли обучать их до того, как он попадет в производство.
Candu 07

2
Что мы делаем, так это шифруем целочисленные идентификаторы, когда они используются в URL или переменных формы.
Брайан Уайт,

6

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

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

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

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


4
Интересно, хотя я думаю, что проверка всех вводимых данных (включая параметры URL) для каждого запроса очень подходит для Интернета.
Орип
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.