HTTP POST уязвим для изменения?

Question

Мне было интересно, если кто-нибудь знает, может ли произойти следующий сценарий.

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

Теперь мой обработчик проверит response.form и проанализирует productID, затем удалит продукт из базы данных на основе productID.

Возможно, кто-то может изменить сообщение, чтобы разрешить удаление других идентификаторов продуктов, возможно, всего в таблице продуктов, добавив поддельные имена флажков в POST?

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

Я никогда не думал об этом раньше, и удивляюсь, сколько людей на самом деле делают это по умолчанию, или существует миллион веб-сайтов, которые могут быть уязвимыми?

Спасибо

Answer 1

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

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

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

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

Мои $ 0,02

Answer 2

Да, это проблема.То, что вы описываете, является примером риска «Небезопасные прямые ссылки на объекты», как определено в Открытом проекте безопасности веб-приложений (OWASP).

Что касается того, насколько он распространен, он в настоящее время(2011) занимает 4-е место в списке 10 самых серьезных угроз безопасности веб-приложений OWASP.Подробные сведения о том, как предотвратить это, можно найти на странице OWASP .

Как предотвратить небезопасные прямые ссылки на объекты?

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

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

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

Answer 3

Почему бы просто не сравнить полученные значения с предоставленными вами значениями? Пример: Вы установили флажки для пунктов 1, 2 и 3, 9. Пользовательские записи 1, 2, 3, 4, 5, 6. Вы можете найти пересечение списков и удалить их (в данном случае 1, 2 и 3 в обоих списках).