我要學ASP.NET MVC 3.0（十三）： MVC 3.0 防止跨站點請求僞造 (CSRF) 攻擊我要學ASP.NET MVC 3.0（十三）： MVC 3.0 防止跨站點請求僞造 (CSRF) 攻擊

概述

衆所周知，ASP.Net MVC程式在浏覽器運作時産生了标準的Html标簽，包括浏覽器要發送的關鍵資料等内容都在Html内容裡面，聽起來不錯，但是假如我們仿造類似的Html内容，更改裡面關鍵資料，在浏覽器運作起來會怎麼樣呢？好下面我們就做這樣一個例子。

CSRF攻擊例子

首先我們拿以前做好的person/edit作為例子

先看控制器代碼

　　

然後我們來看看視圖代碼

運作起來看看

點選儲存後

可以看到，上面例子中的代碼都是正确的，運作都是正常的，下面我們來實作CSRF攻擊。

實作CSRF攻擊

打開記事本，寫入下面代碼

另存為Html檔案。

輕按兩下檔案運作。。。

允許阻止的内容之後：

啊？？？~~~不會吧，此時你可能已經傻了吧。。。這個就叫CSRF攻擊。

什麼是CSRF攻擊

CSRF（Cross-site request forgery），中文名稱：跨站請求僞造，也被稱為：one click attack/session riding，縮寫為：CSRF/XSRF。

因為在ASP.NET程式中，我們的使用者資訊都是存在與cookies裡面的，此時在使用者自己來說，程式已經可以算是裸奔了。正因為如此，Web程式接受的正常用戶端請求一般來自使用者的點選連結和表單送出等行為。可是惡意攻擊者卻可以依靠腳本和浏覽器的安全缺陷來劫持用戶端會話、僞造用戶端請求。攻擊者盜用了你的身份，以你的名義發送惡意請求，以你名義發送郵件，發消息，盜取你的賬号，甚至于購買商品，虛拟貨币轉賬......造成的問題包括：個人隐私洩露以及财産安全。這就是CSRF攻擊。

CSRF漏洞的攻擊一般分為站内和站外兩種類型：

CSRF站内類型的漏洞在一定程度上是由于程式員濫用$_REQUEST類變量造成的，一些敏感的操作本來是要求使用者從表單送出發起POST請求傳參給程式，但是由于使用了$_REQUEST等變量，程式也接收GET請求傳參，這樣就給攻擊者使用CSRF攻擊創造了條件，一般攻擊者隻要把預測好的請求參數放在站内一個貼子或者留言的圖檔連結裡，受害者浏覽了這樣的頁面就會被強迫發起請求。

CSRF站外類型的漏洞其實就是傳統意義上的外部送出資料問題，一般程式員會考慮給一些留言評論等的表單加上水印以防止SPAM問題，但是為了使用者的體驗性，一些操作可能沒有做任何限制，是以攻擊者可以先預測好請求的參數，在站外的Web頁面裡編寫javascript腳本僞造檔案請求或和自動送出的表單來實作GET、POST請求，使用者在會話狀态下點選連結通路站外的Web頁面，用戶端就被強迫發起請求。

浏覽器的安全缺陷

現在的Web應用程式幾乎都是使用Cookie來識别使用者身份以及儲存會話狀态，但是所有的浏覽器在最初加入Cookie功能時并沒有考慮安全因素，從WEB頁面産生的檔案請求都會帶上COOKIE

MVC中防止CSRF攻擊

使用AntiForgeryToken令牌，在ASP.NET的核心中為我們提供了一個用來檢測群組織CSRF攻擊的令牌。

隻要在Html表單裡面使用了@Html.AntiForgeryToken()就可以阻止CSRF攻擊。

相應的我們要在Controller中也要加入[ValidateAntiForgeryToken]過濾特性。

該特性表示檢測伺服器請求是否被篡改。

注意：該特性隻能用于post請求，get請求無效。

 運作效果和上面的一樣

然後我們在運作剛才儲存的Html檔案看看

 哈哈報錯了。。那就證明我們現在的阻止CSRF攻擊是有效的。

使用Salt值加強保護

為了保證我們的AntiForgeryToken阻止在程式中唯一，更好的加密AntiForgeryToken，我們可以為AntiForgeryToken設定Salt值。

這樣，即使攻擊者設法得到了令牌，但是如果Salt值不比對也不能進行post操作。

我們暫時不修改View代碼

運作看看

