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

Question

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

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

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

Спасибо

Редактировать

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

Некоторые отмечают, что Stackoverflow, вероятно, предоставляет ключ в URL-адресе, что, вероятно, нормально. Однако отличаются ли соображения для корпоративных приложений?

Answer 1

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

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

Только не пренебрегайте безопасностью.

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

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

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

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

Answer 2

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

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

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

site.com / user / 123 против site.com/user/username

Answer 3

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

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

Редактировать

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

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

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

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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