За да се предотвратят CSRF атаки, asp.net mvc предоставя функцията ValidateAntiForgeryToken срещу фалшифициране, а в новата версия на основната рамка asp.net Microsoft предоставя функцията AutoValidateAntiforgeryToken, по-специално ValidateAntiForgeryToken и AutoValidateAntiforgeryToken Каква е разликата, тази статия ще обясни подробно.
Концепция за CSRF
CSRF Cross-Site Request Forgery, подобно на XSS атаките, е изключително вредно, можете да го разберете така: нападателят краде вашата самоличност и изпраща злонамерена заявка от ваше име, която е напълно легитимна за сървъра, но изпълнява действие, което нападателят очаква, като изпращане на имейли и съобщения от ваше име, кражба на акаунта ви, добавяне на системни администратори или дори закупуване на стоки, виртуални валутни трансфери и др. Web A е уебсайт с уязвимост към CSRF, Web B е злонамерен уебсайт, създаден от нападател, а User C е легитимен потребител на Web A.
ASP.NET MVC срещу CSRF атаки
На страницата за изглед използвайте @Html.AntiForgeryToken(), за да добавите таг, и когато потребителят отвори страницата, бекендът автоматично ще генерира скрит html код с този таг, както следва:
<input name="__RequestVerificationToken" type="скрит" value="CfDJ8FBn4LzSYglJpE6Q0fWvZ8WDMTgwK49lDU1XGuP5-5j4JlSCML_IDOO3XDL5EOyI_mS2Ux7lLSfI7ASQnIIxo2ScEJvnABf9v51TUZl_iM2S63zuiPK4lcXRPa_KUUDbK-LS4HD16pJusFRppj-dEGc" />
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:
Ако трябва да игнорирате антифалшифицираната автентикация, можете да добавите [IgnoreAntiforgeryTokenатрибут на действието.
Понякога може да се наложи да тагнеш няколко заявки на контролер, докато са нужни и такива, които не се нуждаят от фалшифициране, като например различни GET-базирани операции. Има няколко инструмента, които можете да използвате, за да направите процеса по-удобен и комфортен. Първият е собствеността AutoValidateAntiforgeryToken. Той се държи като свойството ValidateAntiForgeryToken. Въпреки това, автоматично ще игнорира действията, извиквани от методи, предназначени за извличане на данни: GET, HEAD, OPTIONS и TRACE. Това ви позволява бързо и лесно да добавите методи срещу фалшифициране към всички методи, които могат да променят данните, без да влияят на начина, по който се възстановяват.
Следващият код е пример за свойството AutoValidateAntiforgeryToken:
В този пример и двете нормални Index операции (GET) ще работят независимо от източника, докато както операцията Index с метода POST, така и операцията RemoveUser като метод Delete ще изискват клиентът да използва токен срещу фалшифициране.
Персонализирайте съответната информация
Много хора може да се чудят дали името на генерирания скрит домейн може да бъде заменено с техния собствен и дали името на бисквитката може да бъде променено с тяхно.
Отговорът е да, нека накратко демонстрираме:
В метода ConfigureServices на Startup добавете следното, за да промените името по подразбиране съответно.
Забележка: Най-голямата разлика между asp.net core и asp.net е,Core поддържа предаване на валидационни параметри чрез заявка за заглавие, не за да формирам форми!
private const string AntiforgeryTokenFieldName = "__RequestVerificationToken";
private const string AntiforgeryTokenHeaderName = "RequestVerificationToken";
Можете да видите изходния код:Входът към хиперлинк е видим.
Тестов код:
Резултат: Опитът за достъп до метода test1 връща грешка 400, достъпът до метода test2 връща параметъра str, който преминахме, и можете да видите, че функцията AutoValidateAntiforgeryToken не прихваща заявката GET.
(Край)
|
Публикувано в 20.02.2021 г. 19:57:29 ч.
|
|
|
|
Хазяин|
Публикувано в 8.07.2023 г. 22:07:08 ч.
|
