Должен ли я защищать div с помощью входных данных от CSRF

#asp.net #csrf #csrf-protection

#asp.net #csrf #csrf-защита

Вопрос:

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

обычно при кодировании формы она будет защищена от CSRF в ASP.NET использование

 @Html.Antiforgerytoken()
  

Внутри объявления формы на странице razor

Вопрос в том, полезно ли или будет ли работать выполнять ту же процедуру с данным div, который содержит входные данные и кнопку, которая будет выполнять вызов AJAX или нет?

Ответ №1:

Да, решение на стороне клиента не имеет никакого значения. CSRF — это уязвимость на стороне сервера, любой вызов на сервер, который изменяет состояние сервера (в основном, данные, но также такие вещи, как логин, изменения уровня привилегий и т.д.), Уязвим для CSRF, если он не защищен.

В AJAX-запросах вы должны отправить токен самостоятельно. Используя jQuery, вы можете использовать $.ajaxSetup() и beforeSend перехват для захвата любого запроса на изменение состояния и автоматического добавления токена (это относится к сообщениям в целом, но его можно ПОМЕСТИТЬ, УДАЛИТЬ, даже ПОЛУЧИТЬ, если приложение использует GET для изменения материала). Преимущество использования beforeSend заключается в том, что вам нужно сделать это только один раз, и вам больше не нужно это запоминать. Токен в этом случае может быть сгенерирован на странице, @Html.AntiforgeryToken() как обычно, javascript может взять его оттуда.

Немного особый случай — это когда вы отправляете данные json (тип содержимого для запроса application/json — это, и он не закодирован в www-url). Стандартный атрибут [ValidateAntiForgeryToken] не может принимать токен из json (и он также не может принимать его из заголовка запроса, если вы решите, что это лучший вариант для его передачи). В этом случае вы можете реализовать пользовательский атрибут проверки, но это просто, вам нужно только реализовать, откуда получить токен, для фактической проверки вы все равно можете использовать стандартный AntiForgery.Validate() метод.

Комментарии:

1. Большое спасибо, отличное объяснение, и оно имеет смысл (y)