小編給大家分享一下ASP.NET MVC如何防止跨站請(qǐng)求偽造CSRF攻擊，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

成都創(chuàng)新互聯(lián)是一家專業(yè)提供奉新企業(yè)網(wǎng)站建設(shè),專注與做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)、H5場(chǎng)景定制、小程序制作等業(yè)務(wù)。10年已為奉新眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)絡(luò)公司優(yōu)惠進(jìn)行中。

在HTTP POST請(qǐng)求中，我們多次在View和Controller中看下如下代碼：

1.View中調(diào)用了Html.AntiForgeryToken()。

2.Controller中的方法添加了[ValidateAntiForgeryToken]注解。

這樣看似一對(duì)的寫(xiě)法其實(shí)是為了避免引入跨站請(qǐng)求偽造（CSRF）攻擊。

這種攻擊形式大概在2001年才為人們所認(rèn)知，2006年美國(guó)在線影片租賃網(wǎng)站Netflix爆出多個(gè)CSRF漏洞，2008年流行的視頻網(wǎng)址YouTube受到CSRF攻擊，同年墨西哥一家銀行客戶受到CSRF攻擊，殺毒廠商McAfee也曾爆出CSRF攻擊（引自wikipedia）。

之所以很多大型網(wǎng)址也遭遇CSRF攻擊，是因?yàn)镃SRF攻擊本身的流程就比較長(zhǎng)，很多開(kāi)發(fā)人員可能在幾年的時(shí)間都沒(méi)遇到CSRF攻擊，因此對(duì)CSRF的認(rèn)知比較模糊，沒(méi)有引起足夠的重視。

CSRF攻擊的模擬示例

我們這里將通過(guò)一個(gè)模擬的示例，講解CSRF的攻擊原理，然后再回過(guò)頭來(lái)看下MVC提供的安全策略。

看似安全的銀行轉(zhuǎn)賬頁(yè)面

假設(shè)我們是銀行的Web開(kāi)發(fā)人員，現(xiàn)在需要編寫(xiě)一個(gè)轉(zhuǎn)賬頁(yè)面，客戶登錄后在此輸入對(duì)方的賬號(hào)和轉(zhuǎn)出的金額，即可實(shí)現(xiàn)轉(zhuǎn)賬：

[Authorize]
public ActionResult TransferMoney()
{
 return View();
}
[HttpPost]
[Authorize]
public ActionResult TransferMoney(string ToAccount, int Money)
{
 // 這里放置轉(zhuǎn)賬業(yè)務(wù)代碼
 ViewBag.ToAccount = ToAccount;
 ViewBag.Money = Money;
 return View();
}

由于這個(gè)過(guò)程需要身份驗(yàn)證，所以我們?yōu)門(mén)ransferMoney的兩個(gè)操作方法都加上了注解[Authorize]，以阻止匿名用戶的訪問(wèn)。

如果直接訪問(wèn)http://localhost:55654/Home/TransferMoney，會(huì)跳轉(zhuǎn)到登錄頁(yè)面：

登錄后，來(lái)到轉(zhuǎn)賬頁(yè)面，我們看下轉(zhuǎn)賬的視圖代碼：

@{
 ViewBag.Title = "Transfer Money";
}
 
Transfer Money
 
@if (ViewBag.ToAccount == null)
{
 using (Html.BeginForm())
 {
 
 
 
 }
}
else
{
 @:您已經(jīng)向賬號(hào) [@ViewBag.ToAccount] 轉(zhuǎn)入 [@ViewBag.Money] 元！
}

視圖代碼中有一個(gè)邏輯判斷，根據(jù)ViewBag.ToAccount是否為空來(lái)顯示不同內(nèi)容：

1.ViewBag.ToAccount為空，則表明是頁(yè)面訪問(wèn)。

2.ViewBag.ToAccount不為空，則為轉(zhuǎn)賬成功，需要顯示轉(zhuǎn)賬成功的提示信息。

來(lái)看下頁(yè)面運(yùn)行效果：

功能完成！看起來(lái)沒(méi)有任何問(wèn)題，但是這里卻又一個(gè)CSRF漏洞，隱蔽而難于發(fā)現(xiàn)。

