面向Java EE 程序的SQLIA 漏洞分析和驗證方法

郭 帆，范威威

江西師范大學計算機信息工程學院，南昌 330022

雖然Web 應用提供了方便性、靈活性、可用性和互操作性，但是它們也容易受到各種各樣的安全威脅。在《OWASP Top 10-2017》發布的十大Web 應用安全風險[1]中，處于A1 級別的注入漏洞是其中最重要的一種，而SQL 注入攻擊（structured query language injection attack，SQLIA）漏洞最為常見并且使用范圍最廣。SQLIA 會讓攻擊者無限制地訪問底層數據庫，一旦攻擊成功，結果往往是災難性的。

污點分析（taint analysis）可以有效防御SQLIA，它是一種信息流分析技術，通過對敏感數據進行標記進而跟蹤標記數據在程序中的傳播過程和路徑，以找到系統中的安全漏洞[2]，主要分為靜態分析和動態分析。

靜態污點分析從源代碼中抽取語法、語義特征并記錄數據流向，判斷污染數據的產生、傳遞和使用[3]。Medeiros等[4]結合多種方法發現源代碼中的漏洞并使其具有較少誤報，首先使用污點分析發現候選漏洞，然后采用數據挖掘方法來預測假陽，誤報率較低。Maltitz 等[2]提出了一種基于靜態污點分析的形式化的隱私分析方法，用來簡化軟件體系結構的高級隱私屬性的設計和審核過程。Dahse 等[5]通過對數據庫、文件名和會話變量的字符串分析來得到二階數據庫訪問信息流，可以檢測二階SQLIA 和多階漏洞。Hauzar 等[6]提出了一個PHP（hypertext preprocessor）靜態分析框架，能夠自動解析動態語言通用的特性，能夠獨立地定義動態語言的值和堆分析，并能自動組合它們來查找實際存在的安全漏洞，假陽性率較低。Stiévenart 等[7]開發了一個高度模塊化的靜態分析框架SCALA-AM，該框架通過分離操作語義實現模塊化，能夠擴展支持多種語言且包含多種機器抽象，能夠按需實現不同的污染分析方案。王蕾等[8]創新地將數據流分析框架擴展成稀疏形式，利用稀疏優化方法對靜態污點分析中無關聯的污點傳播進行消除，以此達到時間和空間的開銷優化，但未實現別名間的強更新和保守子域的精確計算。馬金鑫等[9]提出并實現了一種基于執行蹤跡離線索引的污點分析方法，以字節為粒度，首次描述并解決了即時翻譯執行導致的污點丟失問題。Tripp 等[10]實現了一種精確且可擴展的新型靜態污點分析方法，將污點分析看作需求驅動問題，只需計算易受攻擊性信息流，而不是計算完整的數據流解決方案。對易受影響的信息流進行需求驅動的跟蹤和計算，以提升分析的精確度和效率，同時可以將分析擴展到大型代碼庫。

動態污點分析在程序執行時即時檢測數據是否來自外部的非可信輸入，通過實時監控程序的污點數據在系統程序中的傳播來檢測數據能否從污點源傳播到污點匯聚點。Amir-Mohammadian 等[11]為Java開發了一個動態完整性污染分析模型，該模型以一種in-depth 方法解決了不完善的消毒問題，結合預期措施和追溯措施，對消毒結果是前瞻性認可的且回顧性污染的情況進行完全消毒，很好地避免了假陽性的出現，但模型擴展性有待加強和開發。Cai 等[12]開發了一個二進制的動態污點分析工具SwordDTA，以期最大化地檢測軟件漏洞。該工具適用于硬件和軟件，通過漏洞建模和污點檢查來發現漏洞，對緩沖區溢出、整數溢出、被零除、UAF（use after free）等漏洞有很好的效果，但對其他類型的漏洞暫時無能為力，且路徑覆蓋率不高。Karim 等[13]為JavaScript提供了一個獨立于平臺的動態污染分析，將污點傳播過程編碼為抽象機器指令，執行這些指令就可得到關于應用的污染流報告，但是沒有對隱式流進行跟蹤，且污點傳播策略不夠靈活，不支持用戶自定義操作。

由于動態數據的不可判定性以及源代碼語義的描述能力有限，靜態分析結果的精確度有限。而動態分析只能觀測到程序的有限次執行，有效性依賴于測試集的完備性。研究人員進而提出了結合靜態分析與動態分析的混合分析方法，文獻[3]提出了一種編譯級的軟件脆弱性檢測和預防解決方案，首先使用靜態分析排除不可執行路徑，然后在問題點進行基于插樁的數據驗證。Balzarotti 等[14]基于靜態分析對應用程序沿著執行路徑修改輸入的行為進行建模，基于動態分析，重構應用程序用于修改輸入的代碼，然后執行代碼并使用大量惡意輸入值來識別消毒過程中可利用的缺陷，以此來分析消毒過程的正確性。

為了降低靜態污點分析假陽性率高的問題，提高靜態分析的精確度，本文提出了一種靜態分析與動態驗證相結合的污點分析方法。首先靜態提取所有的Source 和Sink 語句，并且對Source 集合進行預處理，剔除不是外部輸入的Source。然后，應用基于同方法、Request 請求、Session 會話和方法調用的匹配規則，結合靜態污點分析和活躍變量分析，剔除不可能存在污點傳播路徑的Source 和Sink 對。動態驗證首先對程序進行插樁，然后應用自動化測試工具自動生成測試路徑，在程序執行時結合動態污點傳播分析對Source 和Sink 之間的潛在污點傳播路徑進行驗證。如果漏洞真實存在，則對相應的污點傳播路徑進行消毒處理，檢測是否正確清除SQLIA 漏洞。

本文的貢獻包括以下兩點：

（1）提出一種高效的面向Java Web 程序的SQL注入漏洞靜態檢測方法，基于匹配規則裁剪無效Source和Sink 對，然后綜合污點分析和活躍變量分析裁剪不可能存在污點傳播漏洞的Source和Sink 對；

（2）實現了靜態檢測原型工具TASAT（taint analysis static analysis tool），并結合程序插樁和Selenium 自動測試工具對靜態檢測結果進行動態驗證，針對真實Web 程序的實驗結果驗證了方法的有效性。

1 分析方法

1.1 靜態分析

靜態分析階段的總體框架如圖1 所示。首先根據預定義策略提取所有可能的Source 和Sink 語句，然后對每條Source 語句進行分析，排除不是讀取外部輸入的Source，然后根據自定義匹配規則排除不可能發生SQLIA 的Source 和Sink 對，最后應用靜態污點分析并結合活躍變量分析對剩余的Source 和Sink對進行反向分析，進一步排除不存在污點傳播路徑的Source 和Sink 對。原型系統TASAT 實現了靜態分析階段的預處理Source、過濾無關Source 和Sink、活躍變量分析這三個方法組件。

Fig.1 Overall framework of static analysis圖1 靜態分析的總體框架

1.1.1 預處理Source集合

根據Source 方法讀取的參數是否對應實際的外部輸入，將Source 語句分為原生Source（參數對應外部輸入）和非原生Source（參數不對應外部輸入）。

原生Source 的判斷方法包括：基于Servlet 映射尋找來源action、基于action 確定來源Jsp 及對應表單、基于表單內容確定對應來源，如果來源為用戶外部輸入就可以判斷Source為原生Source。

把所有原生Source 放入原生Source 集合，對于非原生Source，通過匹配方法、匹配Request 和匹配Session 尋找對應的原生Source，然后建立與原生Source的映射關系并加入非原生Source集合。

預處理Source 方法能夠捕捉所有的原生Source以及和原生Source 形成映射關系的非原生Source，目前沒有處理來自其他源（如Cookie）的非原生Source。

圖2 的代碼片段示例1 展示了原生Source 的判斷過程，通過HandleLogin.java 的兩條Source 語句獲取Jsp 頁面傳遞的值，第1 句獲取參數“loginname”的對應值，同時賦值給loginname 變量，第2 句為獲取參數“password”的對應值，賦值給password 變量。

首先基于Servlet 尋找來源action，將Servlet Information 的Servletclass 字段和Source 所在Java 類進行匹配，得知HandleLogin 類與Servlet 類名“myservlet.control.HandleLogin”相匹配，推導出Web 程序通過名為“login”的action 跳轉到HandleLogin.java。

然后基于action 尋找來源Jsp，在Jsp_action 中匹配actions 字段包含“login”的記錄，得到相應jsp_class字段值為org.apache.jsp.login_jsp（即login.jsp 編譯后的class），推導出HandleLogin.java 中Source 的參數來自login.jsp。

最后搜索login_jsp 類的jspSevice 方法，尋找與login.jsp 中action 為“login”的表單內容對應的語句，發現名為“loginname”和“password”的input 語句并且相應value 值為隱含表示，說明找到Source 對應的原始外部輸入，因此判斷HandleLogin 類的兩條Source都是原生Source。

示例2 展示了一個非原生Source 找到對應原生Source 的過程。首先按照與示例1 相同的方式找到Source 方法的參數對應的輸入，位于lookShopCar.jsp中action 為“deletegood”的表單中，對應名為“delete”的input 語句，value 為“car.getNumber()”，表明Source為非原生Source。

Fig.2 Example of Source pre-process圖2 Source預處理示例

接著搜索方法內其他Source 語句，讀取Request對象屬性語句和讀取Session 對象屬性語句，尋找可能的原生Source。示例中Session_get 集合為預先遍歷程序得到的讀取Session 對象屬性的語句集合，其中lookShopCar.jsp 中的讀取Session 對象屬性“login”語句根據Session 對象屬性匹配關系，將變量login 與HandleLogin.java 中的login 對象相關聯，進一步在Handle-Login.java 中找到兩個Source，第4 和第5 行都是原生Source，因此建立input 語句與這兩個原生Source的映射關系。

1.1.2 過濾無關Source和Sink

如果直接簡單地對每對Source 和Sink 進行數據流分析，會浪費大量計算資源，因為許多Source 和Sink 之間不存在任何的可執行路徑。

根據Web 應用中Source 和Sink 所處位置和跨文件傳播的特點，本文提出了一種多重匹配的預處理方法，在進行復雜數據流分析之前首先排除不可能存在可執行路徑的Source 和Sink 對，從而減少了無謂的資源消耗。

多重匹配預處理方法包括：（1）相同方法匹配，判斷Source 和Sink 是否位于相同文件的相同方法；（2）相同的Request 信息匹配，判斷Source 和Sink 是否可以根據相同請求信息的Get 方法返回值和Set 方法參數匹配；（3）Session 信息匹配，判斷Source 和Sink 是否可以通過Session 對象的屬性匹配；（4）方法參數匹配，判斷Source 是否作為方法調用語句的參數傳遞給Sink 所在方法。目前，匹配方法可以支持Request 和Session 對象屬性的常量傳播。

另外，針對匹配成功的Source 和Sink 對，如果Source 不是原生Source，那么需要將該Source映射的原生Source與Sink 進行匹配。

Fig.3 Example of multiple matching圖3 多重匹配示例

圖3 的第1～2 行給出了相同方法匹配的例子，Source 方法getParameter 和Sink 方法executeQuery 都位于login.jsp 文件的_jsp-Service 方法中。第3～6 行給出相同Request 信息匹配的例子，Source（第3 行）在Search-Cosmetic.java 中，而Sink（第6 行）在Search-Cosmetic.jsp 中，根據req 對象的getRequest-Dispatcher 方法調用的參數信息，Source 可以與SearchCosmetic.jps文件中的Sink進行關聯匹配。第7～12 行給出Session 信息匹配的例子，Session信息匹配支持鍵值對中的常量傳播，將變量lg 替換為對應的常量字符串“login”，根據session 對象信息的“login”屬性，可以將HandleLogin.java 中的Source（第7 行）和GenerateOrder.java 中的Sink（第12 行）進行匹配。第13～15 行給出方法參數匹配的例子，Source 變量password 作為DaAccessMethods 類的getUserRole 方法調用的參數，而Sink 位于getUser-Role方法中，因此匹配。

1.1.3 污點傳播規則

污點傳播規則是后續活躍變量分析和動態驗證的基礎，在活躍變量分析中需要結合污點傳播規則生成活躍的污點變量。

給出形式化描述污點變量信息使用的符號，status表示變量的污點狀態取值集合，包括污染（tainted）和可信（trusted），locs 表示在語句中污點變量可能出現的位置集合：等式左值Lvalue、等式右值Rvalue、調用方法對象base 和方法參數arg_i，i 表示參數的下標順序。vars 表示程序中出現的變量及訪問路徑集合，如a、a.f、a[i]、class.f 等。taint_info 記錄各個位置上的變量是否被污染，taint_set 記錄每條語句的所有污點變量的位置集合。Г函數跟蹤記錄每個變量和當前語句不同位置的污點狀態，操作符∪計算兩個污點狀態值的并，兩個相同值的并值不變，而trusted∪tainted=tainted。

污點狀態信息使用的符號：

定義1Unit 使用了變量v，即use（Unit，v）成立當且僅當以下任意條件成立。

（1）Unit是AssignStmt且Rvalue不是InvokeExpr，v出現在Unit的Rvalue中。

