Должен ли я запутывать идентификаторы базы данных от моих пользователей?

Ответ 1

Нет, вы просто делаете дополнительную работу для себя.

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

В некоторых ситуациях может быть полезно скрыть их или иметь несекретные числа или, возможно, не начинать отсчет с нуля. Например, если кто-то получил заказ №3, они могут начать задавать вопросы...

Ответ 2

ИМО: Нет, вы не должны обфускации идентификаторов. Если безопасность является проблемой для вашего приложения, вам все равно нужны другие меры безопасности. Недостаточность безопасности по неизвестности, это просто дает вам ложное чувство безопасности.

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

Ответ 3

Я бы сказал, что это вообще нормально, но есть некоторые gotchas:

• Если ваши номера последовательны, вы открываете "угадывать игры" (например, пользователь меняет детали? id = 4511 на детали? id = 4512, чтобы увидеть подробности других пользователей). Чтобы противодействовать этому, вам сначала нужна надлежащая безопасность. В некоторых случаях этого будет недостаточно, поскольку выявление того, что информация существует, может быть проблемой сама по себе. Например, возьмите Youtube, они используют более распространенные идентификаторы: s, чтобы избежать сбоев экрана робота.

• Если вы делаете предположения о характере id: s вы можете быть в беде (например, если вы манипулируете идентификатором: s непосредственно в графическом интерфейсе или сортировать элементы на основе идентификаторов). Это может быть неприятным сюрпризом, когда вам нужно загрузить баланс своей БД и в итоге получить отдельные диапазоны идентификаторов.

• Повторное использование идентификатора. Например, MySql: s двигатель InnoDB сбрасывает последовательности после перезапуска (до последнего максимального значения). Это может укусить вас, если вы удаляете.

Но все эти gotchas применимы и к пользовательским id: s, но, вероятно, они происходят из этих людей. Наиболее гибким решением в моих глазах является GUID: s, потому что вы можете генерировать их в любом месте и не сталкиваться ни с одной из вышеупомянутых проблем. Их труднее читать для людей, хотя, так что это компромисс.

Ответ 4

Да, вы, вероятно, должны.

Если пользователь злонамеренно изменяет эти идентификаторы, проверяет ли ваш код, чтобы убедиться, что данные, которые они запрашивают, являются данными, которые им разрешено видеть?

Легче скрыть идентификатор, чем вручную выполнить валидацию по всему месту.

Редактируйте с ясностью на этот раз:

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

Если вы используете суррогатные идентификаторы, это становится проще, я думаю.

Ответ 5

Вам следует скрыть идентификаторы базы данных от пользователей

Почему? Это деталь реализации, которую им (пользователю) не нужно беспокоиться. Я ID 123311122? Какая разница! (Если, возможно, я на ICQ). Посмотрите, как SO минимизирует (но не устраняет) экспозицию, например.

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

Говоря это, если ваша фреймворк не предоставляет средства для обработки "скрытия идентификаторов" или иным образом обеспечивает чистое сопоставление, тогда просто не стоит его переходить.

Ответ 6

Я бы сказал, что если этот идентификатор имеет какой-то смысл для пользователя, и вы имеете дело с чувствительным к данным приложением, вы должны скрыть значение идентификатора. Что еще более важно, я бы рекомендовал вам проверить, имеет ли текущий пользователь доступ к данным, запрашиваемым через URL. Например, если у вас есть URL-адрес, например, mysite.com/account/view/12, имеет ли текущий пользователь доступ к идентификатору учетной записи (т.е. 12).

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

Ответ 7

Мне не нравится публиковать что-либо, что говорит о внутренних данных для пользователей, однако обычно это всегда происходит, особенно когда дело касается создания выпадающих списков на основе источника данных. Мое решение состоит в том, чтобы иметь разные идентификационные спецификации на таблицах, чтобы устранить приращения приращения и, где возможно, зашифровать значения querystring. Это не всегда возможно, учитывая очень популярные шаблоны URL MVC в .NET, поэтому я, как правило, использую уникальное имя столбца, а затем нормализую его для URL. Затем я просматриваю это значение в базе данных. Там нет простого способа обойти его полностью.

Ответ 8

"Мне говорят, что я не должен использовать идентификаторы базы данных непосредственно в HTML-коде в веб-приложениях. ... Вы обфускаете идентификаторы от пользователя? "

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

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

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

Ответ 9

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

Например, рассмотрите mysite/products.aspx? id = 25 vs mysite/products/ferrari. Последний чище, легче запоминается (для пользователей) и т.д.

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

Ответ 10

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

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

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

В то время, когда сеть была такой же прозрачной, как сегодня, трудно найти другое ее использование, кроме того, что она использовалась для сокращения URI: s, то есть видеостраницы Youtube и бесчисленное URI-сокращение услуги.

Ответ 11

В качестве примера "публикации" идентификатора для общественности, посмотрите на URL для этой записи.

Я попробовал https://stackoverflow.com/questions/1, но похоже, что он был удален. Вы должны перейти к При применении непрозрачности к форме мы должны использовать десятичное или двойное значение?, чтобы найти "первый" порядковый вопрос; )

... никакого вреда не сделано, просто ссылка на другое сообщение.

Ответ 12

Если вы решите защищать идентификаторы строк в скрытых полях, вы можете посмотреть на книгу Стива Сандерсона asp.net mvc на странице 415, где он представляет класс полезности для HMAC (Hashing Message Authentication Code) для этой цели. Это .NET, конечно, но вы можете получить эту идею. Вы можете увидеть это в Google Книгах, (Сандерсон написал о лучшей книге программирования, которую я прочитал).

Когда я помещаю идентификаторы строк в html, а бизнес-модель говорит, что пользователь должен иметь доступ к определенному набору строк, например те, которые он вставил, я мог бы создать таблицу db для включения столбца идентификатора пользователя и включить его в любые операции db (псевдокод: где @rowID = table.rowID AND @userID = table.userID). Таким образом, если другой пользователь-пользователь взломает идентификаторы rowID в скрытых полях, операция db не позволит им увидеть другие пользовательские данные, потому что пользовательские идентификаторы не совпадут. Конечно, этот подход предполагает, что вы используете аутентификацию какого-то типа, и она также не была взломана.