今天，我還是分析一款強大的代碼安全審計工具到底應該什麼樣？還是以OWASP Benchmark的Java案例作為例子進行分析。Benchmark中2740個包含真假漏洞的案例中，分為10類，例如SQL注入、指令行注入、弱密碼、弱哈希等等。下面我以其中三個類别的真假漏洞作為例子，進行分析。
先看SQL注入，我從其中選擇了一個具有代表性的案例，BenchmarkTest00105.java，是一個假漏洞。
使用代碼安全審計工具進行檢測，不會報出sql注入漏洞。為什麼呢？下面分析過程。
在第70行，int[] counts = statement.executeBatch(); 執行批量查詢是SQL注入的污點語句，從該語句向上面檢視，找到執行的sql語句，在69行，把sql語句添加到批量進行中。參數sql來自于65行，String sql = "SELECT * from USERS where USERNAME='foo' and PASSWORD='"+ bar +"'"; 這一行相加了使用者輸入的密碼，bar字元串，bar字元串又來自于第61行，60行。
在條件表達式中 bar = (7*18) + num > 200 ? "This_should_always_happen" : param;
（7*18）+num其值大于200，為真，是以bar= "This_should_always_happen"；為固定字元串，是以不會出現sql注入風險漏洞。
下面是把影響bar取值條件語句修改一下，把num由100修改為10，此時bar = （7*18）+ num > 200 ? "This_should_always_happen" : param;的條件表達式值為假，bar取param的值，而param是未經處理，是以存在着SQL注入風險漏洞。檢測工具應該能夠報出這個漏洞。
強大的代碼安全審計工具之是以能夠報出這個安全漏洞，主要是因為采用常量替換技術。在條件表達式，把num的值帶入到表達式中進行計算，再進行符号執行，是以雖然代碼安全審計工具采用靜态分析技術，但是也會在記憶體中進行動态的計算和執行，是以能夠發現運作時缺陷和安全漏洞。
下面我們再分析一個XSS跨站攻擊案例。BenchmarkTest02233.java是一個假漏洞。
使用代碼安全審計工具并不會報出XSS安全漏洞，工具中報出的另外的漏洞。因為valuesList.get(1)取值時，從list中取出的值是”moresafe”，固定字元串，是以不存在安全漏洞。
下面我修改第68行，bar取值不再取valuesList的第1個元素，而是取第0個元素，也就是Param，該值是POST未經處理的傳回值。第54行列印輸出時仍然是param值，未處理的post參數值，存在xss的風險。是以代碼安全審查工具應該報出這個潛在漏洞。你看，該工具報出了XSS安全漏洞。
下面再看一個CMDI指令行注入案例。BenchmarkTest00051.java 是一個假漏洞。下面檢視一下添加到執行指令的參數args，param來自于調用String param = scr.getTheValue("vector");的傳回值。
看另一個檔案SeparateClassREquest.java，調用getTheValue傳回的是一個固定值bar，是以不會産生指令行注入安全漏洞。
下面我把46行調用getTheValue修改為調用String param = scr.getTheParameter("vector"); getTheParameter函數傳回的參數傳入的vector參數的值，該值來自于post請求，未經處理，應該存在SQL注入的風險。
修改後，覆寫原來的檔案，執行代碼安全審計工具，重新叫麼，可以看到工具檢測出潛在的指令行注入漏洞。
各位，通過上面代碼安全審計工具先分别對三個假漏洞進行檢測，能夠分析出不存在安全漏洞。但是代碼進行調整，當輸出字元串中有從POST請求中取值，又未經處理時，則存在着安全漏洞，能夠檢測出來。一款強大的代碼安全審計工具應該能夠區分真假漏洞，在對實際項目進行檢測時，才能保證準确度，做到靜态分析類工具能夠達到的最小誤報率和最小漏報率。
（完）
-------------------------------------------------------------------------------------
關注安全 關注作者