（2）Unit 是AssignStmt 且Rvalue 是InvokeExpr：①Rvalue ∈InterfaceInvoke，v出現在Unit 的arg_i；②Rvalue ∈SpecialInvoke，v出現在Unit 的arg_i；③Rvalue ∈VirtualInvoke，v出現在Unit 中的base 或arg_i；④Rvalue ∈StaticInvoke，v出現在Unit的base或arg_i。

（3）Unit 是InvokeStmt，v出現在Unit 的base 或arg_i。

定義2Unit 定義了變量d，def（Unit，d）成立當且僅當以下任意條件成立。（1）Unit 是AssignStmt，d出現在Unit 的Lvalue；（2）Unit 是InvokeStmt，d沒出現在Unit中且d是base對象的某個屬性。

使用符號Use 存儲所有use（Unit，v）為真的變量v，表示Unit 使用的變量集合，符號Def 存儲def（Unit，d）為真的變量d，表示Unit 定義的變量集合。下面是一些在污傳播規則中使用的變量。

（1）system_method：系統類方法集合。

（2）custom_method：自定義方法集合。

（3）method：被調用方法。

（4）taint_custom(method)：處理自定義方法的方法內污點傳播，如果method 有返回值，那么返回該值的污點狀態。

（5）xX：對象的屬性。

（6）SetXX：屬性xX 的Set方法集合。

（7）GetXX：屬性xX 的Get方法集合。

污點傳播規則分為單文件傳播和跨文件傳播。單文件傳播包括兩類指令：

（1）賦值語句

污點信息由Rvalue 傳播到Lvalue，即Г（Lvalue）=Г（Rvalue），Lvalue 和Rvalue 都包括多種類型，具體如下。

①a=C，Lvalue 是變量a，Rvalue 是常量C。常量賦值可以消除左值的污點狀態，將污點變量驗證為可信變量，對應式（1）。

②a=b，Rvalue 為變量b；a=bbinopc，Rvalue為二元表達式；a=unopb，Rvalue 為一元表達式；a=b.f，Rvalue 為對象實例的成員變量；a=class.f，Rvalue 為全局靜態變量；a.f=b，Lvalue 為對象實例的成員變量；class.f=b，Lvalue 為全局靜態變量。在上述任意情形，Rvalue的污點狀態為所有當前Unit使用變量的污點狀態值的并值，對應式（2）。

③a=b[i]，Rvalue 為數組元素且索引為變量；a=b[constant]，Rvalue 為數組元素且索引為常量。當右值為數組元素時，污點傳播采用保守策略，Rvalue的污點狀態值為所有在程序中出現的數組元素的污點狀態值的并值，對應式（3）。

④b[i]=a，Lvalue 為數組元素且索引為變量；b[constant]=a，Lvalue 為數組元素且索引為常量。當Lvalue為數組元素時，只需要把Rvalue的污點狀態值賦予Lvalue 即可，不需要修改其他數組元素。如果該元素是tainted，那么所有數組元素的并值一定也是tainted，如果該元素被驗證為trusted，那么不影響其他元素的污點狀態，從而保證污點傳播的可靠性，對應式（4）。

⑤a=invoke_expr b.f（arg_1，arg_2...），將方法調用語句分為三類，一是對象屬性的Get方法即GetXX，二是庫方法system_method，三是自定義方法custom_method。GetXX 方法沒有參數，直接返回屬性b.xX的值，因此Lvalue 的污點狀態等于b.xX 的污點狀態值。如果system_method 的實例對象b 或任意參數的污點狀態為tainted，Lvalue 的污點狀態保守地設置為tainted。對于自定義方法，根據方法內污點傳播taint_custom 計算返回值的污點狀態，對應式（5）～式（7）。

⑥a=new_expr（arg_1，arg_2...），Rvalue 為創建對象表達式，如果表達式中的任意參數的污點狀態為tainted，那么Lvalue 為tainted，否則為trusted，對應式（8）。

（2）方法調用語句

形如invoke b.f（arg_1，arg_2...），分為三類，一是對象屬性的Set 方法即SetXX，二是庫方法system_method，三是自定義方法custom_method。對于Set方法，修改對象b 的屬性b.xX 為相應參數的污點狀態。對于沒有返回值的system_method，沒有給出任何定義，忽略了庫方法可能改變全局變量的污點狀態，可能改變對象b 和參數對象的屬性的污點狀態，忽略了對象b 可能受到參數的污點傳播而改變污點狀態。對于custom_method，根據方法內污點傳播taint_custom 改變其他變量的污點狀態，對應式（9）。

對于傳播方法taint_custom，靜態分析和動態分析有所不同。靜態分析采用標準的方法內數據流分析，根據賦值語句和方法調用語句定義的相應傳播規則在控制流圖中傳播污點信息，遇見分支語句時進行變量的污點狀態并值計算，如果存在環（即循環），則迭代分析至污點狀態集合為最小不動點。動態分析伴隨著指令的順序執行，根據每條指令的污點傳播規則動態修改相應變量的污點狀態即可。

跨文件污點傳播發生在待分析語句是Request和Session 對象的屬性讀寫語句時，如getParameter 和setAttribute 等，根據屬性的鍵值對信息傳播污點。在單個文件污點傳播過程結束后，根據跨文件傳播規則獲取目標文件的污點信息集合，然后對目標文件開啟新一輪污點傳播分析?？缥募埸c傳播在目標文件中僅保留和傳播被讀寫的屬性所對應的污點狀態值，并以此作為單文件傳播的初始taintset，開始目標文件的污點傳播分析。

1.1.4 活躍變量分析

如果在每條從Source 到Sink 的執行路徑上都存在一個程序點位置，在該位置上所有的活躍變量都是可信變量，或者在Source 點的活躍變量集合不包含Source 方法返回值變量，那么每條路徑都不可能有污點信息傳播到Sink，即Source 與Sink 之間不可能存在真實污點傳播路徑。

活躍變量分析與預定義污點傳播規則相結合，僅記錄可能是污點的活躍變量，即在標準活躍變量分析基礎上，按照1.1.3 小節定義的污點傳播語義，計算每條指令的活躍污點變量。如果污點變量通過方法調用參數傳遞，根據預定義的實參和形參的映射關系計算新的活躍變量；如果通過Request方法傳遞，根據Request 對象的鍵值對計算新的活躍變量；如果通過Session 對象的屬性傳遞，根據Session 對象的屬性和活躍變量的匹配關系計算新的活躍變量。

圖4 給出了兩個代碼片段示例，說明活躍變量分析過程。在第5 行的Sink 語句位置，方法參數query是活躍污點變量，在第4 行活躍污點變量是query 和name，進而得知在第3 行只有name 是活躍污點變量，然后可以計算出在第2 行，s 是活躍污點變量，最后s是Source 方法的返回值，說明示例1 存在潛在的污點傳播路徑。

Fig.4 Example of live variable analysis圖4 活躍變量分析示例

示例2 給出了3 種不存在污點傳播執行路徑的Source 和Sink 對，示例污點傳播過程中的污點驗證、Session 屬性匹配和Request屬性匹配。在第9 行Sink語句，方法參數s 是活躍污點變量，在第8 行，根據屬性方法getLoginname 的污點傳播語義，活躍污點變量變為lg.loginname，在第7 行，sanitize 方法對login對象進行了消毒處理后賦予lg 變量，此時不存在任何活躍污點變量，活躍變量分析中止，表明第1行Source 和第9 行的Sink 之間不可能存在污點傳播路徑。

在第14 行Sink 語句，query 是活躍污點變量，在第13 和第12 行，活躍污點變量分別是{query，name}和name。在第11 行，方法調用login.getLoginname 獲取login 對象的loginname 屬性，因此活躍污點變量是login.loginname，而不是login 對象。在第10 行，根據Session 對象屬性名“login”匹配，污點變量追溯至文件1 中的login 對象的屬性login.loginname（第4 行）。在第4 行，活躍污點變量還是login.loginname，第2 行設置login 對象的“password”屬性為password 變量，活躍污點變量依然是login.loginname，與第1 行的Source 返回值變量password 無關，表明password 在Source 位置不活躍，即第1 行的Source 無法將污點變量傳播到第14 行的Sink。

在第17 行的Sink 語句，login.password 為活躍污點變量，在第16 行對login 對象執行污點驗證，此時活躍污點變量為空集，活躍變量分析中止，login 對象在第15 行根據Request 屬性“login”匹配文件1 的login 對象（第5 行），表明第1 行的Source 與第17 行的Sink 不存在污點傳播路徑。

靜態分析主要完成原生Source 的正確判斷和轉換處理，發現存在潛在SQL 注入漏洞的Source 和Sink 對，通過自定義的污點傳播語義規則并使用活躍變量分析方法對它們進行反向數據流分析，排除不可能存在SQ 注入漏洞的Source 和Sink 對。預處理過程有效地過濾無關Source 和Sink 對，極大減少了待分析的Source 和Sink 對數量，進而提高了分析的性能。通過自定義一套完整的指令級污點傳播語義規則，并結合經典活躍變量分析方法，進一步排除不可能存在SQLIA 漏洞的Source 和Sink 對，提高了分析的精確度。

