A CSRF támadások megelőzése érdekében asp.net mvc biztosítja a ValidateAntiForgeryToken hamisítás elleni támadás funkciót, míg a asp.net alap új verziójában a Microsoft az AutoValidateAntiforgeryToken funkciót kínálja, különösen a ValidateAntiForgeryToken és AutoValidateAntiforgeryToken funkciókat Mi a különbség, ezt a cikk részletesen elmagyarázza.
CSRF koncepció
A CSRF Cross-Site Request Hamisítás, akárcsak az XSS támadások, rendkívül káros, így érthető: a támadó ellopja az identitásodat, és rosszindulatú kérést küld a nevedre, ami teljesen jogos a szerver számára, de végrehajt egy olyan cselekvést, amit a támadó vár, például e-maileket és üzeneteket küld a nevedben, lopja el a fiókodat, rendszergazdákat ad hozzá vagy akár árut vásárol. virtuális pénzátutalások stb. A Web A egy CSRF sebezhetőséggel rendelkező weboldal, a Web B egy támadó által készített rosszindulatú weboldal, és a C felhasználó a Web A legitim felhasználója.
ASP.NET MVC a CSRF támadások ellen
A megtekintési oldalon a @Html.AntiForgeryToken() billentyűt használd egy címkéhez, és amikor a felhasználó eléri az oldalt, a háttérrendszer automatikusan generál egy rejtett html kódot a címkével, a következők szerint:
<input name="__RequestVerificationToken" type="rejtve" value="CfDJ8FBn4LzSYglJpE6Q0fWvZ8WDMTgwK49lDU1XGuP5-5j4JlSCML_IDOO3XDL5EOyI_mS2Ux7lLSfI7ASQnIIxo2ScEJvnABf9v51TUZl_iM2S63zuiPK4lcXRPa_KUUDbK-LS4HD16pJusFRppj-dEGc" />
A ValidateAntiForgeryToken és az AutoValidateAntiforgeryToken eltérnek
Az AutoValidateAntiforgeryTokenAuthorizationFilter örökli a ValidateAntiforgeryTokenAuthorizationFilter-t, de csak a ShouldValidate metóduszot írja át benne.
AutoValidantiforgeryToken tulajdonság, amely minden nem biztonságos HTTP módszer esetén hamisítás elleni tokeneket validál.A GET, HEAD, OPTIONS és TRACE (GET, HEAD, OPTIONS) és TRACE nélküli HTTP módszerek mind hamisításellenes tokent igényelnek。 Ez globális szűrőként alkalmazható, hogy alapértelmezés szerint elindítsa az alkalmazás hamisításellenes token validációját.
A hiperlink bejelentkezés látható.
AutoValidateAntiforgeryTokenAttribute érvényesíti az AutoValidateAntiforgeryTokenAuthorizationFilter hívását, amely a következőktől örököl ValidateAntiforgeryTokenAuthorizationFilter,A ShouldValidate módszert átírták, a true visszaadása azt jelenti, hogy ellenőrizni kell, és a hamisat visszaadás nem lesz validálva., ahogy az alábbi ábrán látható:
Elemezze a forráskódot:
Az AutoValidantiforgeryTokenAttribute lehetővé teszi, hogy hamisítás elleni token validáció globális alkalmazásra kerüljön minden nem biztonságos módszerre, mint például a POST, PUT, PATCH és DELETE. Így nem kell minden olyan művelethez hozzáadnod a [ValidateAntiForgeryToken] tulajdonságot, amely megköveteli.
A használatához add hozzá a következő kódot a ConfigureServices Startup osztály metódusához:
Ha figyelmen kívül kell hagynod a hamisítás elleni hitelesítést, hozzáadhatod [Figyelmen kívül hagydAntiforgeryTokentulajdonítsa a cselekedetet.
Néha előfordulhat, hogy több kérést kell címkézni egy kontrolleren, miközben olyan kérésekre van szükséged, amelyeket nem kell hamisítani, például különféle GET-alapú műveleteket. Számos eszköz létezik, hogy kényelmesebbé és kényelmesebbé tegye a folyamatot. Az első az AutoValidatedAntiforgeryToken tulajdonság. Úgy viselkedik, mint a ValidateAntiForgeryToken tulajdonság. Azonban automatikusan figyelmen kívül hagyja az adatlekérésre tervezett metódusok által meghívott műveleteket: GET, HEAD, OPTIONS és TRACE. Ez lehetővé teszi, hogy hamisítás elleni módszereket gyorsan és könnyen hozzáadj minden olyan módszerhez, amely képes adatokat megváltoztatni anélkül, hogy befolyásolná az adatok visszanyerését.
Az alábbi kód az AutoValidateAntiforgeryToken tulajdonság példája:
Ebben a példában mindkét normál Index művelet (GET) működik a forrástól függetlenül, míg mind az Index művelet a POST metódussal, mind a RemoveUser művelet Delete metódusként megköveteli a kliens egy hamisításellenes tokent használni.
Testreszabni a releváns információkat
Sokan elgondolkodhatnak rajta, hogy a generált rejtett domain nevét fel lehet-e cserélni a sajátjukra, és hogy a süti nevét is megváltoztathatjuk-e sajátjukra.
A válasz igen, mutassuk be röviden:
A startup ConconfigServices metódusában add hozzá a következőket, hogy ennek megfelelően módosítsuk az alapértelmezett nevet.
Megjegyzés: A legnagyobb különbség asp.net mag és asp.net között az,A Core támogatja az érvényesítési paraméterek továbbítását fejléc kérésével, nem formák kialakítására!
private const string AntiforgeryTokenFieldName = "__RequestVerificationToken";
private const string AntiforgeryTokenHeaderName = "RequestVerificationToken";
A forráskódot megtekintheted:A hiperlink bejelentkezés látható.
Tesztkód:
Eredmény: A test1 metódushoz való hozzáférés 400-as hibát ad, a test2 metódus elérése visszaadja az átadott str paramétert, és látható, hogy az AutoValidateAntiforgeryToken funkció nem fogja el a GET kérést.
(Vége)
|
Közzétéve 2021. 02. 20. 19:57:29
|
|
|
|
Háziúr|
Közzétéve 2023. 07. 08. 22:07:08
|
