ASP.NET MVC - CSRF атака

Има един вид атака, към която сме склонни и която много пъти пренебрегваме, това е Фалшифициране на заявки между сайтове или CSRF, това е отговорно за подвеждането на нашето приложение да получава данни, които не идват от домейна, където се хоства.
Този тип атака е доста вреден, тъй като кара потребител, който е бил измамен да използва удостоверяването си, за да въведе данни в нашата база данни, представете си, че с атака от този тип административен потребител или може би фалшиви новини се успява да влезе в нашия раздел с новини .
Както обяснихме, тази атака подвежда нашето приложение да получава данни, които не идват от само себе си, за това се възползва от начина, по който протоколите работят като HTTP и неговите различни методи, поради което нападателят може създайте формуляр и посочете нашия контролер.
За да илюстрираме тази атака, нека разгледаме следния контролер, който е уязвим за този тип атака:

Тук можем да видим как получаваме данните директно от нашата форма и това не е лошо, единственият проблем е, че не казваме на нашето приложение, че трябва да потвърди своя произход, с това нападателят може да генерира скрипт като следния:

Увеличете

Тук е ясно какво се случва, когато се зарежда тази страница, се изпраща формулярът, който сочи към конкретен запис в базата данни, този формуляр сочи към валиден контролер, така че ако удостоверен потребител е насочен към тази страница, ние вероятно сме в малко обвързване.
Независимо колко фатално може да бъде, тази атака може да бъде избегната, за това трябва само да направим някои проверки, които гарантират, че получените данни идват от нашето приложение, за това можем да използваме някои от тези техники:
Препратка към домейнТова се състои в проверка от кой домейн идва заявката, като с това гарантираме, че то е само от домейна, където се хоства нашето приложение, единственият проблем или недостатък е, че ако мигрираме нашето приложение за домейн, може да се наложи да възстановим валидирането в случай, че не сме направили динамични. Възможно е също така да се направи фалшива препратка, като се възползвате от уязвимостите на приложението, като например Adobe Flash.
Генериран жетонС тази опция правим, че в рамките на нашата форма a жетон което е уникално за потребителя, така че нашето приложение при получаване на формулярите потвърждава, че маркерът е един и същ, по този начин позволява да се приемат данните или не. Това е най -широко използваният вариант, тъй като е много лесен за изпълнение и има малки или никакви недостатъци.
В случай на генерирания знак ASP.NET MVC съдържа някои методи, които могат да ни помогнат, основният е @ Html.AntiForgeryToken () който генерира секретния ключ, чрез който нашето приложение може да валидира формулярите.
Виждаме тогава, че има повече области, отколкото си мислим, и че трябва да се погрижим в нашите приложения, затова трябва да се информираме и да сме наясно как се случват атаките, за да измислим начини да ги избегнем.