Документы / ссылки по предотвращению возни HTML-формы? - PullRequest
1 голос
/ 30 апреля 2010

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

Например, если мое приложение имело дело с подержанными автомобилями и имело ссылки для добавления / удаления инвентаря, которые включали в качестве части URL идентификатор пользователя, что я могу сделать, чтобы перехватить попытки изменить ссылку и вставить туда чужой идентификатор ? В этом ограниченном случае я всегда могу запустить проверку на сервере, чтобы убедиться, что ID пользователя XYZ действительно имеет права на автомобильную ABC, но мне было любопытно, какие существуют другие стратегии, чтобы держать ум в страхе. (Возможно, делаете контрольную сумму страницы? Не уверен.)

Спасибо за ваш вклад.

Ответы [ 2 ]

1 голос
/ 30 апреля 2010

Следующее, что вы описываете, является уязвимостью, называемой «Небезопасные прямые ссылки на объекты», и она распознается A4 в Топ-10 OWASP за 2010 год .

что я могу сделать, чтобы перехватить попытки взломать ссылку и поставить чужой ID там?

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

Вот пример системы безопасности, которую я описываю:

"update users set password='new_pass_hash' where user_id='"&Session("user_id")&"'";

Edit:

Другим подходом является Код аутентификации хешированного сообщения . Этот подход намного менее безопасен, чем использование Session, так как он вводит новую схему атаки методом грубой силы вместо того, чтобы избегать проблемы в целом. Hmac позволяет вам увидеть, было ли сообщение изменено кем-то, у кого нет секрета key. Значение hmac может быть рассчитано следующим образом на стороне сервера и затем сохранено как скрытая переменная.

hmac_value=hash('secret'&user_name&user_id&todays_date)

Идея состоит в том, что если пользователь попытается изменить свое имя пользователя или ИД пользователя, то hmac_value будет недействительным, если злоумышленник не сможет получить «секрет», который может быть взломан. Опять же, вам следует избегать этой системы безопасности любой ценой. Хотя иногда у вас нет выбора (у вас есть выбор в вашем примере уязвимости).

1 голос
/ 30 апреля 2010

Вы хотите узнать, как использовать сеанс.

Сеансы на тизтаге.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...