淺談ASP.NET MVC 防止跨站請(qǐng)求偽造(CSRF)攻擊的實(shí)現(xiàn)方法
在HTTP POST請(qǐng)求中，我們多次在View和Controller中看下如下代碼：
1.View中調(diào)用了Html.AntiForgeryToken()。
2.Controller中的方法添加了[ValidateAntiForgeryToken]注解。
這樣看似一對(duì)的寫法其實(shí)是為了避免引入跨站請(qǐng)求偽造（CSRF）攻擊。
這種攻擊形式大概在2001年才為人們所認(rèn)知，2006年美國在線影片租賃網(wǎng)站Netflix爆出多個(gè)CSRF漏洞，2008年流行的視頻網(wǎng)址YouTube受到CSRF攻擊，同年墨西哥一家銀行客戶受到CSRF攻擊，殺毒廠商McAfee也曾爆出CSRF攻擊（引自wikipedia）。
之所以很多大型網(wǎng)址也遭遇CSRF攻擊，是因?yàn)镃SRF攻擊本身的流程就比較長，很多開發(fā)人員可能在幾年的時(shí)間都沒遇到CSRF攻擊，因此對(duì)CSRF的認(rèn)知比較模糊，沒有引起足夠的重視。
CSRF攻擊的模擬示例
我們這里將通過一個(gè)模擬的示例，講解CSRF的攻擊原理，然后再回過頭來看下MVC提供的安全策略。
看似安全的銀行轉(zhuǎn)賬頁面
假設(shè)我們是銀行的Web開發(fā)人員，現(xiàn)在需要編寫一個(gè)轉(zhuǎn)賬頁面，客戶登錄后在此輸入對(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è)過程需要身份驗(yàn)證，所以我們?yōu)門ransferMoney的兩個(gè)操作方法都加上了注解[Authorize]，以阻止匿名用戶的訪問。
如果直接訪問http://localhost:55654/Home/TransferMoney，會(huì)跳轉(zhuǎn)到登錄頁面：
登錄后，來到轉(zhuǎn)賬頁面，我們看下轉(zhuǎn)賬的視圖代碼：
@{
ViewBag.Title = "Transfer Money";
}
<h2>Transfer Money</h2>
@if (ViewBag.ToAccount == null)
{
using (Html.BeginForm())
{
<input type="text" name="ToAccount" />
<input type="text" name="Money" />
<input type="submit" value="轉(zhuǎn)賬" />
}
}
else
{
@:您已經(jīng)向賬號(hào) [@ViewBag.ToAccount] 轉(zhuǎn)入 [@ViewBag.Money] 元！
}
視圖代碼中有一個(gè)邏輯判斷，根據(jù)ViewBag.ToAccount是否為空來顯示不同內(nèi)容：
1.ViewBag.ToAccount為空，則表明是頁面訪問。
2.ViewBag.ToAccount不為空，則為轉(zhuǎn)賬成功，需要顯示轉(zhuǎn)賬成功的提示信息。
來看下頁面運(yùn)行效果：
功能完成！看起來沒有任何問題，但是這里卻又一個(gè)CSRF漏洞，隱蔽而難于發(fā)現(xiàn)。
我是黑客，Show me the money
這里就有兩個(gè)角色，銀行的某個(gè)客戶A，黑客B。
黑客B發(fā)現(xiàn)了銀行的這個(gè)漏洞，就寫了兩個(gè)簡單的頁面，頁面一（click_me_please.html）：
<!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=utf-8" /> </head> <body> 哈哈，逗你玩的！ <iframe frameborder="0" style="display:none;" src="./click_me_please_iframe.html"></iframe> </body> </html>
第一個(gè)頁面僅包含了一個(gè)隱藏的iframe標(biāo)簽，指向第二個(gè)頁面（click_me_please_iframe.html）：
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
</head>
<body onload="document.getElementById('myform1').submit();">
<form method="POST" id="myform1"
action="http://localhost:55654/Home/TransferMoney">
<input type="hidden" name="ToAccount" value="999999999">
<input type="hidden" name="Money" value="3000">
</form>
</body>
</html>
第二個(gè)頁面放置了一個(gè)form標(biāo)簽，并在里面放置了黑客自己的銀行賬號(hào)和轉(zhuǎn)賬金額，在頁面打開時(shí)提交表單（body的onload屬性）。
現(xiàn)在黑客把這兩個(gè)頁面放到公網(wǎng)：
http://fineui.com/demo_mvc/csrf/click_me_please.html
然后批量向用戶發(fā)送帶有攻擊鏈接的郵件，而銀行的客戶A剛好登錄了銀行系統(tǒng)，并且手賤點(diǎn)擊了這個(gè)鏈接：
然后你將看到這個(gè)頁面：
你可能會(huì)在心里想，誰這么無聊，然后郁悶的關(guān)閉了這個(gè)頁面。之后客戶A會(huì)更加郁悶，因?yàn)楹诳虰的銀行賬號(hào)[999999999]已經(jīng)成功多了3000塊錢！
到底怎么轉(zhuǎn)賬的，不是有身份驗(yàn)證嗎
是的。轉(zhuǎn)賬的確是需要身份驗(yàn)證，現(xiàn)在的問題是你登錄了銀行系統(tǒng)，已經(jīng)完成了身份驗(yàn)證，并且在瀏覽器新的Tab中打開了黑客的鏈接，我們來看下到底發(fā)生了什么：
這里有三個(gè)HTTP請(qǐng)求，第一個(gè)就是[逗你玩]頁面，第二個(gè)是里面的IFrame頁面，第三個(gè)是IFrame加載完畢后發(fā)起的POST請(qǐng)求，也就是具體的轉(zhuǎn)賬頁面。因?yàn)镮Frame是隱藏的，所以用戶并不知道發(fā)生了什么。
我們來具體看下第三個(gè)請(qǐng)求：
明顯這次轉(zhuǎn)賬是成功的，并且Cookie中帶上了用戶身份驗(yàn)證信息，所有后臺(tái)根本不知道這次請(qǐng)求是來自黑客的頁面，轉(zhuǎn)賬成功的返回內(nèi)容：
如何阻止CSRF攻擊
從上面的實(shí)例我們可以看出，CSRF源于表單身份驗(yàn)證的實(shí)現(xiàn)機(jī)制。
由于HTTP本身是無狀態(tài)的，也就是說每一次請(qǐng)求對(duì)于Web服務(wù)器來說都是全新的，服務(wù)器不知道之前請(qǐng)求的任何狀態(tài)，而身份驗(yàn)證需要我們?cè)诘诙卧L問時(shí)知道是否登錄的狀態(tài)（不可能每次請(qǐng)求都驗(yàn)證賬號(hào)密碼），這本身就是一種矛盾！
解決這個(gè)矛盾的辦法就是Cookie，Cookie可以在瀏覽器中保存少量信息，所以Forms Authentication就用Cookie來保存加密過的身份信息。而Cookie中保存的全部值在每次HTTP請(qǐng)求中（不管是GET還是POST，也不管是靜態(tài)資源還是動(dòng)態(tài)資源）都會(huì)被發(fā)送到服務(wù)器，這也就給CSRF以可乘之機(jī)。
所以，CSRF的根源在于服務(wù)器可以從Cookie中獲知身份驗(yàn)證信息，而無法得知本次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)求的頁面地址。
一個(gè)正常的轉(zhuǎn)賬請(qǐng)求，我們可以看到Referer和瀏覽器地址欄是一致的：
我們?cè)賮砜聪聞偛诺暮诳晚撁妫?/p>
可以看到Referer的內(nèi)容和當(dāng)前發(fā)起請(qǐng)求的頁面地址一樣，注意對(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)求的頁面，而不一定就是瀏覽器地址欄顯示的網(wǎng)址。
基于這個(gè)原理，我們可以簡單的對(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í)訪問http://fineui.com/demo_mvc/csrf/click_me_please.html，惡意轉(zhuǎn)賬失?。?/span>
MVC默認(rèn)支持的CSRF驗(yàn)證
MVC默認(rèn)提供的CSRF驗(yàn)證方式更加徹底，它通過驗(yàn)證當(dāng)前請(qǐng)求是否真的來自用戶的操作。
在視圖頁面，表單內(nèi)部增加對(duì)Html.AntiForgeryToken函數(shù)的調(diào)用：
@if (ViewBag.ToAccount == null)
{
using (Html.BeginForm())
{
@Html.AntiForgeryToken()
<input type="text" name="ToAccount" />
<input type="text" name="Money" />
<input type="submit" value="轉(zhuǎn)賬" />
}
}
else
{
@:您已經(jīng)向賬號(hào) [@ViewBag.ToAccount] 轉(zhuǎn)入 [@ViewBag.Money] 元！
}
這會(huì)在表單標(biāo)簽里面和Cookie中分別生成一個(gè)名為__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è)隱藏字段的值，來看下錯(cuò)誤提示：
類似的道理，運(yùn)行黑客頁面http://fineui.com/demo_mvc/csrf/click_me_please.html，惡意轉(zhuǎn)賬失?。?/span>
此時(shí)，雖然Cookie中的__RequestVerificationToken提交到了后臺(tái)，但是黑客無法得知表單字段中的__RequestVerificationToken值，所以轉(zhuǎn)賬失敗。
以上這篇淺談ASP.NET MVC 防止跨站請(qǐng)求偽造(CSRF)攻擊的實(shí)現(xiàn)方法就是小編分享給大家的全部內(nèi)容了，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。
相關(guān)文章
asp.net 選擇excel類型文件，利用Dos命令成批復(fù)制文件
選擇excel類型文件，利用Dos命令成批復(fù)制文件2009-12-12
輕量級(jí)ORM框架Dapper應(yīng)用之實(shí)現(xiàn)In操作
這篇文章介紹了使用Dapper實(shí)現(xiàn)In操作的方法，文中通過示例代碼介紹的非常詳細(xì)。對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值，需要的朋友可以參考下2022-03-03
這篇文章主要介紹了.Net緩存之MemoryCahe的相關(guān)資料，幫助大家更好的理解和學(xué)習(xí)使用.net技術(shù)，感興趣的朋友可以了解下2021-05-05
在ASP.NET中實(shí)現(xiàn)彈出日歷的具體方法
這篇文章介紹了ASP.NET彈出日歷功能的實(shí)現(xiàn)方法，有需要的朋友可以參考一下2013-07-07
這篇文章主要介紹了ASP.NET新增時(shí)多字段取值解決方案，從解題思路出發(fā)分析原因，2015-09-09
.Net8.0 WebApi發(fā)布到IIS詳細(xì)步驟
本文主要介紹了.Net8.0 WebApi發(fā)布到IIS詳細(xì)步驟, 文中通過圖文介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2024-05-05
Silverlight中動(dòng)態(tài)獲取Web Service地址
開發(fā)過Silverlight應(yīng)用的朋友們相信都會(huì)遇到這樣一個(gè)問題2009-11-11
ASP.NET中的Dictionary想必使用.net的朋友并不陌生吧，下面以示例的方式為大家介紹下其基本用法，感興趣的朋友可以參考下2014-01-01
Web服務(wù)器的性能優(yōu)化有很多資料介紹了，多臺(tái)主機(jī)負(fù)載均衡，查詢結(jié)果的多級(jí)緩存，數(shù)據(jù)庫索引優(yōu)化等都是常見的優(yōu)化手段。2011-08-08
本篇文章給大家詳細(xì)講述了.NET單元測(cè)試的詳細(xì)方法和步驟，有需要的朋友參考學(xué)習(xí)下。2018-07-07