Почему первичные ключи БД не должны отображаться в HTML-коде, например в выбранных полях?

Question

везде, где я читал, что значения в полях выбора (или что-либо еще в HTML-коде) не должны быть первичным ключом таблицы базы данных.Например:

<select>
       <option value="1">Value 1</option>
       <option value="2">Value 2</option>
</select>

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

Answer 1

Звучит как безопасность сквозь мрак , иначе мне совсем не безопасность.

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

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

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

Answer 2

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

Суррогатный ключ не должен иметь делового значения или иметь зависимости в коде приложения или внешних процессах. Это часто является важным соображением, например, если значения ключей необходимо изменить в результате развития структуры базы данных или объединения наборов данных. Используя суррогатные ключи в качестве «магических чисел» в коде или в URL-адресах, вы можете скомпрометировать то, что делает суррогатные ключи полезными. Кроме того, суррогатные ключи гораздо менее удобны для пользователей (и, возможно, разработчиков), поскольку значения для них не имеют смысла и поэтому менее читабельны, чем использование естественного ключа.

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

Answer 3

Меня беспокоит, как информация обрабатывается с URL.Что произойдет, если я разместил контент, используя value = "does_this_break_the_code" или value = "can_I_read_secret_info"

Answer 4

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

Скажем, у вас есть база данных автомобилей, все автомобили имеют уникальный идентификатор, называемый VIN (идентификационный номер транспортного средства), в VIN кодируется куча информации о каждом конкретном автомобиле вплоть до завода, который его изготовил. VIN идентифицирует только один конкретный автомобиль. PK на предмете может быть чем угодно, автомобиль сбрасывается из БД, теперь PK не существует, но этот VIN все еще где-то там. Это гораздо лучший уникальный идентификатор, чем PK, так что это то, что, вероятно, должно отображаться пользователям.