Представление базы данных ID - угроза безопасности?

Отличным способом автоматического создания этих классов для вас является копирование вашего JSON-вывода и его бросок здесь:

http://json2csharp.com/

Он предоставит вам начальную точку, чтобы подправить ваши классы для десериализации.

118
задан orip 16 October 2009 в 06:04
поделиться

6 ответов

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

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

  1. безопасность на уровне ролей Использования для управления доступом к операции. То, как это сделано, зависит от платформы и платформы, которую Вы выбрали, но многие поддерживают декларативную модель обеспечения безопасности, которая автоматически перенаправит браузеры к шагу аутентификации, когда действие потребует некоторых полномочий.
  2. Использование программируемая безопасность для управления доступом к объекту. Это более трудно сделать на уровне платформы. Чаще, это - что-то, что необходимо записать в код, и поэтому более подвержено ошибкам. Эта проверка идет вне основанной на роли проверки путем обеспечения не только, что пользователь имеет полномочия для операции, но также и имеет необходимые права на изменяемом конкретном объекте. В основанной на роли системе легко проверить, что только менеджеры могут дать повышения, но кроме того, необходимо удостовериться, что сотрудник принадлежит отделу конкретного менеджера.
  3. Для большинства записей базы данных, условия 1 и 2 достаточны. Но добавление непредсказуемых идентификаторов может считаться небольшой дополнительной страховкой, или "безопасностью подробно", если Вы вложились в то понятие. Одно место, где непредсказуемые идентификаторы необходимость, однако, находится в идентификаторах сессии или других аутентификационных маркерах, где сам идентификатор аутентифицирует запрос. Они должны быть сгенерированы криптографическим RNG.
95
ответ дан erickson 24 November 2019 в 01:58
поделиться

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

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

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

30
ответ дан John Topley 24 November 2019 в 01:58
поделиться

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

Представление базы данных ID рассчитывает как раскрывающий некоторую информацию.

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

22
ответ дан Arjan Einbu 24 November 2019 в 01:58
поделиться

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

14
ответ дан Joshua 24 November 2019 в 01:58
поделиться

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

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

7
ответ дан John Topley 24 November 2019 в 01:58
поделиться

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

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

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

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

отбрасывания bobby
6
ответ дан krosenvold 24 November 2019 в 01:58
поделиться
Другие вопросы по тегам:

Похожие вопросы: