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

2、輸入通過System.Diagnostics.Process來實現調用外部程序XPATH注入/EmployeeUserName/text()=aaron and password/text()=password/EmployeeUserName/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

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

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

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

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

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

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

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

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

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

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

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

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