我是黑客，Show me the money

這里就有兩個(gè)角色，銀行的某個(gè)客戶A，黑客B。

黑客B發(fā)現(xiàn)了銀行的這個(gè)漏洞，就寫(xiě)了兩個(gè)簡(jiǎn)單的頁(yè)面，頁(yè)面一（click_me_please.html）：

 


 
 哈哈，逗你玩的！
 
 
 

第一個(gè)頁(yè)面僅包含了一個(gè)隱藏的iframe標(biāo)簽，指向第二個(gè)頁(yè)面（click_me_please_iframe.html）：

第二個(gè)頁(yè)面放置了一個(gè)form標(biāo)簽，并在里面放置了黑客自己的銀行賬號(hào)和轉(zhuǎn)賬金額，在頁(yè)面打開(kāi)時(shí)提交表單（body的onload屬性）。

現(xiàn)在黑客把這兩個(gè)頁(yè)面放到公網(wǎng)：

http://fineui.com/demo_mvc/csrf/click_me_please.html

然后批量向用戶發(fā)送帶有攻擊鏈接的郵件，而銀行的客戶A剛好登錄了銀行系統(tǒng)，并且手賤點(diǎn)擊了這個(gè)鏈接：

然后你將看到這個(gè)頁(yè)面：

你可能會(huì)在心里想，誰(shuí)這么無(wú)聊，然后郁悶的關(guān)閉了這個(gè)頁(yè)面。之后客戶A會(huì)更加郁悶，因?yàn)楹诳虰的銀行賬號(hào)[999999999]已經(jīng)成功多了3000塊錢(qián)！

到底怎么轉(zhuǎn)賬的，不是有身份驗(yàn)證嗎

是的。轉(zhuǎn)賬的確是需要身份驗(yàn)證，現(xiàn)在的問(wèn)題是你登錄了銀行系統(tǒng)，已經(jīng)完成了身份驗(yàn)證，并且在瀏覽器新的Tab中打開(kāi)了黑客的鏈接，我們來(lái)看下到底發(fā)生了什么：

這里有三個(gè)HTTP請(qǐng)求，第一個(gè)就是[逗你玩]頁(yè)面，第二個(gè)是里面的IFrame頁(yè)面，第三個(gè)是IFrame加載完畢后發(fā)起的POST請(qǐng)求，也就是具體的轉(zhuǎn)賬頁(yè)面。因?yàn)镮Frame是隱藏的，所以用戶并不知道發(fā)生了什么。

我們來(lái)具體看下第三個(gè)請(qǐng)求：

明顯這次轉(zhuǎn)賬是成功的，并且Cookie中帶上了用戶身份驗(yàn)證信息，所有后臺(tái)根本不知道這次請(qǐng)求是來(lái)自黑客的頁(yè)面，轉(zhuǎn)賬成功的返回內(nèi)容：

如何阻止CSRF攻擊

從上面的實(shí)例我們可以看出，CSRF源于表單身份驗(yàn)證的實(shí)現(xiàn)機(jī)制。

由于HTTP本身是無(wú)狀態(tài)的，也就是說(shuō)每一次請(qǐng)求對(duì)于Web服務(wù)器來(lái)說(shuō)都是全新的，服務(wù)器不知道之前請(qǐng)求的任何狀態(tài)，而身份驗(yàn)證需要我們?cè)诘诙卧L問(wèn)時(shí)知道是否登錄的狀態(tài)（不可能每次請(qǐng)求都驗(yàn)證賬號(hào)密碼），這本身就是一種矛盾！

解決這個(gè)矛盾的辦法就是Cookie，Cookie可以在瀏覽器中保存少量信息，所以Forms Authentication就用Cookie來(lái)保存加密過(guò)的身份信息。而Cookie中保存的全部值在每次HTTP請(qǐng)求中（不管是GET還是POST，也不管是靜態(tài)資源還是動(dòng)態(tài)資源）都會(huì)被發(fā)送到服務(wù)器，這也就給CSRF以可乘之機(jī)。

所以，CSRF的根源在于服務(wù)器可以從Cookie中獲知身份驗(yàn)證信息，而無(wú)法得知本次HTTP請(qǐng)求是否真的是用戶發(fā)起的。

