Столбцы идентификации и безопасность в веб-приложении RESTful

Question

Вопрос

Должны ли столбцы идентификаторов с автоинкрементом иметь начальное значение / приращение не по умолчанию при использовании в веб-приложении RESTful?

Фон

Я работаю над своим первым приложением ASP.NET MVC и пытаюсь сохранить URL-адреса RESTful. Для приложения нет отдельного административного веб-сайта. Я использую атрибуты, чтобы контролировать, кто может получить доступ к каким частям сайта и какие пункты меню видны текущему пользователю в зависимости от их ролей в системе. Я (в основном) следую шаблону ActiveRecord DB и использую синтетические идентификаторы для своих таблиц, включая таблицу пользователей, где идентификаторы являются автоматически генерируемыми столбцами идентификаторов.

Сегодня утром мне пришло в голову, что существует небольшая угроза безопасности при использовании начальных значений по умолчанию для столбцов идентификаторов в приложении RESTful. Если вы предполагаете, что административные идентификаторы, особенно наиболее мощные, обычно создаются в приложении первыми, то из этого следует, что они будут идентификаторами с наименьшим номером в системе. Несмотря на то, что на самом деле не открываются дыры в приложении, использование значений по умолчанию для начального числа / приращения может помочь взломщику атаковать цель с высоким значением, просто нацеливая идентификаторы с низким номером с помощью действий RESTful (таких как ChangePassword - который является одним из готовые действия в шаблоне сайта ASP.NET MVC).

Должен ли я добавить установку не по умолчанию начального числа, по крайней мере, в мою таблицу пользователей в свой арсенал рекомендаций по безопасности? Стоит ли этого делать? Или я слишком параноик? Как связанный вопрос, должен ли я менять готовые имена шаблонов для действий, связанных с учетной записью.

Answer 1

Мой совет - использовать GUID вместо идентификаторов с автоинкрементом. Это полностью избавляет от "игры в угадайку".

Answer 2

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

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

Answer 3

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

Answer 4

Я очень скептически относился к использованию Guid's; однако, как указывает Люцерно, это помогает минимизировать игру в догадки в зависимости от того, как создается и используется Guid. Руководства, сгенерированные с использованием последовательного из SQL Server, не помешают, например, игре в угадайку.

Руководства также очень удобны, если у вас есть модель домена и вы используете ORM, например, nHibernate, или даже используете свою собственную. Поскольку это значительно упрощает сложность вставки обратных ссылок, так как все объекты могут получить свой идентификатор на ранней стадии.

С учетом сказанного, если ваши идентификаторы включены в URL, они должны рассматриваться как общедоступные данные. Даже через HTTPS хитрая атака может получить весь URL. Если ваша страница запрашивает какой-либо сторонний контент, такой как, например, Google Analytics, строку URL-запроса и все, отправляется третьей стороне в качестве реферера, например.