可以看到加入Salt值後即使是MVC程式本身的頁面都無法請求，更别說攻擊者了，除非他能猜到我們的Salt值。

我們修改view代碼

繼續運作項目

可以看到在view中加入Salt值後，阻止就變的有目的性了。

總結

浏覽器的會話安全特性 ：

我們參照Set-Cookie的标準格式

Set-Cookie: <name>=<value>[; <name>=<value>] [; expires=<date>][; domain=<domain_name>] [; path=<some_path>][; secure][; HttpOnly]

浏覽器支援的cookie實際上分為兩種形式：

一種是記憶體COOKIE，在沒有設定COOKIE值的expires參數，也就是沒有設定COOKIE的失效時間情況下，這個COOKIE在關閉浏覽器後将失效，并且不會儲存在本地。另外一種是本地儲存COOKIE，也就是設定了expires參數，COOKIE的值指定了失效時間，那麼這個COOKIE會儲存在本地，關閉浏覽器後再通路網站，在COOKIE有效時間内所有的請求都會帶上這個本地儲存COOKIE。

Internet Explorer有一個隐私報告功能，其實這是一個安全功能，它會阻擋所有的第三方COOKIE，比如A域Web頁面嵌入了B域的檔案，用戶端浏覽器通路了A域的Web頁面後對B域所發起的檔案請求所帶上的COOKIE會被IE攔截。除開檔案請求情況，A域的Web頁面如果使用IFRAME幀包含B域的Web頁面，通路A域的Web頁面後，B域的Web頁面裡的所有請求包括檔案請求帶上的COOKIE同樣會被IE攔截。不過Internet Explorer的這個安全功能有兩個特性，一是不會攔截記憶體COOKIE，二是在網站設定了P3P頭的情況下，會允許跨域通路COOKIE，隐私報告功能就不會起作用了。

是以在Internet Explorer的這個安全特性的前提下，攻擊者要進行站外的CSRF攻擊使用檔案請求來僞造GET請求的話，受害者必須在使用記憶體COOKIE也就是沒有儲存登陸的會話狀态下才可能成功。而Firefox浏覽器并沒有考慮使用這樣的功能，站外的CSRF攻擊完全沒有限制。

關于Javascript劫持技術 ：

近年來的web程式頻繁使用Ajax技術，JSON也開始取代XML做為AJAX的資料傳輸格式，JSON實際上就是一段javascript，大部分都是定義的數組格式。fortify公司的三位安全人員在2007年提出了Javascript劫持技術，這是一種針對JSON動态資料的攻擊方式，實際上這也是一種變相的CSRF攻擊。攻擊者從站外調用一個script标簽包含站内的一個JSON動态資料接口，因為<script src=”>這種腳本标簽的檔案請求會帶上COOKIE，使用者通路後相當于被迫從站外發起了一個帶有身份認證COOKIE的GET請求，web程式馬上傳回了使用者相關的JSON資料，攻擊者就可以取得這些關鍵的JSON資料加以利用，整個過程相當于一個站外類型的CSRF攻擊。

WEB應用中的JSON資料大部分使用在個人資料、好友清單等隐私功能裡，這類資料一般是web蠕蟲最重要的傳播功能所需要的資料，而CSRF攻擊結合Javascript劫持技術完全可以分析這類資料制作自動傳播的web蠕蟲，在一定情況下這種web蠕蟲比網站出現跨站腳本漏洞制作的web蠕蟲更具威脅性，幾乎不受網站架構的限制，因為攻擊者利用的不是傳統的Web漏洞而是網站自身正常的功能，如果出現這類CSRF蠕蟲，對網站的打擊将是災難性的。

安全提醒 ：

各個大型社群類網站必須警惕CSRF攻擊和相關web蠕蟲的爆發,并且針對這類web攻擊制定有效的應急措施。同建議程式員不要濫用$_REQUEST類變量，在必要的情況下給某些敏感的操作加上水印，考慮使用類似DISCUZ論壇的formhash技術提高黑客預測請求參數的難度，注意JSON資料接口的安全問題等。最後希望大家全面的考慮用戶端和服務端整體的安全，注意Internet Explorer等用戶端浏覽器一些安全缺陷和安全特性，防止用戶端程式的安全問題影響整個Web應用程式。

本文轉自程式猿部落格51CTO部落格，原文連結http://blog.51cto.com/haihuiwei/1966358如需轉載請自行聯系原作者

365850153