搜尋此網誌

2014/10/8

[資安]OWASP Top 10 Application Security Risks – 2013

OWASP Top 10 Application  Security Risks – 2013
OWASP(開放Web軟體安全項目- Open Web Application Security Project)是一個開放社群、非營利性組織，目前全球有130個分會近萬名會員，其主要目標是研議協助解決Web軟體安全之標準、工具與技術文件，長期 致力於協助政府或企業瞭解並改善網頁應用程式與網頁服務的安全性。


下表左邊是2010年的排名，下表右邊是2013年的排名，可以看出改變的地方有：
  1. 2010年的Insecure Cryptographic Storage（不安全加密存儲）和Insufficient Transport Layer Protection（傳輸層保護不足），在2013年合併為了一個：Sensitive Data Exposure（敏感數據暴露）
  1. 2010年的Failure to Restrict URL Access（不限制URL訪問），在2013年成為了Missing Function Level Access Control（功能級別訪問控制缺失）
  1. 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 – 不安全的加密資料儲存--與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)
• Web應用程式經常將使用者重新導向和轉發到其他網頁和網站，並且利用不可信的資料去判定目的頁面。如果沒有得到適當驗證，攻擊者可以重新導向受害使用者到釣魚軟體或惡意網站，或者使用轉發去訪問未授權的頁面。
這邊引用這個blog
A1 – Injection(注入)
名稱
現象
解決方法
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 （失效的身份認證和會話管理）
登錄
在login驗證事件中，一旦合法身份驗證通過後，就要把Session.Abort()，來重新獲得新的Session（此時客戶端的session cookie value也會被reset成新的）

註銷
Session要Abort
相關的緩存要clear
額外的cookie也要被clear

A3 – Cross-Site Scripting (XSS) （跨站腳本攻擊）
名稱
現象
解決方法
反射式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 （不安全的直接對物件參考）
工具類
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 （安全配置錯誤）
A6 – Sensitive Data Exposure （敏感資訊洩漏）
加密方法
密碼用單向加密，如MD5
信用卡賬號等需要加密後再存儲到數據庫中（可逆的加密方式）
傳輸層保護
貌似就https了，其他的不怎麼瞭解
客戶端cookie的保護
設置cookie的屬性
HttpOnly
Secure
數據庫的數據保護
除了程序中進行加密敏感數據外，數據庫級別也要使用數據庫加密
A7 – Missing Function Level Access Control （缺少功能級別的存取控制）
對UI的處理
導航欄中，如果沒有權限訪問的，就隱藏掉，不要弄disable之類的東西
具體頁面中的按鈕也是這樣的處理方式，隱藏不要禁用（就是用戶不能操作的，就不要讓用戶看到，省的麻煩）
在最終頁面中要加入權限判斷代碼，這樣即便直接輸入了某特權url，由於還會在page中檢查權限，因此還是安全的
對主要業務函數的處理
  1. 要有完善的安全系統
  2. 給主要業務函數貼上tag
[PrincipalPermission(SecurityAction.Demand, Role = "Admin")]
public void RemoveUserFromRole(string userName, string role)
{
Roles.RemoveUserFromRole(userName, role);
}

A8 – Cross-Site Request Forgery (CSRF) （跨站請求偽造）
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（未驗證的重新導向和轉發）
工具類
RedirectForwardDispatcher
Void Config(List<string> whitelist)
bool IsRedirectable(string newUrl)
使用方法
String returnUrl=…;
If(!RedirectForwardDispatcher.IsRedirectable(returnUrl))
{
Throw exception(「Unvalidated Redirects and Forwards」);
}






A1  
原因：代碼中的邏輯裸依賴於外部的輸入。
分支：SQL注入、OS命令注入、XPATH注入、LDAP注入、JSON注入、URL注入
A2  
原因：Session相關的數據沒有被完整替換導致的安全問題
解決關注點：Login通過後，立刻把當前Session（包含Session, Cache, Cookie）失效掉，把需要保存進Session的value重開一個Session保存進；Logout功能中，除了把當前Session失效掉外，還要把Session相關的Cache也remove掉


A3  
原因：和Injection類似，只不過xss的關注點落在了html, javascript注入上，由於內容比較多，因此單獨拉出來，成為了XSS
分支：反射式XSS、存儲式XSS、基於DOM的XSS
解決關注點：html的輸入輸出編碼、javascript的編碼、url的編碼


A4  
原因：http://www.a.com/userdetail.aspx?userId=1，容易認為的進行猜測userId=2等等，如果沒有判斷權限，就容易出現信息洩露的問題；但是如果url是http://www.a.com/userdetail.aspx?userId=ABAWEFRA則很難進行猜測
解決關注點：url參數的編碼和解碼


A5  
原則：最少使用模塊配置、最小權限配置；適用範圍：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  
原因：敏感信息需要加密保存(內存、數據庫中、客戶端)+加密傳輸(HTTPS)+不緩存(這個只是儘量，具體看情況)
解決關注點：登錄、付款這樣的頁面要用https保護傳輸


A7  
原因：UI中顯示了當前用戶不能進行的操作，比如禁用了某個delete按鈕（能被修改成disable: 0即可使用）；權限驗證是否覆蓋到了某功能、UI；服務器端是否進行了權限驗證（業務層級別）
解決關注點：權限驗證
Sample: 讀取文件時，比如下載時，如：download.aspx?file=a.txt，如果被修改成了download.aspx?file=http://www.cnblogs.com/config.xml 就麻煩了。


A8  
原因：利用合法用戶的身份，在合法用戶的終端調用請求。這些請求可能是轉賬…
解決關注點：重要操作不要使用get方式，如：delete.aspx?id=1；要使用post方式；為每個能進行post動作的form增加token，並且在服務器端檢查token是否合法，合法則進行操作；


A9  
原因：由於系統有意無意間使用了組件（自己的組件和第三方的組件，範圍太廣…），導致了不可預料的問題
解決關注點：對於自己的組件，要加強質量，這個已經和代碼沒有很多關係了，更多的是質量管理、版本管理方面的了，略；對於第三方的組件，要選擇知名的提供商。

A10  
原因：當系統接受重定向參數（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
張貼者： 於
標籤： ,

沒有留言:

張貼留言

訂閱： 張貼留言 (Atom)