Избегайте подвергать первичные ключи источнику веб-приложения?

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

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

Должно ли вы предоставить другое значение веб-приложению, которое можно перевести обратно на первичный ключ?

Спасибо

Edit

В идеальном мире ваше приложение будет на 100% безопасным, поэтому было бы неважно, если вы замаскировали вещи. Очевидно, что не так, поэтому мы должны ошибаться с осторожностью и не раскрывать эту информацию?

Некоторые из них указали, что Stackoverflow, вероятно, раскрывает ключ в Url, который, вероятно, прекрасен. Однако для корпоративных приложений разные соображения?

Ответ 1

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

Однако использовать идентификаторы в качестве значения для элементов списка со списком? Пойдите, я говорю. Какой смысл делать перевод с промежуточного значения и обратно? У вас может не быть уникального ключа для использования. Такой перевод создает больше возможностей для ошибок.

Просто не пренебрегайте безопасностью.

Если вы сообщите, что вы представляете пользователя с 6 элементами (от 1 до 6), никогда не предполагайте, что вы получите эти значения только от пользователя. Кто-то может попытаться нарушить безопасность, отправив обратно ID 7, поэтому вам все равно придется проверять, разрешено ли вам возвращаться.

Но избегайте этого полностью? Ни за что. Нет необходимости.

Как говорится в другом ответе, посмотрите здесь URL. Это включает в себя, без сомнения, первичный ключ для вопроса в базе данных SO. Это совершенно нормально, чтобы выставлять ключи для технических целей.

Кроме того, если вы вместо этого используете какое-то суррогатное значение, это не обязательно более безопасно.

Ответ 2

Да на все ваши вопросы. Я согласен с вашими утверждениями в том, что вы должны "показать другое значение для веб-приложения, которое может быть переведено на первичный ключ"

В противном случае вы можете открыть себе потенциальные проблемы.

Edit

Относительно комментария, что "нет оснований для принятия штрафного удара для тривиальных ключей. Посмотрите в URL-адрес своего браузера прямо сейчас, я уверен, вы видите ключ!".

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

Я бы предпочел разоблачить нечто иное, чем ПК - что-то с семантической ценностью. Название вопроса также указано в URL-адресе, но поскольку это было бы трудно проверить как уникальное (или передать между пользователями в устной форме), оно не может быть надежно использовано на нем.

Однако, просматривая URL-адреса "тегов" (т.е. https://stackoverflow.com/questions/tagged/java+j2ee), ПК не отображаются и вместо этого используются имена тегов. Лично я предпочитаю этот подход и буду стремиться к этому.

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

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

Это один экземпляр, в котором разоблачение PK "сломает" приложение, не связанное с безопасностью приложения. Не так с сгенерированным ключом.

Ответ 3

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

Используйте другой ключ/столбец, если считаете, что информация чувствительна.

Например, чтобы не показывать, как могут быть у вас пользователи, подумайте:

site.com/user/123 vs site.com/user/username

Ответ 4

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

Как говорили другие, хотя для раскрывающегося списка значений обычно нет проблем.

Ответ 5

Выявление других значений, чем первичный ключ, не будет препятствовать вам проверке безопасности. Действительно, если у вашей безопасности есть дыры, "злые" пользователи могут по-прежнему обращаться к объектам, к которым они не предназначены, изменяя значение в URL-адресе. У них может быть меньше подсказок о том, какие значения использовать, но случайным образом собирать ценности, им может повезти.

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

Я думаю, что это не стоит хлопот большую часть времени.

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

Ответ 6

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

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

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

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