оценка риска безопасности раскрытия идентификатора строки в строке запроса

Question

Является ли угроза безопасности выставлять идентификационный номер строки SQL?

Например, есть событие с идентификатором 12.

Это проблема безопасности, если кто-тообращается к нему через http://example.com/events/12, или кто-то делает POST на http://example.com/events/12, чтобы обновить эту запись (если, конечно, я разрешу это)?

Answer 1

Проблема предоставления идентификаторов пользователям часто упоминается как «небезопасные прямые ссылки на объекты» в контексте веб-безопасности.

С OWASP :

Предотвращение небезопасныхПрямые ссылки на объекты требуют выбора подхода для защиты каждого доступного пользователю объекта (например, номера объекта, имени файла):

1. Использовать косвенные ссылки на объект для пользователя или сеанса.Это предотвращает прямое нападение злоумышленников на неавторизованные ресурсы.Например, вместо использования ключа базы данных ресурса раскрывающийся список из шести ресурсов, авторизованных для текущего пользователя, может использовать цифры от 1 до 6, чтобы указать, какое значение выбрал пользователь.Приложение должно сопоставить косвенную ссылку для каждого пользователя с реальным ключом базы данных на сервере.ESAPI OWASP включает в себя карты ссылок как последовательного, так и произвольного доступа, которые разработчики могут использовать для исключения прямых ссылок на объекты.
2. Проверка доступа.Каждое использование прямой ссылки на объект из ненадежного источника должно включать проверку контроля доступа, чтобы удостовериться, что пользователь авторизован для запрошенного объекта..

Answer 2

Показывать или нет, не имеет значения.

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

У кого-то может быть бот, выплевывающий запросы на http://example/events/x, где x - увеличивающееся число. Возможно, это какой-то подглядывающий сотрудник, пытающийся посмотреть http://payroll/employee/x.

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

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

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

Answer 3

URL-адреса и строки запросов особенно небезопасны, когда вы используете целочисленные идентификаторы.В конце концов, если есть 12, почти наверняка есть 11 или 10. GUID затрудняют угадывание другого элемента, но все же не должны считаться безопасными IMJO.

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