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 – 不安全的加密資料儲存--與A9合併
Insecure Cryptographic Storage – Merged with A9

A6 – 敏感資訊洩漏

(Sensitive Data Exposure)

A8 -限制網址存取失效--擴大為2013-A7
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))

<隱藏於A6: 不當安全組態設定>
<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)

與2010-A7合併至2013-A6 

Merged with 2010-A7 into new 2013-A6

A1 注入攻擊

(Injection)

• 注入攻擊漏洞，例如SQL，OS以及 LDAP注入。這些攻擊發生在當不可信的資料作為命令或者查詢語句的一部分，被發送給解譯器的時候。攻擊者發送的惡意資料可以欺騙解譯器，以執行計畫外的命令或者在未被恰當授權時訪問資料。

A2 失效的身份認證和會話管理

(Broken Authentication and Session Management)

• 身份認證和會話(session )管理相關的應用程式功能得不到正確的執行，導致攻擊者破壞密碼、密鑰、會話權杖(session tokens)或攻擊其他的漏洞去冒充其他用戶的身份。

A3 跨站腳本攻擊

（Cross-Site Scripting ,XSS） 

• 當應用程式收到含有不可信的資料，在沒有進行適當的驗證和轉碼(escaping ，未將特殊字元編碼)的情況下，就將它發送給一個網頁瀏覽器，這就會產生跨站腳本攻擊（簡稱XSS）。XSS允許攻擊者在受害者的瀏覽器上執行腳本，從而劫持用戶端的Session、危害網站或者將用戶轉向至惡意網站。

A4 不安全的直接對物件參考

(Insecure Direct Object References)

• 當開發人員暴露一個對內部實現物件的引用時，例如，一個檔案(File)、目錄(Directory)或者資料庫密鑰( Database key)，就會產生一個不安全的直接物件引用(References)。在沒有檢查存取控制或其他保護時，攻擊者會利用這個引用去取得未授權資料。

A5 安全配置錯誤

(Security Misconfiguration)

• 好的安全需要對應用程式、框架、應用程式伺服器、web伺服器、資料庫伺服器和平臺定義和執行安全配置。由於許多設置的預設值並不是安全的，因此，必須定義、實施和維護這些設置。

這包含了對所有的軟體保持及時地更新，包括所有應用程式的庫檔。

A6 敏感資訊洩漏

(Sensitive Data Exposure)

• 許多Web應用程式沒有正確保護敏感性資料，如信用卡，稅務ID和身份驗證憑證。攻擊者可能會竊取或篡改這些弱保護的資料以進行信用卡詐騙、身份竊取，或其他犯罪。

敏感性資料需額外的保護，比如在存放或在傳輸過程中的加密，以及在與瀏覽器交換時進行特殊的預防措施。

A7 缺少功能級別的存取控制

(Missing Function Level Access Control)

• 大多數Web應用程式在功能在UI中可見以前，驗證功能級別的存取權限。但是，應用程式需要在每個功能被訪問時在伺服器端執行相同的存取控制檢查。

如果請求沒有被驗證，攻擊者能夠偽造請求以在未經適當授權時訪問功能。

A8 跨站請求偽造

（Cross-Site Request Forgery ,CSRF）

• 一個跨站請求偽造攻擊迫使登錄用戶的瀏覽器將偽造的HTTP請求，包括該用戶的session cookie和其他認證資訊，發送到一個存在漏洞的web應用程式。這就允許了攻擊者迫使用戶流覽器向存在漏洞的應用程式發送請求，而這些請求會被應用程式認為是使用者的合法請求。

A9 使用含有已知漏洞的組件

(Using Known Vulnerable Components) 

• 組件，比如：函式庫(libraries)、框架(framework)和其它軟體模組(software modules)，幾乎總是以全部的許可權運行。如果一個帶有漏洞的元件被利用，這種攻擊可以造成更為嚴重的資料丟失或伺服器接管。應用程式使用帶有已知漏洞的元件會破壞應用程式防禦系統，並使一系列可能的攻擊和影響成為可能。

A10 未驗證的重新導向和轉發

(Unvalidated Redirects and Forwards)

名稱

現象

解決方法

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合併起來，其他語言都只取到一個，但是取到的是第一個還是最後一個，就看語言了。

這個和業務邏輯有很大的關係

登錄

在login驗證事件中，一旦合法身份驗證通過後，就要把Session.Abort()，來重新獲得新的Session（此時客戶端的session cookie value也會被reset成新的）

註銷

Session要Abort

相關的緩存要clear

額外的cookie也要被clear

名稱

現象

解決方法

反射式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屬性

工具類

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就能自動綁定了

加密方法

密碼用單向加密，如MD5
信用卡賬號等需要加密後再存儲到數據庫中（可逆的加密方式）

傳輸層保護

貌似就https了，其他的不怎麼瞭解

客戶端cookie的保護

設置cookie的屬性

HttpOnly

Secure

數據庫的數據保護

除了程序中進行加密敏感數據外，數據庫級別也要使用數據庫加密

對UI的處理

導航欄中，如果沒有權限訪問的，就隱藏掉，不要弄disable之類的東西

具體頁面中的按鈕也是這樣的處理方式，隱藏不要禁用（就是用戶不能操作的，就不要讓用戶看到，省的麻煩）

在最終頁面中要加入權限判斷代碼，這樣即便直接輸入了某特權url，由於還會在page中檢查權限，因此還是安全的

對主要業務函數的處理

1. 要有完善的安全系統
2. 給主要業務函數貼上tag

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

工具類

RedirectForwardDispatcher

Void Config(List<string> whitelist)

bool IsRedirectable(string newUrl)

使用方法

String returnUrl=…;

If(!RedirectForwardDispatcher.IsRedirectable(returnUrl))

{

Throw exception(「Unvalidated Redirects and Forwards」);

}