1.2 動態驗證方法

1.2.1 流程概述

動態驗證基于污點傳播規則對Jimple 中間代碼進行插樁，執行插樁后程序獲得污點傳播的指令序列Trace，基于Trace 驗證靜態分析結果的Source 和Sink 之間是否存在真實污點傳播路徑。驗證過程如圖5 所示，首先將Java 和Jsp 文件編譯為class，然后應用Soot 框架反編譯為Jimple 中間代碼，并基于污點傳播規則對相應語句進行插樁，插樁代碼用于動態跟蹤污點變量的傳播，接著將插樁后的Jimple 代碼重新編譯為class，最后打包為jar 文件并進行網站部署。應用自動化測試工具對網站進行測試，根據插樁代碼動態跟蹤的污點傳播信息打印相應的代碼片斷Trace，然后將每條Trace 與靜態分析結果的Source和Sink 進行匹配，判斷是否存在真實污點傳播路徑。如果存在，嘗試在源代碼中增加驗證方法，并重新執行靜態分析，檢測漏洞是否已經被安全消除。

1.2.2 插樁處理

動態插樁定義一個輔助類用于實現污點傳播，其中設置不同的靜態方法用于實現不同語句的污點傳播語義。靜態遍歷程序的每條語句，根據污點傳播規則判斷其是否需要插樁，是則根據其類型進行相應插樁，即插入一條調用輔助類的相應方法的語句并傳入相應參數。不用插樁的語句類型包括definitionstmt、ifstmt、return 和goto 等。

插樁根據不同類型的語句（Unit）調用不同類型的輔助方法，傳入不同的方法參數，同時不影響原來代碼的業務邏輯，對AssignStmt 和InvokeStm 類型語句的插樁方式如表1所示。對于AssignStmt類型分為Source、Sink、右值為InvokeExpr 和other 等情形進行處理，對于InvokeStmt 類型分為request_set、session_set、invokeexpr 等情形進行處理。傳入參數Unit 指語句自身，left 指語句左值，base 指方法調用對象，arg 表示方法參數，itsClass 表示語句所屬類，key 指request參數或session 屬性名，value 表示key 對應的值，method 表示被調用方法。

Fig.5 Flowchart of dynamic verification圖5 動態驗證流程

Table 1 Statement instrumentation parameter example表1 語句插樁參數示例

對于AssignStmt 中的Source、Sink 和other 情形，left和arg參數用于跟蹤污點變量傳播，Unit和itsClass參數用于記錄產生污點傳播的語句。對于InvokeExpr、base 和method 參數，用于處理方法調用的污點傳播。對于InvokeStmt 中的request_set 和session_set，key 和value 參數用于處理匹配Request 和Session 對象的鍵值對進行污點傳播。

圖6 展示了一段Java 代碼轉換為對應的Jimple代碼以及根據Jimple 代碼的特性進行插樁操作后的效果展示圖?？偣灿? 段代碼片段：第1 段為Java 代碼。第2 段為Java 代碼對應的Jimple 代碼，在該段Jimple 代碼中，第1 句為接口調用方法，調用Http-ServletRequest 接口對象的getParameter 方法來獲得對應參數的值，第2 句為普通調用方法，調用String 對象的trim 方法來去除String 對象的字符串的頭尾空白符，第3、4 句與第1、2 句類似。第3 段為插樁后得到的Jimple 代碼，第2 和第4 句為插樁代碼，在第2 段代碼的每條語句后面插入一條調用DynamicUtil輔助類的靜態方法的語句。第1 句是AssignStmt 類型的Source語句，插入靜態findAndjudgeSource方法，傳入unit、left、arg 和itsClass 參數進行污點傳播。第3 句為AssignStmt 類型的InvokeExpr 語句，插入taintanalysis_assignstmt_invokeexpr 方法，并傳入unit、left、base、method、arg 和itsClass等參數進行污點傳播。

1.2.3 驗證

Fig.6 Example of instrumentation result圖6 插樁效果展示圖

驗證過程首先對原始Web 程序進行人工測試，盡量覆蓋程序中所有可能執行數據庫操作的路徑，同時應用Selenium 工具錄制瀏覽器與Web 程序的交互過程，錄制的全部路徑作為自動化測試模塊對插樁后的Web 程序進行自動測試。

