概述
安全在web領域是一個永遠都不會過時的話題，今天我們就來看一看一些在開發ASP.NET MVC應用程序時一些值得我們注意的安全問題。本篇主要包括以下幾個內容 ：
認證
所謂認證，簡單的來說就是驗證一個用戶的身份。這取決於我們開發的站點的類型，是否允許匿名訪問，是否是屬於管理員或者其它角色的用戶等等。也就是說我們的整個程序或者某些功能是針對某些特定的用戶開發的，那么我們可能就要進行認證來確定用戶的身份。需要注意的是，認證與授權是是完全不一樣的概念，我們要區別對待。打個比方，在ASP.NET MVC里面允許某一類用戶訪問某個Action就是授權。
ASP.NET MVC中主要有兩種認證機制
- Forms 認證
- Windows 認證
Forms 認證
從字面上我們就可以得到一些信息，基於表單的認證提供給用戶一個表單可以輸入用戶名和密碼，然后我們可以在我們的程序中寫自己的邏輯去驗證這些信息。ASP.NET MVC為Forms認證提供了很多支持，並且有很強自定義性。從通過表單登錄到用戶信息存儲在什么地方，到怎么樣去驗證這些用戶信息。Forms認證默認是依靠cookie技術實現的，一旦某個用戶登錄站點，那么用戶所使用的這個瀏覽器就會得到一個cookie並且在后面所有與這個站點的其它請求中都會將這個cookie包含在http的頭中。ASP.NET能夠檢測到這個cookie，這個cookie中包含了用戶的認證信息，那么后面就不需要再重復的認證用戶了。
Windows認證
Windows 認證也就是大家熟悉的集成身份認證，因為它使用了集成在Windows操作系統中的用戶組件來認證用戶。一旦某個用戶登錄到域中，Windows能夠在應用程序中自動認證他們。Windows認證一般在企業局域網內比較常用，一般企業局域網中所有的用戶都需要用域身份來登錄，這個有點像單點登錄的體驗，一旦進入域中就可以就可以很方便的同時登錄域內的其它應用程序。
配置Forms認證
首先我們需要更改web.config中的authentication結點。
這個配置信息很簡單，首先我們要使用的authentication類型是Forms認證。通過loginUrl指定我們認證用戶的頁面。這個Account Controller和 Login View還有一些允許用戶注冊的View都被ASP.NET MVC的internet模板默認實現了。我們可以輕而易舉在在ASP.NET MVC中實現Forms認證。
打開Visual Studio 2010 > New Project > Select ASP.NET MVC 4 Web Application 點擊確認。
然后選擇Internet Application點擊確認，Forms認證所需要的Controller 和View等等都會默認包含在我們的項目里面了。
Authorize 屬性
Authorize不關注我們如何認證用戶，我們既可以用Forms認證也可以用Windows認證。Authorize會去檢測當前用戶是否有身份信息。如果我們在Index上加上Authorize屬性那么匿名用戶就不能訪問我們的Index Action了。他們會被跳轉到Account/Login，也就是我們上面在web.config中配置的loginUrl。
如何配置Windows認證
和Forms認證一樣，首先我們需要更改一下web.config中的authentication結點。
然后同樣地，應用Authorize屬性到我們的Index Action上。
我們可以將Authorize應用到一個單獨的Action上，也可以應用到一個Controller上。當我們在某一個Controller上應用Authorize屬性時，也就意味着這個Controller下所有的Action都必須是經過認證的用戶才允許訪問 。
如果使用IIS Express的話，我們需要更改配置信息來啟用Windows認證。否則我們就會得到以下錯誤頁面。
我們可以到IIS Express的配置中去啟用Windows認證，打開Windows Explorer進入我的文檔> IIS Express > config > applicationhost.config。然后將windowsAuthentication enabled設置為true。
然后我們就可以拿到一些用戶的信息。
授權
授權允許我們傳遞一些參數去設置規則，我們可以告訴Authroize屬性只有某些具體用戶才可以訪問某個Action。
同時 ，我們還可以為Authorize屬性指定 Roles。這些Roles默認匹配到我們web服務器的Windows Group或者是域管理器里面的用戶組。
在Forms認證中, ASP.NET為我們提供了一個角色管理器（role provider）我們可以通過它來方便和將我們的角色信息存儲到SQL中，並且進行管理。我們只需要點擊一個按鈕即可：
點擊上面這個按鈕之后，它會幫我們運行ASP.NET configuration tool。這個站點只能在本地運行，我們可以在這個站點管理我們的角色，這個站點默認使用的數據連接就是我們配置在web.config中的連接字符串。
XSS跨站腳本攻擊
在web領域，有幾個比較常見的安全隱患，其中一個比較流行的就是跨站腳本攻擊。一些惡意的用戶通過一些手段讓我們的站點加載一些惡意的腳本，那么如果其它用戶訪問到這些腳本就有可能成為受害者。除了腳本，包括active-x控件，甚至一些惡意的Html都可以成為XSS的武器。XSS可以做到哪里事情 ？
- 竊取cookie
- 更改用戶設置
- 下載惡意軟件
- 更改內容
- 賬戶劫持
簡單的說，我們可以通過XSS訪問用戶的個人信息以及身份信息。
XSS示例
這是一個簡單的錄入員工信息的頁面，我們輸入一些html代碼然后保存頁面。ASP.NET默認會去檢測我們的request，發現類似html代碼會直接拒絕我們的請求。
當然，有些時候我們需要允許用戶輸入html，那么只要在我們的Action上打上ValidateInput(false)即可。
這樣我們就可以成功的提交 我們的請求了。
如上圖所示，這樣我們又遇到了另外一個問題。在ASP.NET MVC中razor默認會對所有輸出進行html編碼。這是ASP.NET MVC針對XSS攻擊的另一道防火牆。通過為屬性打上AllowHtml屬性，我們可以允許某一個屬性包含html的值，這樣我們就可以移除Action上的ValidateInput屬性。通過Html.Raw 我們可以將html輸出到客戶端。
Anti XSS library
如果我們允許用戶輸入html的話，有些人可能會嘗試輸入一些腳本 (不要說你沒有想過在博客園輸入一些腳本來玩玩？)
幸運的是，Microsoft為我們提供了一個組件，我們可以通過nugget或者Library Package Manager Console( Visual Studio > Tools > Library Package Manager > Package Manager Console 輸入 Install-Package AntiXss回車 )
只需要簡單的一句話，就可以移除所有的有害代碼，是不是感覺又被Microsoft搞蠢了？
CSRF跨站請求偽造
跨站請求偽造也是一種危險的主流攻擊。試想一下，某個用戶登錄到網站想修改一些個人信息，如果服務器端使用了Forms認證，那么在這個用戶登錄之后就會得到一個包含身份信息的cookie並且在后面所有這個站點下的請求中傳遞。當然這個並沒有錯，畢竟如果每次都去驗證用戶名和密碼是一次不小的開銷，驗證一次之后將登錄信息保存到cookie中，至少在用戶不關閉瀏覽器之前，我們不用再重新去驗證用戶。
安全隱患在哪里？
如果瀏覽器端依然保留着我的身份信息，那在我訪問其他惡意的站點的時候。這些惡意的站點就可以自己封裝一個表單並提交到我們的服務器，雖然這個請求時惡意站點偽造的，但是因為它帶有用戶的身份，所以服務器是會正常處理的。小到更改用戶資料，大到轉走用戶的賬戶余額都成為可能。
所以我們在處理請求的時候，不僅僅需要驗證用戶身份信息，還需要確保發送數據的表單是由我們服務器產生的。這樣就可以避免其他惡意用戶偽造表單發送數據。
CSRF示例
這里有一段很常見的代碼，通過Edit Action來編輯用戶信息。我們已經為Edit 打上了Authorize屬性，也就是說用戶是需要登錄才能訪問這個Action的。從普通開發的角度來看，這個程序是不會有什么問題的，我們首先通過正常渠道添加了一個用戶。
接下來，很雷很雷的事情發生了。你收到一封郵件說你中獎了，給了你一個鏈接，或者在某個網站上本身就嵌入了一些惡意代碼，而你不幸手一抖，就點了。接下來結果有可能是這樣滴。
你的數據很輕松就被篡改了。如果賬號是有余額的，你就哭吧。來看看這個頁面 是如何實現的。
非常的簡單，我們只需要將form的action指向實際的action就可以了。這個頁面一旦被加載，這個表單就會自動提交，那我們的數據就被黑了，一切都是那么的簡單。
如何避免？
ASP.NET MVC 為我們提供了Html.AntiForgeryToken() 方法，我們只需要在form中添加這句話。MVC 會為我們生成一個唯一標識放在form中的一個隱藏域中，該標識還會被存放到cookie中在客戶端和服務器的請求中傳輸。另外我們要做的就是為我們的Action打上ValidateAntiForgeryToken的屬性。
如果請求不包含這個cookie，那服務器就會拒絕這個請求，從而避免CSRF的攻擊。
原文：http://www.codeproject.com/Articles/654846/Security-In-ASP-NET-MVC
本篇是根據上面的文章按照我的理解翻譯的。
今天的故事就講到這里，謝謝大家的收看！