Referer驗(yàn)證

Referer是HTTP請(qǐng)求頭信息中的一部分，每當(dāng)瀏覽器向服務(wù)器發(fā)送請(qǐng)求時(shí)，都會(huì)附帶上Referer信息，表明當(dāng)前發(fā)起請(qǐng)求的頁(yè)面地址。

一個(gè)正常的轉(zhuǎn)賬請(qǐng)求，我們可以看到Referer和瀏覽器地址欄是一致的：

我們?cè)賮?lái)看下剛才的黑客頁(yè)面：

可以看到Referer的內(nèi)容和當(dāng)前發(fā)起請(qǐng)求的頁(yè)面地址一樣，注意對(duì)比：

1.瀏覽器網(wǎng)址：click_me_please.html

2.HTTP請(qǐng)求地址：Home/TransferMoney

3.Referer：click_me_please_iframe.html，注意這個(gè)是發(fā)起請(qǐng)求的頁(yè)面，而不一定就是瀏覽器地址欄顯示的網(wǎng)址。

基于這個(gè)原理，我們可以簡(jiǎn)單的對(duì)轉(zhuǎn)賬的POST請(qǐng)求進(jìn)行Referer驗(yàn)證：

[HttpPost]
[Authorize]
public ActionResult TransferMoney(string ToAccount, int Money)
{
 if(Request.Url.Host != Request.UrlReferrer.Host)
 {
 throw new Exception("Referrer validate fail!");
 }
 
 // 這里放置轉(zhuǎn)賬業(yè)務(wù)代碼
 
 ViewBag.ToAccount = ToAccount;
 ViewBag.Money = Money;
 return View();
}

此時(shí)訪問(wèn)http://fineui.com/demo_mvc/csrf/click_me_please.html，惡意轉(zhuǎn)賬失敗：

MVC默認(rèn)支持的CSRF驗(yàn)證

MVC默認(rèn)提供的CSRF驗(yàn)證方式更加徹底，它通過(guò)驗(yàn)證當(dāng)前請(qǐng)求是否真的來(lái)自用戶的操作。

在視圖頁(yè)面，表單內(nèi)部增加對(duì)Html.AntiForgeryToken函數(shù)的調(diào)用：

@if (ViewBag.ToAccount == null)
{
 using (Html.BeginForm())
 {
 @Html.AntiForgeryToken()
 
 
 
 }
}
else
{
 @:您已經(jīng)向賬號(hào) [@ViewBag.ToAccount] 轉(zhuǎn)入 [@ViewBag.Money] 元！
}

這會(huì)在表單標(biāo)簽里面和Cookie中分別生成一個(gè)名為_(kāi)_RequestVerificationToken 的Token：

然后添加[ValidateAntiForgeryToken]注解到控制器方法中：

[HttpPost]
[Authorize]
[ValidateAntiForgeryToken]
public ActionResult TransferMoney(string ToAccount, int Money)
{
 // 這里放置轉(zhuǎn)賬業(yè)務(wù)代碼
 ViewBag.ToAccount = ToAccount;
 ViewBag.Money = Money;
 return View();
}

在服務(wù)器端，會(huì)驗(yàn)證這兩個(gè)Token是否一致（不是相等），如果不一致就會(huì)報(bào)錯(cuò)。

下面手工修改表單中這個(gè)隱藏字段的值，來(lái)看下錯(cuò)誤提示：

類(lèi)似的道理，運(yùn)行黑客頁(yè)面http://fineui.com/demo_mvc/csrf/click_me_please.html，惡意轉(zhuǎn)賬失?。?/p>

此時(shí)，雖然Cookie中的__RequestVerificationToken提交到了后臺(tái)，但是黑客無(wú)法得知表單字段中的__RequestVerificationToken值，所以轉(zhuǎn)賬失敗。

以上是“ASP.NET MVC如何防止跨站請(qǐng)求偽造CSRF攻擊”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

網(wǎng)站標(biāo)題：ASP.NETMVC如何防止跨站請(qǐng)求偽造CSRF攻擊-創(chuàng)新互聯(lián)
當(dāng)前地址：http://weahome.cn/article/ccijss.html