圖7 給出了一條測試路徑示例，從用戶登錄開始，包括瀏覽化妝品、加入購物車、查看購物車和用戶退出。主要記錄交互過程，即定位到特定元素并執行對應操作，如點擊元素click 和元素賦值sendKeys等。

Fig.7 Example of test path圖7 測試路徑示例

驗證過程通過重放執行錄制的測試路徑實現，在程序執行的同時，插入的代碼執行動態污點分析并打印與污點傳播相關的指令序列即Trace。然后，驗證過程搜索每條Trace 的Source 和Sink 集合，判定是否與靜態分析結果的Source 和Sink 對匹配，是則表明找到了對應Source 和Sink 的一條真實污點傳播路徑，同時驗證了靜態分析結果的正確性。

圖8 是一條Trace 示例。第1 行是Source 語句，獲取login.jsp 中“password”對應的外部輸入并賦值給password 變量，password 變量成為污點變量。第2行，password 作為查詢語句的一部分，在查詢操作完成后將污點信息傳播給ResultSet類型的變量rs，污點信息在第3 行從rs 傳播至userid 變量。第4 行是session 對象的寫屬性語句，將污點變量userid 以鍵值對<“userid”，userid>的形式保存在session 對象中。在第5 行，通過session 對象的讀屬性語句將loing_jsp文件中的污點變量userid 傳播給basket_jsp 文件中的字符串變量userid。第6 行是Sink 語句，污點變量userid 作為查詢語句的一部分，可能造成相關數據表的數據泄漏。

Fig.8 Trace example圖8 Trace示例

動態驗證使用程序插樁技術，基于自定義的污點傳播規則對Jimple 中間代碼進行插樁，使用自動測試工具動態遍歷執行插樁后程序的不同路徑，針對程序運行后產生的Trace 進行跟蹤驗證，檢查Source是否能夠成功傳播到相應Sink，進而判斷漏洞是否真實存在。

靜態分析結果的誤報率較高，人工驗證的效率很低，本文將靜態分析與動態驗證相結合，實現了靜態分析的自動化和動態驗證過程的半自動化，實驗結果表明本文方法在大幅提高分析效率的同時保持了很好的準確率。

2 實驗結果及分析

實驗環境為Windows 7 64 位操作系統，CPU 為Intel?CoreTMi5-4200M，8 GB 物理內存，瀏覽器為加載SeleniumIDE 3.15.1 插件的Firefox。開發環境基于JDK 7、Soot-2.5.0 以及Kepler 和Mars 等Eclipse 工具，代碼量為7 600 行，其中原生Source 判斷及轉換模塊1 100行，多重匹配模塊600行，污點規則定義及活躍變量分析模塊代碼量為2 300行，動態插樁模塊1 600行。

實驗整體框架如圖9 所示，靜態分析檢測潛在SQL 注入漏洞，作為動態驗證過程的數據集。動態驗證通過驗證數據集定位真實漏洞，排除誤報，并對漏洞進行消毒處理。

Fig.9 Experimental overall framework圖9 實驗整體框架

實驗數據集包括6 個網站，其中3 個漏洞測試網站為bodgeit、security-shepherd 和webgoat，3 個開源網站為contineo、cosmetic_shop 和puzzlemall。靜態分析階段的實驗結果如表2 所示，經過多重匹配（P_decrement rate）后，需要驗證的Source 和Sink 對的數量極大減少，最少減少88.6%，最多減少99.4%，平均減少98.7%。將活躍變量分析與污點傳播相結合進一步消除不可能存在污點傳播路徑的Source 和Sink，最少減少6.2%，最多減少84.4%，平均減少69.6%，表明靜態分析階段能夠有效排除無關Source和Sink 對，避免無謂的計算資源浪費。

動態驗證的結果如表3 所示，Finds 表示成功驗證的Source和Sink 對數量。bodgeit項目的15 個潛在漏洞中有9 個是Source 和Sink 位于相同方法，其余6個是經過Session 對象跨文件傳遞，動態驗證確認了其中的12 個漏洞。contineo 項目的100 個潛在漏洞有89 個被成功地驗證，都是通過方法調用進行跨文件污點傳播。cosmetic_shop、security_shephred 和puzzlemall 等項目的潛在漏洞全部被成功地驗證。webgoat 項目潛在的30 個漏洞有25 個被成功驗證。所有數據集中無法驗證的漏洞都是因為Selenium 沒有生成相應執行路徑導致，這是由于動態測試無法做到100%覆蓋測試路徑。

Table 2 Static analysis results表2 靜態分析實驗結果

Table 3 Results of dynamic verification表3 動態驗證結果

