ASP.NET MVC - CSRF -angrep

Det er en type angrep som vi er utsatt for, og som vi ofte overser, dette er Forfalskning på tvers av sider eller CSRF, er dette ansvarlig for å lure applikasjonen vår til å motta data som ikke kommer fra domenet der den er vert.
Denne typen angrep er ganske skadelig siden den får en bruker som har blitt lurt til å bruke autentiseringen sin til å legge inn data i databasen vår, tenk at med et angrep av denne typen administreres en administrativ bruker eller kanskje falske nyheter i vår nyhetsseksjon .
Som vi forklarte, lurer dette angrepet vår applikasjon for å motta data som ikke kommer fra seg selv, for dette utnytter den måten protokollene fungerer som HTTP og dens forskjellige metoder, og dermed kan en angriper lag et skjema og pek på kontrolleren vår.
For å illustrere dette angrepet, la oss se på følgende kontroller som er sårbar for denne typen angrep:

Her kan vi se hvordan vi henter dataene direkte fra skjemaet vårt, og dette er ikke dårlig, det eneste problemet er at vi ikke forteller applikasjonen vår at den må validere opprinnelsen, med dette kan en angriper generere et skript som følgende:

FORSTØRRE

Her er det klart hva som skjer, når du laster denne siden, sendes skjemaet som peker til en bestemt post i databasen, dette skjemaet peker til en gyldig kontroller, så hvis en godkjent bruker blir dirigert til denne siden, er vi sannsynligvis i en litt av et bind.
Til tross for hvor fatalistisk det kan være, kan dette angrepet unngås, for dette trenger vi bare å gjøre noen valideringer som garanterer at de mottatte dataene kommer fra applikasjonen vår, for dette kan vi bruke noen av disse teknikkene:
DomenereferanseDette består av å bekrefte hvilket domene forespørselen kommer fra, med dette garanterer vi at det er bare fra domenet der applikasjonen vår er vert, det eneste problemet eller ulempen er at hvis vi overfører domeneapplikasjonen vår, må vi kanskje bygge om valideringen i tilfelle vi har ikke gjort dynamisk. Det er også mulig å lage en falsk referanse ved å dra fordel av applikasjonssårbarheter som Adobe Flash.
Generert tokenMed dette alternativet er det vi gjør at det i vår form a token som er unik per bruker, så vår søknad når vi mottar skjemaene bekrefter at tokenet er det samme, på denne måten lar det dataene bli akseptert eller ikke. Dette er det mest brukte alternativet, da det er veldig enkelt å implementere og har små eller ingen ulemper.
Når det gjelder det genererte tokenet ASP.NET MVC inneholder noen metoder som kan hjelpe oss, den viktigste er @ Html.AntiForgeryToken () som genererer den hemmelige nøkkelen som søknaden vår kan validere skjemaene med.
Vi ser da at det er flere områder enn vi tror og at vi må ta vare på i søknadene våre, så vi må informere oss selv og være klar over hvordan angrep skjer for å finne ut måter å unngå dem.