漏洞分類及判定方法

1、 漏洞分類及判定方法A1 注入原因：代碼中的邏輯裸依賴于外部的輸入。分支：SQL注入、OS命令注入、XPATH注入、LDAP注入、JSON注入、URL注入名稱現(xiàn)象解決方法SQL注入程序把用戶輸入的一段字符串直接用在了拼湊sql語句上，導(dǎo)致了用戶可以控制sql語句，比如加入delete的行為、繞過用戶密碼驗證等使用參數(shù)形式調(diào)用sql使用存儲過程（存儲過程中不要使用動態(tài)sql拼語句）使用Linq, EF等框架來寫（不要使用里面的直接拼sql語句的方式）OS命令注入因為是由程序拼湊命令行（包括參數(shù)）來實(shí)現(xiàn)調(diào)用外部程序的，因此用戶也能夠通過小計量來突破限制，實(shí)現(xiàn)調(diào)用其他外部程序業(yè)務(wù)邏輯層要驗證是否合法

2、輸入通過System.Diagnostics.Process來實(shí)現(xiàn)調(diào)用外部程序XPATH注入/EmployeeUserName/text()=aaron and password/text()=password/EmployeeUserName/text()=aaron or 1=1 or a =a and password/text()=password這個和典型的sql注入一樣，呵呵解決方法和sql類似，也是對查詢進(jìn)行參數(shù)化，如下：Declare variable $userName as xs: string external;Declare variable $password as

3、xs: string external;/ EmployeeUserName/text()=$userName and password/text()=$passwordLDAP注入LDAP查詢和sql查詢類似，也是可以通過拼字符串得來的，因此頁存在注入漏洞JSON注入user: usera, sex, boyuser: usera, sex, boy這樣會導(dǎo)致js報錯傳統(tǒng)webform下，使用JSON.NET來實(shí)現(xiàn)json數(shù)據(jù)的生成Mvc下，使用JSONResult來生成json數(shù)據(jù)URL注入如果還有個cookie，name為：p1, value: c則，最終獲取這個參數(shù)的value為：a,

4、b,c這個認(rèn)識的還不夠深入，而且和服務(wù)器端語言有關(guān)，只要會把幾個參數(shù)value合并起來，其他語言都只取到一個，但是取到的是第一個還是最后一個，就看語言了。這個和業(yè)務(wù)邏輯有很大的關(guān)系A(chǔ)2 失效的身份認(rèn)證和會話管理原因：Session相關(guān)的數(shù)據(jù)沒有被完整替換導(dǎo)致的安全問題解決關(guān)注點(diǎn)：Login通過后，立刻把當(dāng)前Session（包含Session, Cache, Cookie）失效掉，把需要保存進(jìn)Session的value重開一個Session保存進(jìn)；Logout功能中，除了把當(dāng)前Session失效掉外，還要把Session相關(guān)的Cache也remove掉登錄在login驗證事件中，一旦合法身份驗證

5、通過后，就要把Session.Abort()，來重新獲得新的Session（此時客戶端的session cookie value也會被reset成新的）注銷Session要Abort相關(guān)的緩存要clear額外的cookie也要被clearA3 跨站腳本（XSS）原因：和Injection類似，只不過xss的關(guān)注點(diǎn)落在了html, javascript注入上，由于內(nèi)容比較多，因此單獨(dú)拉出來，成為了XSS分支：反射式XSS、存儲式XSS、基于DOM的XSS解決關(guān)注點(diǎn)：html的輸入輸出編碼、javascript的編碼、url的編碼名稱現(xiàn)象解決方法反射式XSS由于服務(wù)器端直接調(diào)用了客戶端用戶輸入的數(shù)

6、據(jù)（沒有經(jīng)過無害化處理），導(dǎo)致了對廣大客戶端用戶的損害比如獲取客戶端用戶在某網(wǎng)站的所有cookie，這樣惡意用戶就能實(shí)現(xiàn)session劫持等更進(jìn)一步的攻擊對用戶輸入的數(shù)據(jù)要過濾特殊字符對輸出到客戶端的數(shù)據(jù)也要過濾特殊字符Html, js, url三大領(lǐng)域過濾方法不同，需要區(qū)別對待Server.HtmlEncode;Server.HtmlDecode;Server.UrlEncode;Server.UrlDecode;Server.UrlPathEncode;Js函數(shù)如下存儲式XSS存儲式XSS比反射式XSS更加深遠(yuǎn)，范圍更廣；因為這種未經(jīng)處理的代碼是保存到數(shù)據(jù)庫中的，因此時間、范圍都比較廣基于

7、DOM的XSSAJAX程序中，JS代碼沒有過濾/轉(zhuǎn)換用戶輸入的文本，導(dǎo)致了對DOM元素的結(jié)構(gòu)性影響，或者導(dǎo)致了行為性的影響Js中使用escape函數(shù)來過濾特殊字符，包括元素value、元素Attribute，都要encode起來escape,encodeURI,encodeURIComponent的使用參考goody9807的這篇文章：Anti-XSS腳本過濾庫，具體使用方法參考木子的這篇文章：Anti-XSS SRESRE: Security Runtime Engine的縮寫是一個更智能的過濾系統(tǒng)，具體使用參考Syed的這篇文章：ASP.NET MVC 4不會進(jìn)行轉(zhuǎn)換會進(jìn)行轉(zhuǎn)換AllowH