Table 4 Comparison of time performance表4 時間性能比較

將分析結果與經典Java EE 程序分析工具ANDROMEDA[10]進行對比，結果如表3 所示。在ANDROMEDA 的數據集中，因為只成功運行了contineo 和webgoat 兩個項目，所以表3 和表4 只針對這兩個項目比較準確率和時間性能。表4 以靜態分析得到的Source 和Sink 對作為潛在漏洞總數，以動態驗證確認的Source 和Sink 對作為Findings，得出TP和FP，準確率P=TP/(TP+FP)，表示動態驗證通過的漏洞數量與潛在漏洞數量的比值，虛警率FPR=FP/(FP+TP)，表示動態驗證未通過的漏洞數量與潛在漏洞數量的比值，T/F=Time/Findings，表示找到一個Finding 的平均時間。ANDROMEDA 的有關數據來自文獻[10]。

對于contineo，本文方法和ANDROMEDA 的TP和FP接近，對于webgoat，本文方法的TP和FP都要好于ANDROMEDA，上述結果表明本文方法的準確率優于ANDROMEDA，因為本文方法專注分析SQL 注入漏洞，并且將靜態分析與動態驗證相結合以排除虛警，而ANDROMEDA 是單純的靜態分析工具，用于分析多種Web 程序漏洞，在保證可靠性的同時虛警率會上升。

FN 表示靜態分析沒有發現的漏洞數量，在本文中表示沒有和原生Source 形成映射關系的非原生Source 數量。召回率R=TP/(TP+FN)，表示驗證通過的漏洞數量與所有實際漏洞數量的比值。綜合評價指標F=2PR/(P+R)，表示準確率和召回率的加權調和平均，綜合了準確率和召回率的結果，有利于對檢測結果綜合性能的評價[15]。

ANDROMEDA 和本文方法的綜合情況對比如表5 所示，由于ANDROMEDA 論文中沒有對應的召回率數據，因此將其保守地設置為1。對于contineo項目，ANDROMEDA 和本文方法的誤報率和綜合評價相差無幾，對于webgoat 項目，本文方法的誤報率顯著低于ANDROMEDA，準確率和綜合評價指標更好?？傮w來看，本文方法的誤報率明顯低于ANDROMEDA，具有更好的準確率，同時召回率也維持在一個較高水平，綜合評價指標也略優于ANDROMEDA，說明本文方法具有更好的檢測效果。

時間性能以平均Time/Finding 進行比較，即找到一個漏洞所用的平均時間，如圖10 所示。ANDROMEDA 在兩個項目中總計找到297 個漏洞，花費848 s，平均為2.85 s，本文方法在6 個項目中共找到220 個漏洞，花費598 s，平均為2.71 s，兩者的時間性能相差無幾。

Table 5 Comparison of comprehensive performance表5 綜合性能比較

Fig.10 Average time for a finding圖10 Finding 平均時間

3 結束語

本文提出了一種面向SQLIA 漏洞的靜態檢測和動態驗證方案。靜態分析階段首先搜索程序中所有的Source 和Sink，然后對Source 集合進行預處理，區分原生Source 和非原生Source，同時定位和映射非原生Source 對應的原生Source。接著根據Request 和Session 對象屬性，采用多重匹配方法，尋找存在潛在污點傳播路徑的Source和Sink，然后應用活躍變量分析結合污點傳播，排除不可能存在污點傳播路徑的Source 和Sink，極大減少了待分析的潛在漏洞數量。動態驗證首先對程序插樁，插入污點傳播跟蹤代碼，然后應用seleniumIDE 插件對原始Web 項目產生自動化測試路徑，接著對插樁后的Web 項目重放這些測試路徑并根據生成的Trace 驗證潛在漏洞是否真實。最后嘗試對傳播的污點變量進行可信驗證，阻斷污點傳播路徑從而修復漏洞。針對真實項目的實驗結果表明了方法的有效性，同時，本文方法與經典工具ANDROMEDA 對比，在時間性能和準確度上均有一定提高。

方法不足之處主要有：（1）在Source 預處理和多重匹配時，目前只能處理action 和屬性名為常量字符串的情況，無法處理對于運行時確定的action 和屬性名，解決該問題需要引入字符串分析技術。（2）庫方法的建模采用保守方式，可能影響污點傳播的精確度，擬應用污點摘要定義庫方法的污點傳播語義。（3）動態驗證采用人工測試并自動重放執行路徑，存在路徑覆蓋率低的問題，未來擬引入模糊測試和動態符號執行技術改善路徑覆蓋。