Щоб запобігти атакам CSRF, asp.net mvc надає функцію ValidateAntiForgeryToken проти підробки, а в новій версії asp.net core фреймворку Microsoft надає функції AutoValidateAntiforgeryToken, зокрема ValidateAntiForgeryToken та AutoValidateAntiforgeryToken У чому різниця, детально пояснимо ця стаття.
Концепція CSRF
CSRF Cross-Site Fakery, як і XSS-атаки, є надзвичайно шкідливим, це можна зрозуміти так: зловмисник краде вашу особистість і надсилає шкідливий запит від вашого імені, який є цілком легітимним для сервера, але виконує очікувану дією, наприклад, надсилає електронні листи та повідомлення від вашого імені, крадіжка акаунта, додавання системних адміністраторів або навіть купівля товарів, Віртуальні валютні перекази тощо. Web A — це вебсайт із вразливістю CSRF, Web B — шкідливий сайт, створений зловмисником, а User C — легітимний користувач Web A.
ASP.NET MVC проти атак CSRF
На сторінці перегляду використовуйте @Html.AntiForgeryToken() для додавання тегу, і коли користувач звертається до сторінки, бекенд автоматично згенерує прихований html-код з тегом, наступним чином:
<вхідне ім'я="__RequestVerificationToken" type="прихований" value="CfDJ8FBn4LzSYglJpE6Q0fWvZ8WDMTgwK49lDU1XGuP5-5j4JlSCML_IDOO3XDL5EOyI_mS2Ux7lLSfI7ASQnIIxo2ScEJvnABf9v51TUZl_iM2S63zuiPK4lcXRPa_KUUDbK-LS4HD16pJusFRppj-dEGc" /> Фоновий контролер потрібно встановити [ValidateAntiForgeryToken] функція запобігання підробці форм.
ValidateAntiForgeryToken та AutoValidateAntiforgeryToken відрізняються
AutoValidateAntiforgeryTokenAuthorizationFilter успадковує ValidateAntiforgeryTokenAuthorizationFilter, але переписує лише метод ShouldValidate у ньому.
Властивість AutoValidateAntiforgeryToken, яка забезпечує валідацію токенів проти підробок для всіх незахищених HTTP-методів.HTTP-методи, окрім GET, HEAD, OPTIONS та TRACE, вимагають токена для захисту від підробок。 Це можна застосувати як глобальний фільтр для запуску валідації токена проти підробок за замовчуванням.
Вхід за гіперпосиланням видно.
AutoValidateAntiforgeryTokenAttribute перевіряє виклик AutoValidateAntiforgeryTokenAuthorizationFilter, який успадковує з ValidateAntiforgeryTokenAuthorizationFilter,Метод ShouldValidate було переписано, повернення true означає, що його потрібно перевірити, а повернення false не буде підтверджено, як показано на рисунку нижче:
Проаналізуйте вихідний код:
AutoValidateAntiforgeryTokenAttribute дозволяє глобально застосовувати валідацію токенів проти підробки до всіх незахищених методів, таких як POST, PUT, PATCH і DELETE. Тож вам не потрібно додавати властивість [ValidateAntiForgeryToken] до кожної дії, яка її вимагає.
Щоб скористатися ним, додайте наступний код до методу класу запуску ConfigureServices:
Якщо потрібно ігнорувати автентифікацію проти підробки, ви можете додати [Ігнорувати AntiforgeryTokenАтрибут дії.
Іноді вам може знадобитися тегувати кілька запитів на контролері, а деякі запити не потребують підробки, наприклад, різні операції на основі GET. Існує кілька інструментів, які допоможуть зробити процес зручнішим і комфортнішим. Перша — це властивість AutoValidateAntiforgeryToken. Він поводиться як властивість ValidateAntiForgeryToken. Однак він автоматично ігноруватиме дії, викликані методами, призначеними для отримання даних: GET, HEAD, OPTIONS та TRACE. Це дозволяє швидко та легко додавати методи протидії підробкам до всіх методів, які можуть змінювати дані, не впливаючи на спосіб їх отримання.
Наступний код є прикладом властивості AutoValidateAntiforgeryToken:
У цьому прикладі обидві звичайні операції Index (GET) працюватимуть незалежно від джерела, тоді як операції Index з методом POST і RemoveUser як метод Delete вимагатимуть від клієнта використання токена проти підробки.
Налаштуйте відповідну інформацію
Багато людей можуть замислюватися, чи можна замінити назву згенерованого прихованого домену на їхню власну, і чи можна змінити назву cookie на їхню власну.
Відповідь — так, давайте коротко продемонструємо:
У методі ConfigureServices Startup додайте наступне, щоб відповідно змінити ім'я за замовчуванням.
Примітка: Найбільша різниця між asp.net ядром і asp.net полягає в тому,Core підтримує передачу параметрів валідації шляхом запиту заголовка, не формувати форми!
private const string AntiforgeryTokenFieldName = "__RequestVerificationToken"; private const string AntiforgeryTokenHeaderName = "RequestVerificationToken";
Ви можете переглянути вихідний код:Вхід за гіперпосиланням видно.
Тестовий код:
Результат: Спроба отримати доступ до методу test1 повертає помилку 400, доступ до методу test2 повертає параметр str, який ми пройшли, і ви бачите, що функція AutoValidateAntiforgeryToken не перехоплює запит GET.
(Кінець)
|