8、tmltag盡量不改動默認(rèn)的ValidateRequest屬性A4 不安全的直接對象引用原因：解決關(guān)注點(diǎn)：url參數(shù)的編碼和解碼工具類IndirectReference/根據(jù)數(shù)據(jù)庫中的entity id生成UI客戶端用于顯示的字符串id，這個字符串id類似于散列值，不容易猜測，但是能被還原String GenerateUIID(string/int/guid)/根據(jù)UI客戶端ID還原成原始的entity id,具體類型由T決定String FromUIID(string)Webform開發(fā)模式下Aspx頁面中a href=”product.aspx?productId=”產(chǎn)品APage_Loa

9、d中ductId= IndirectReference.FromUIID(Request.QueryString“productId”);MVC開發(fā)模式下為Entity增加IndirectReferenceID，然后ModelBinder就能自動綁定了A5 安全配置錯誤原則：最少使用模塊配置、最小權(quán)限配置；適用范圍：OS,IIS,數(shù)據(jù)庫解決關(guān)注點(diǎn)：Web.config中的Error節(jié)點(diǎn)配置，比如404、403錯誤的重定向和日志記錄、日志文件不能放在網(wǎng)站路徑下；web.config文件的加密（aspnet_regiis），具體命令如下：使用命令行，如(run as admin)：

10、 C:WindowsMicrosoft.NETFrameworkv4.0.30319aspnet_regiis -site VulnerableApp -app / -pe connectionStringsA6 敏感信息泄露原因：敏感信息需要加密保存(內(nèi)存、數(shù)據(jù)庫中、客戶端)+加密傳輸(HTTPS)+不緩存(這個只是盡量，具體看情況)解決關(guān)注點(diǎn)：登錄、付款這樣的頁面要用https保護(hù)傳輸加密方法密碼用單向加密，如MD5信用卡賬號等需要加密后再存儲到數(shù)據(jù)庫中（可逆的加密方式）傳輸層保護(hù)貌似就https了，其他的不怎么了解客戶端cookie的保護(hù)設(shè)置cookie的屬性HttpOnlySecure

11、數(shù)據(jù)庫的數(shù)據(jù)保護(hù)除了程序中進(jìn)行加密敏感數(shù)據(jù)外，數(shù)據(jù)庫級別也要使用數(shù)據(jù)庫加密A7 功能級訪問控制缺失原因：UI中顯示了當(dāng)前用戶不能進(jìn)行的操作，比如禁用了某個delete按鈕（能被修改成disable: 0即可使用）；權(quán)限驗證是否覆蓋到了某功能、UI；服務(wù)器端是否進(jìn)行了權(quán)限驗證（業(yè)務(wù)層級別）解決關(guān)注點(diǎn)：權(quán)限驗證Sample: 讀取文件時，比如下載時，如：download.aspx?file=a.txt，如果被修改成了download.aspx?file= 就麻煩了。對UI的處理導(dǎo)航欄中，如果沒有權(quán)限訪問的，就隱藏掉，不要弄disable之類的東西具體頁面中的按鈕也是這樣的處理方式，隱藏不要禁用（就

12、是用戶不能操作的，就不要讓用戶看到，省的麻煩）在最終頁面中要加入權(quán)限判斷代碼，這樣即便直接輸入了某特權(quán)url，由于還會在page中檢查權(quán)限，因此還是安全的對主要業(yè)務(wù)函數(shù)的處理1. 要有完善的安全系統(tǒng)2. 給主要業(yè)務(wù)函數(shù)貼上tagPrincipalPermission(SecurityAction.Demand, Role = Admin)public void RemoveUserFromRole(string userName, string role)Roles.RemoveUserFromRole(userName, role);A8 跨站請求偽造（CSRF）原因：利用合法用戶的身份，在

13、合法用戶的終端調(diào)用請求。這些請求可能是轉(zhuǎn)賬解決關(guān)注點(diǎn)：重要操作不要使用get方式，如：delete.aspx?id=1；要使用post方式；為每個能進(jìn)行post動作的form增加token，并且在服務(wù)器端檢查token是否合法，合法則進(jìn)行操作；Webform傳統(tǒng)開發(fā)模式給每個請求的頁面加入token的解決方法：使用Anti-CSRF組件可解決，使用方法見：自定義ViewState默認(rèn)的ViewState是沒有加密的，很容易被看到具體的value，如通過這個工具就能看到：ViewStateDecoder，url 可以通過給ViewState自定義來緩解那么一點(diǎn)點(diǎn)，但是沒辦法提升到像加入token

14、那樣的力度，代碼很簡單：this.ViewStateUserKey=Convert.ToString(Session“UserID”)如上代碼即可實(shí)現(xiàn)對ViewState的加密，會根據(jù)this.ViewStateUserKey的value對每個ViewState進(jìn)行Salt類似的加密MVC開發(fā)模式HttpPostValidateAntiForgeryTokenpublic ActionResult Login(Usr usr)return View();在aspx模版或者Razor 模版中的form中增加如下代碼：具體的方式參考這篇文章：A9 使用含有已知漏洞的組件原因：由于系統(tǒng)有意無意間使用了組件（自己的組件和第三方的組件，范圍太廣），導(dǎo)致了不可預(yù)料的問題解決關(guān)注點(diǎn)：對于自己的組件，要加強(qiáng)質(zhì)量，這個已經(jīng)和代碼沒有很多關(guān)系了，更多的是質(zhì)量管理、版本管理方面的了，略；對于第三方的組件，要選擇知名的提供商。A10 未驗證的重定向和轉(zhuǎn)發(fā)原因：當(dāng)系統(tǒng)接受重定向參數(shù)（login界面居多，如：解決關(guān)注點(diǎn)：對于returnUrl這種參數(shù)值進(jìn)行判斷，只要在白名單中的url才能redirect，盡量使用相對