OWASP(開放Web軟體安全項目- Open Web Application Security Project)是一個開放社羣、非營利性組織，目前全球有130個分會近萬名會員，其主要目標是研議協助解決Web軟體安全之標準、工具與技術文件，長期 致力於協助政府或企業瞭解並改善網頁應用程式與網頁服務的安全性。
下表左邊是2010年的排名，下表右邊是2013年的排名，可以看出改變的地方有：
- 2010年的Insecure Cryptographic Storage（不安全加密存儲）和Insufficient Transport Layer Protection（傳輸層保護不足），在2013年合併爲了一個：Sensitive Data Exposure（敏感數據暴露）
- 2010年的Failure to Restrict URL Access（不限制URL訪問），在2013年成爲了Missing Function Level Access Control（功能級別訪問控制缺失）
- 2010年中Security Misconfiguration（安全配置錯誤）的一部分，在2013年單獨拉出來，成爲了Using Known Vulnerable Components（使用已知易受攻擊組件）
|
OWASP Top 10 – 2010 (Previous) |
OWASP Top 10 – 2013 (New) |
|
A1 – Injection |
A1 – Injection |
|
A3 – Broken Authentication and Session Management |
A2 – Broken Authentication and Session Management |
|
A2 – Cross-Site Scripting (XSS) |
A3 – Cross-Site Scripting (XSS) |
|
A4 – Insecure Direct Object References |
A4 – Insecure Direct Object References |
|
A6 – Security Misconfiguration |
A5 – Security Misconfiguration |
|
A7 – Insecure Cryptographic Storage – Merged with A9 à |
A6 – Sensitive Data Exposure |
|
A8 – Failure to Restrict URL Access – Broadened into à |
A7 – Missing Function Level Access Control |
|
A5 – Cross-Site Request Forgery (CSRF) |
A8 – Cross-Site Request Forgery (CSRF) |
|
<buried in A6: Security Misconfiguration> |
A9 – Using Known Vulnerable Components |
|
A10 – Unvalidated Redirects and Forwards |
A10 – Unvalidated Redirects and Forwards |
|
A9 – Insufficient Transport Layer Protection |
Merged with 2010-A7 into new 2013-A6 |
A1 – Injection(注入)
原因：代碼中的邏輯裸依賴於外部的輸入。
分支：SQL注入、OS命令注入、XPATH注入、LDAP注入、JSON注入、URL注入
|
名稱 |
現象 |
解決方法 |
|
SQL注入 |
程序把用戶輸入的一段字符串直接用在了拼湊sql語句上，導致了用戶可以控制sql語句，比如加入delete的行爲、繞過用戶密碼驗證等 |
使用參數形式調用sql 使用存儲過程（存儲過程中不要使用動態sql拼語句） 使用Linq, EF等框架來寫（不要使用裏面的直接拼sql語句的方式） |
|
OS命令注入 |
因爲是由程序拼湊命令行（包括參數）來實現調用外部程序的，因此用戶也能夠通過小計量來突破限制，實現調用其他外部程序 |
業務邏輯層要驗證是否合法輸入 通過System.Diagnostics.Process來實現調用外部程序 |
|
XPATH注入 |
//Employee[UserName/text()=’aaron’ and password/text()=’password’] à //Employee[UserName/text()=’aaron’ or 1=1 or ‘a’ =’a’ and password/text()=’password’] 這個和典型的sql注入一樣，呵呵 |
解決方法和sql類似，也是對查詢進行參數化，如下： Declare variable $userName as xs: string external; Declare variable $password as xs: string external; // Employee[UserName/text()=$userName and password/text()=$password] |
|
LDAP注入 |
LDAP查詢和sql查詢類似，也是可以通過拼字符串得來的，因此頁存在注入漏洞 |
|
|
JSON注入 |
{‘user’: ‘usera’, ‘sex’, ‘boy’} à {‘user’: ‘usera’, ‘sex’, ‘bo’y’} 這樣會導致js報錯 |
傳統webform下，使用JSON.NET來實現json數據的生成 Mvc下，使用JSONResult來生成json數據 |
|
URL注入 |
http://www.a.com/a.aspx?p1=a&p1=b 如果還有個cookie，name爲：p1, value: c 則，最終asp.net獲取這個參數的value爲：a,b,c |
這個認識的還不夠深入，而且和服務器端語言有關，只要asp.net會把幾個參數value合併起來，其他語言都只取到一個，但是取到的是第一個還是最後一個，就看語言了。 這個和業務邏輯有很大的關係 |
A2 – Broken Authentication and Session Management （失效的身份認證和會話管理）
原因：Session相關的數據沒有被完整替換導致的安全問題
解決關注點：Login通過後，立刻把當前Session（包含Session, Cache, Cookie）失效掉，把需要保存進Session的value重開一個Session保存進；Logout功能中，除了把當前Session失效掉外，還要把Session相關的Cache也remove掉
|
登錄 |
在login驗證事件中，一旦合法身份驗證通過後，就要把Session.Abort()，來重新獲得新的Session（此時客戶端的session cookie value也會被reset成新的） |
|
|
註銷 |
Session要Abort 相關的緩存要clear 額外的cookie也要被clear |
|
A3 – Cross-Site Scripting (XSS) （跨站腳本）
原因：和Injection類似，只不過xss的關注點落在了html, javascript注入上，由於內容比較多，因此單獨拉出來，成爲了XSS
分支：反射式XSS、存儲式XSS、基於DOM的XSS
解決關注點：html的輸入輸出編碼、javascript的編碼、url的編碼
|
名稱 |
現象 |
解決方法 |
|
反射式XSS |
由於服務器端直接調用了客戶端用戶輸入的數據（沒有經過無害化處理），導致了對廣大客戶端用戶的損害 比如獲取客戶端用戶在某網站的所有cookie，這樣惡意用戶就能實現session劫持等更進一步的攻擊 |
對用戶輸入的數據要過濾特殊字符 對輸出到客戶端的數據也要過濾特殊字符 Html, js, url三大領域過濾方法不同，需要區別對待 Server.HtmlEncode; Server.HtmlDecode; Server.UrlEncode; Server.UrlDecode; Server.UrlPathEncode; Js函數如下 |
|
存儲式XSS |
存儲式XSS比反射式XSS更加深遠，範圍更廣；因爲這種未經處理的代碼是保存到數據庫中的，因此時間、範圍都比較廣 |
|
|
基於DOM的XSS |
AJAX程序中，JS代碼沒有過濾/轉換用戶輸入的文本，導致了對DOM元素的結構性影響，或者導致了行爲性的影響 |
Js中使用escape函數來過濾特殊字符，包括元素value、元素Attribute，都要encode起來 escape,encodeURI,encodeURIComponent的使用參考goody9807的這篇文章： http://www.cnblogs.com/goody9807/archive/2009/01/16/1376913.html |
|
Anti-XSS |
腳本過濾庫，具體使用方法參考木子的這篇文章： http://www.cnblogs.com/moozi/archive/2010/03/04/1677904.html |
|
|
Anti-XSS SRE |
SRE: Security Runtime Engine的縮寫 是一個更智能的過濾系統，具體使用參考Syed的這篇文章： http://blogs.msdn.com/b/syedab/archive/2009/07/08/preventing-cross-site-scripting-attacks-using-microsoft-anti-xss-security-runtime-engine.aspx |
|
|
ASP.NET MVC 4 |
<%=Html%>à不會進行轉換 <%: Html%>à會進行轉換 [AllowHtml]tag 儘量不改動默認的ValidateRequest屬性 |
|
A4 – Insecure Direct Object References （不安全的直接對象引用）
原因：http://www.a.com/userdetail.aspx?userId=1，容易認爲的進行猜測userId=2等等，如果沒有判斷權限，就容易出現信息泄露的問題；但是如果url是http://www.a.com/userdetail.aspx?userId=ABAWEFRA則很難進行猜測
解決關注點：url參數的編碼和解碼
|
工具類 |
IndirectReference //根據數據庫中的entity id生成UI客戶端用於顯示的字符串id，這個字符串id類似於散列值，不容易猜測，但是能被還原 String GenerateUIID(string/int/guid)
//根據UI客戶端ID還原成原始的entity id,具體類型由T決定 String FromUIID<T>(string) |
|
Webform開發模式下 |
Aspx頁面中 <a href=”product.aspx?productId=<%= IndirectReference.GenerateUIID(this.productID) %>”>產品A</a> Page_Load中 this.productId= IndirectReference.FromUIID<int>(Request.QueryString[“productId”]); |
|
MVC開發模式下 |
爲Entity增加IndirectReferenceID，然後ModelBinder就能自動綁定了 |
A5 – Security Misconfiguration （安全配置錯誤）
原則：最少使用模塊配置、最小權限配置；適用範圍：OS,IIS,數據庫
解決關注點：Web.config中的Error節點配置，比如404、403錯誤的重定向和日誌記錄、日誌文件不能放在網站路徑下；web.config文件的加密（aspnet_regiis），具體命令如下：使用命令行，如(run as admin)： C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis -site "VulnerableApp" -app "/" -pe "connectionStrings"
A6 – Sensitive Data Exposure （敏感數據暴露）
原因：敏感信息需要加密保存(內存、數據庫中、客戶端)+加密傳輸(HTTPS)+不緩存(這個只是儘量，具體看情況)
解決關注點：登錄、付款這樣的頁面要用https保護傳輸
|
加密方法 |
密碼用單向加密，如MD5 |
|
傳輸層保護 |
貌似就https了，其他的不怎麼了解 |
|
客戶端cookie的保護 |
設置cookie的屬性 HttpOnly Secure |
|
數據庫的數據保護 |
除了程序中進行加密敏感數據外，數據庫級別也要使用數據庫加密 |
A7 – Missing Function Level Access Control （功能級別訪問控制缺失）
原因：UI中顯示了當前用戶不能進行的操作，比如禁用了某個delete按鈕（能被修改成disable: 0即可使用）；權限驗證是否覆蓋到了某功能、UI；服務器端是否進行了權限驗證（業務層級別）
解決關注點：權限驗證
Sample: 讀取文件時，比如下載時，如：download.aspx?file=a.txt，如果被修改成了download.aspx?file=http://www.cnblogs.com/config.xml 就麻煩了。
|
對UI的處理 |
導航欄中，如果沒有權限訪問的，就隱藏掉，不要弄disable之類的東西 具體頁面中的按鈕也是這樣的處理方式，隱藏不要禁用（就是用戶不能操作的，就不要讓用戶看到，省的麻煩） 在最終頁面中要加入權限判斷代碼，這樣即便直接輸入了某特權url，由於還會在page中檢查權限，因此還是安全的 |
|
|
對主要業務函數的處理 |
|
A8 – Cross-Site Request Forgery (CSRF) （跨站請求僞造）
原因：利用合法用戶的身份，在合法用戶的終端調用請求。這些請求可能是轉賬…
解決關注點：重要操作不要使用get方式，如：delete.aspx?id=1；要使用post方式；爲每個能進行post動作的form增加token，並且在服務器端檢查token是否合法，合法則進行操作；
|
Webform傳統開發模式 |
給每個請求的頁面加入token的解決方法：使用Anti-CSRF組件可解決，使用方法見：http://anticsrf.codeplex.com
自定義ViewState 默認的ViewState是沒有加密的，很容易被看到具體的value，如通過這個工具就能看到：ViewStateDecoder，urlà http://download.csdn.net/detail/skt90u/3974340
可以通過給ViewState自定義來緩解那麼一點點，但是沒辦法提升到像加入token那樣的力度，代碼很簡單： this.ViewStateUserKey=Convert.ToString(Session[“UserID”]) 如上代碼即可實現對ViewState的加密，會根據this.ViewStateUserKey的value對每個ViewState進行Salt類似的加密 |
|
MVC開發模式 |
[HttpPost] [ValidateAntiForgeryToken] public ActionResult Login(Usr usr) { return View(); }
在aspx模版或者Razor 模版中的form中增加如下代碼： <%=Html.AntiForgeryToken() %>
具體的方式參考這篇文章：http://www.cnblogs.com/leleroyn/archive/2010/12/30/1921544.html |
A9 – Using Known Vulnerable Components （使用已知易受攻擊組件）
原因：由於系統有意無意間使用了組件（自己的組件和第三方的組件，範圍太廣…），導致了不可預料的問題
解決關注點：對於自己的組件，要加強質量，這個已經和代碼沒有很多關係了，更多的是質量管理、版本管理方面的了，略；對於第三方的組件，要選擇知名的提供商。
A10 – Unvalidated Redirects and Forwards（未驗證的重定向和轉發）
原因：當系統接受重定向參數（login界面居多，如：http://www.a.com/login.aspx?returnUrl=default.aspx），由於這個url會顯示在瀏覽器地址欄中，只要修改這個url爲http://www.a.com/login.aspx?returnUrl=http://wwv.a.com/login.aspx，用戶輸入密碼後被重定向到假冒站點的login界面（用戶以爲輸入的密碼錯誤了），用戶再次輸入密碼，此時密碼就被假冒站點保存起來了…
解決關注點：對於returnUrl這種參數值進行判斷，只要在白名單中的url才能redirect，儘量使用相對路徑來redirect
|
工具類 |
RedirectForwardDispatcher Void Config(List<string> whitelist) bool IsRedirectable(string newUrl) |
|
使用方法 |
String returnUrl=…; If(!RedirectForwardDispatcher.IsRedirectable(returnUrl)) { Throw exception(“Unvalidated Redirects and Forwards”); } |