ASP.NET MVC - CSRF Attack

Det finns en typ av attack som vi är benägna att och som vi många gånger förbiser, detta är Begär förfalskning på flera webbplatser eller CSRF, detta är ansvarigt för att lura vår applikation att ta emot data som inte kommer från domänen där den är värd.
Denna typ av attack är ganska skadlig eftersom det får en användare som har blivit lurad att använda sin autentisering för att mata in data i vår databas, föreställ dig att med en attack av denna typ lyckas en administrativ användare eller kanske falska nyheter gå in i vårt nyhetsavsnitt .
Som vi förklarade lurar denna attack vår applikation för att ta emot data som inte kommer från sig själv, för det drar nytta av det sätt på vilket protokollen fungerar som HTTP och dess olika metoder, och därmed kan en angripare skapa ett formulär och peka på vår controller.
För att illustrera denna attack, låt oss titta på följande kontroller som är sårbar för denna typ av attack:

Här kan vi se hur vi hämtar data direkt från vårt formulär och detta är inte dåligt, det enda problemet är att vi inte säger till vår applikation att den måste validera dess ursprung, med detta kan en angripare generera ett skript som följande:

FÖRSTORA

Här är det klart vad som händer, när du laddar den här sidan skickas formuläret som pekar på en specifik post i databasen, detta formulär pekar på en giltig kontroller, så om en autentiserad användare riktas till den här sidan befinner vi oss förmodligen i en lite av en bindning.
Trots hur fatalistisk det kan vara kan denna attack undvikas, för detta behöver vi bara göra några valideringar som garanterar att den mottagna informationen kommer från vår applikation, för detta kan vi använda några av dessa tekniker:
DomänreferensDetta består av att verifiera vilken domän förfrågan kommer från, med detta garanterar vi att det bara är från domänen där vår applikation är värd, det enda problemet eller nackdelen är att om vi migrerar vår domänapplikation kan vi behöva bygga om valideringen ifall vi har inte gjort dynamiska. Det är också möjligt att göra en falsk referens genom att dra nytta av programproblem som t.ex. Adobe Flash.
Genererat tokenMed det här alternativet är det vi gör i vår form a tecken vilket är unikt per användare, så vår ansökan vid mottagandet av formuläret bekräftar att token är densamma, på så sätt tillåter den att data accepteras eller inte. Detta är det mest använda alternativet eftersom det är mycket enkelt att implementera och har små eller inga nackdelar.
När det gäller den genererade token ASP.NET MVC innehåller några metoder som kan hjälpa oss, den viktigaste är @ Html.AntiForgeryToken () som genererar den hemliga nyckeln genom vilken vår ansökan kan validera formulären.
Vi ser då att det finns fler områden än vi tror och att vi måste ta hand om i våra applikationer, så vi måste informera oss själva och vara medvetna om hur attacker sker för att utforma sätt att undvika dem.