潘秋紅，崔展齊，王林章,2,3+

1.南京大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)系，南京 210023

2.南京大學(xué) 計(jì)算機(jī)軟件新技術(shù)國家重點(diǎn)實(shí)驗(yàn)室，南京 210023

3.江蘇省軟件新技術(shù)與產(chǎn)業(yè)化協(xié)同創(chuàng)新中心，南京 210023

4.北京信息科技大學(xué) 計(jì)算機(jī)學(xué)院，北京 100101

1 引言

SQL（structured query language）注入是攻擊者由外部輸入向程序中原有的數(shù)據(jù)庫執(zhí)行語句中插入惡意SQL語句片段，篡改SQL執(zhí)行命令來操作數(shù)據(jù)庫的安全漏洞。無論是對(duì)于Web應(yīng)用還是移動(dòng)應(yīng)用，SQL注入都是一個(gè)嚴(yán)重的安全問題。攻擊者可以利用SQL注入漏洞竊取用戶敏感信息，惡意篡改數(shù)據(jù)庫中的內(nèi)容，提升權(quán)限等，引發(fā)嚴(yán)重后果。根據(jù)OWASP（Open Web Application Security Project）發(fā)布的Web應(yīng)用十大安全威脅中，從2010年至2017年4月，注入類漏洞都高居榜首[1]。

SQL注入漏洞對(duì)軟件安全產(chǎn)生了巨大威脅，對(duì)SQL注入的檢測(cè)和防范是開發(fā)者在開發(fā)軟件時(shí)必須考慮的一個(gè)重要因素。已經(jīng)提出了很多方法用于檢測(cè)Web應(yīng)用中的SQL注入漏洞，主要可分為靜態(tài)分析[2]、動(dòng)態(tài)測(cè)試[3]兩類。靜態(tài)分析方法如符號(hào)執(zhí)行技術(shù)，其將符號(hào)作為值賦給變量，對(duì)程序的路徑進(jìn)行模擬執(zhí)行，精確分析程序的代碼屬性[2]。動(dòng)態(tài)測(cè)試則要通過運(yùn)行軟件來得到程序的動(dòng)態(tài)行為信息，包括分析軟件的覆蓋率、監(jiān)控內(nèi)存的狀態(tài)、分析執(zhí)行軌跡、提取程序不變式等[3]。同時(shí)，針對(duì)Web應(yīng)用中的SQL注入漏洞已有很多工具得到了廣泛應(yīng)用，如HPFortify SCA[4]、Coverity[5]等。

近年來，隨著無線通信技術(shù)和移動(dòng)互聯(lián)網(wǎng)迅猛發(fā)展，移動(dòng)終端普及率快速提高。據(jù)CNNIC（China Internet Network Information Center）第39次《中國互聯(lián)網(wǎng)絡(luò)發(fā)展?fàn)顩r統(tǒng)計(jì)報(bào)告》[6]，截至2016年12月，我國手機(jī)網(wǎng)民規(guī)模已達(dá)到6.95億，臺(tái)式電腦、筆記本的上網(wǎng)比例則持續(xù)下降，網(wǎng)民上網(wǎng)設(shè)備進(jìn)一步向移動(dòng)端集中。其中，據(jù)CNNIC《2015年中國手機(jī)網(wǎng)民網(wǎng)絡(luò)安全狀況報(bào)告》[7]，使用Android操作系統(tǒng)的手機(jī)占67.4%。根據(jù)Veracode 2016年發(fā)布的軟件安全狀態(tài)報(bào)告，在Android應(yīng)用存在的安全漏洞中，SQL注入漏洞位列第八[8]。然而，Coverity、FindBugs[9]等面向Web應(yīng)用的通用軟件質(zhì)量及安全漏洞檢測(cè)工具未關(guān)注移動(dòng)應(yīng)用的SQL注入特性，導(dǎo)致無法有效識(shí)別Android應(yīng)用中的SQL注入漏洞。此外，用于檢測(cè)SQL注入漏洞的方法未使用污點(diǎn)分析等技術(shù)，針對(duì)Android應(yīng)用進(jìn)行靜態(tài)污點(diǎn)分析的工具，如Flow-Droid[10]等，不支持直接檢測(cè)SQL注入漏洞，即使通過人工修改配置文件增加對(duì)SQL注入漏洞的描述，也只是分析SQL方法中的SQL參數(shù)是否被污染，沒有考慮應(yīng)用中是否對(duì)外部輸入進(jìn)行過合法性檢查，導(dǎo)致誤報(bào)率較高。

針對(duì)上述問題，本文提出了一種基于污點(diǎn)分析的Android應(yīng)用SQL注入漏洞靜態(tài)檢測(cè)方法。首先，根據(jù)Android應(yīng)用的字節(jié)碼文件進(jìn)行程序靜態(tài)分析，并在其上定位SQL注入漏洞的SQL方法和SQL參數(shù)；然后，通過靜態(tài)污點(diǎn)分析方法，檢測(cè)SQL參數(shù)是否來自外部輸入；最后，基于SQL注入的輸入驗(yàn)證機(jī)制，通過識(shí)別應(yīng)用中是否存在對(duì)污染的SQL參數(shù)進(jìn)行過合法性檢查，來判斷是否存在SQL注入漏洞。

本文的貢獻(xiàn)包括以下兩點(diǎn)：

（1）針對(duì)Android應(yīng)用，提出一種基于污點(diǎn)分析的SQL注入漏洞靜態(tài)檢測(cè)方法；

（2）基于所提出的方法實(shí)現(xiàn)了原型工具SQLInj，并設(shè)計(jì)了一組實(shí)驗(yàn)來驗(yàn)證所提出方法的有效性。

本文組織結(jié)構(gòu)如下：第2章介紹SQL注入漏洞模型；第3章詳細(xì)分析基于靜態(tài)分析的Android應(yīng)用SQL方法及參數(shù)定位；第4章介紹方法的原型工具實(shí)現(xiàn)和實(shí)驗(yàn)評(píng)估；第5章討論與本文相關(guān)的研究工作；第6節(jié)總結(jié)了本文的工作，并對(duì)下一步的研究計(jì)劃進(jìn)行展望。

2 SQL注入漏洞模型

SQL注入漏洞是發(fā)生在使用數(shù)據(jù)庫對(duì)數(shù)據(jù)進(jìn)行管理的應(yīng)用程序中的一種安全漏洞，其本質(zhì)是攻擊者通過表單等方式進(jìn)行外部輸入，在應(yīng)用程序中預(yù)先定義好的數(shù)據(jù)庫查詢語句中插入惡意的SQL語句，篡改其含義來欺騙數(shù)據(jù)庫服務(wù)器執(zhí)行非授權(quán)的查詢[11]，通過這些操作獲得數(shù)據(jù)庫信息，非法讀取、修改、添加、刪除數(shù)據(jù)，私自添加賬號(hào)，注入木馬等其他病毒。

攻擊者一般通過構(gòu)造有特殊含義的SQL語句進(jìn)行SQL注入攻擊，攻擊方式大致可以分為以下幾類[12-13]：重言式與注釋符攻擊、非法/邏輯錯(cuò)誤查詢攻擊、聯(lián)合查詢攻擊、推斷攻擊、基于存儲(chǔ)過程或函數(shù)攻擊、復(fù)合查詢攻擊、編碼替換攻擊等。

對(duì)于每種SQL注入攻擊方式，其注入的字符串中通常會(huì)包含不同的敏感字符，這些字符是SQL語言中定義的擁有特殊含義的字符，攻擊者就是通過這些字符篡改原SQL指令。將各類SQL注入攻擊方式可能采用的敏感字符進(jìn)行了整理，如表1所示。

Table 1 SQL injection sensitive characters表1 SQL注入敏感字符

為了能夠檢測(cè)出Android應(yīng)用中的SQL注入漏洞，首先需要對(duì)SQL注入漏洞進(jìn)行建模和分析，然后在此基礎(chǔ)上對(duì)程序進(jìn)行靜態(tài)分析，并在代碼中定位SQL注入攻擊的SQL方法和SQL參數(shù)，最后通過污點(diǎn)分析及判斷合法性檢查判定程序中是否存在SQL注入漏洞。

假設(shè)將由若干語句（statement）組成的Android應(yīng)用程序（program）表示為P={s1,s2,…,sn}，則可將SQL注入漏洞模型定義如下：

（1）SQL方法為語句集合SSQL?P中的元素，其中，對(duì)任意的語句si∈SSQL，si為SQL操作語句，SQL操作語句包括rawQuery、execSQL、query等與數(shù)據(jù)庫訪問相關(guān)的API調(diào)用。

（2）對(duì)于SQL方法si，變量集合Pari={pari,1,pari,2,…,pari,m}為si所使用的參數(shù)，其中，pari,j∈Pari即為si的SQL參數(shù)。

（3）對(duì)于任意的SQL參數(shù)pari,j∈Pari若其與P的外部輸入相關(guān)，且在使用前未進(jìn)行過合法性檢查，則認(rèn)為SQL方法si存在SQL注入漏洞。

以圖1所示的代碼片段為例，其功能為當(dāng)USER表中存在用戶輸入的用戶名且其密碼也正確時(shí)允許其登錄。首先，分析程序發(fā)現(xiàn)第5行為SQL方法android.database.sqlite.SQLiteDatabase.rawQuery；然后，分析該SQL方法rawQuery中的SQL參數(shù)為sql和null；最后，對(duì)SQL參數(shù)進(jìn)行分析，其中，參數(shù)sql在第3行通過字符串username和password拼接而來，而username和password是應(yīng)用登錄界面用戶輸入的用戶名和密碼，因此SQl參數(shù)sql與外部輸入有關(guān)，且在SQL方法rawQuery執(zhí)行前，程序并沒有對(duì)SQL參數(shù)sql進(jìn)行合法性檢查，因此，可以判斷SQL方法raw-Query處存在SQL注入漏洞。若攻擊者在用戶名和密碼處均輸入“1’OR‘1’=‘1”，則會(huì)通過SQL方法rawQuery中的SQL參數(shù)sql，將外部輸入傳遞到后臺(tái)數(shù)據(jù)庫中。此時(shí)執(zhí)行的SQL查詢語句的形式為：

SELECT*from USER WHERE USERNAME=‘1’OR‘1’=‘1’AND PASSWORD=‘1’OR‘1’=‘1’;

在這種情況下，該SQL查詢語句的結(jié)果恒為真，將會(huì)成功利用SQL注入漏洞進(jìn)行攻擊，攻擊者無需正確的用戶名和密碼即可直接登錄。

Fig.1 Example of SQL injection圖1 SQL注入示例

3 基于污點(diǎn)分析的Android應(yīng)用SQL注入漏洞靜態(tài)檢測(cè)技術(shù)

針對(duì)缺少專用的Android應(yīng)用SQL注入漏洞檢測(cè)工具，而現(xiàn)有的通用檢測(cè)工具用于檢測(cè)Android應(yīng)用SQL注入漏洞時(shí)精確度較低的問題，本文提出了一種靜態(tài)檢測(cè)Android應(yīng)用中潛在SQL注入漏洞的方法。如圖2所示，首先，通過靜態(tài)分析處理程序的結(jié)構(gòu)，獲得程序的控制流圖和數(shù)據(jù)流圖，并在程序中定位SQL方法和SQL參數(shù)；然后，對(duì)程序進(jìn)行靜態(tài)污點(diǎn)分析，判斷SQL方法中的參數(shù)是否來自外部輸入；最后，對(duì)于使用了污點(diǎn)數(shù)據(jù)的SQL方法，要判斷應(yīng)用中是否對(duì)其中的SQL參數(shù)進(jìn)行了合法性檢查，若不存在合法性檢查，則認(rèn)為這一條SQL方法存在SQL注入漏洞。

Fig.2 Flowchart of static detection approach for SQL injection vulnerability inAndroid applications圖2 Android應(yīng)用中SQL注入漏洞靜態(tài)檢測(cè)方法流程圖

3.1 基于靜態(tài)分析的SQL方法及參數(shù)定位

為了能夠?qū)Υa進(jìn)行靜態(tài)檢測(cè)，需要對(duì)程序的結(jié)構(gòu)進(jìn)行靜態(tài)分析，使用合適的數(shù)據(jù)結(jié)構(gòu)來描述代碼。為擴(kuò)大方法的適用范圍，靜態(tài)分析的對(duì)象采用了Android應(yīng)用的字節(jié)碼文件而非源代碼。首先對(duì)程序進(jìn)行靜態(tài)分析，通過控制流分析、數(shù)據(jù)流分析等技術(shù)剖析程序的結(jié)構(gòu)；然后在程序中定位SQL注入漏洞模型中的SQL方法及相應(yīng)SQL參數(shù)。圖3為通過靜態(tài)分析定位Android應(yīng)用SQL注入相關(guān)SQL方法及SQL參數(shù)的流程圖。對(duì)于應(yīng)用的class文件以及依賴的jar文件，首先需要對(duì)字節(jié)碼進(jìn)行控制流分析?？刂屏鞅硎境绦虻膯蝹€(gè)語句、指令或者函數(shù)調(diào)用的順序，通過有向圖表示控制流，形成控制流圖?？刂屏鲌D表示了程序執(zhí)行過程中所有可能遍歷的路徑，它的每個(gè)結(jié)點(diǎn)是一個(gè)基本塊，有向邊指明了基本塊間的執(zhí)行關(guān)系。控制流只能從基本塊中的第一個(gè)指令進(jìn)入該塊，除了基本塊的最后一個(gè)指令，控制流在離開基本塊之前不會(huì)停機(jī)或者跳轉(zhuǎn)[14]。確定了基本塊之后，就可以根據(jù)條件或無條件轉(zhuǎn)移指令來識(shí)別基本塊間的前后流通關(guān)系，以此建立字節(jié)碼文件的控制流圖。

Fig.3 Process of locating SQL method and parameter based on static analysis圖3 基于靜態(tài)分析的SQL方法及參數(shù)定位流程

有了控制流圖之后，可以對(duì)程序進(jìn)行進(jìn)一步的數(shù)據(jù)流分析。數(shù)據(jù)流分析是一種用于獲取程序中數(shù)據(jù)是如何沿著程序執(zhí)行路徑進(jìn)行流動(dòng)的信息的技術(shù)。在數(shù)據(jù)流分析中，通過對(duì)一組約束求解，就可以得到每個(gè)點(diǎn)上的數(shù)據(jù)流值，可分為基于語句語義約束和基于控制流約束。本文采用的是基于控制流約束方法，即在基本塊之內(nèi)時(shí)，每條語句輸出的數(shù)據(jù)流就是下一條語句輸入的數(shù)據(jù)流。在基本塊之間時(shí)，每條控制流邊都對(duì)應(yīng)著新的約束，通過反復(fù)計(jì)算使系統(tǒng)達(dá)到穩(wěn)定。

根據(jù)定義的SQL注入漏洞模型，遍歷所有方法的控制流圖，關(guān)注其中用于方法調(diào)用的指令，定位使用SQL方法的位置信息。對(duì)SQL方法的參數(shù)進(jìn)行數(shù)據(jù)流分析，定位每個(gè)SQL參數(shù)的位置、參數(shù)標(biāo)識(shí)等信息。可以定位程序中調(diào)用的所有SQL方法，以及每個(gè)SQL方法對(duì)應(yīng)的SQL參數(shù)信息。定位SQL方法和SQL參數(shù)后，調(diào)用靜態(tài)污點(diǎn)分析功能，分析對(duì)應(yīng)的SQL參數(shù)是否來自外部輸入。對(duì)于使用了外部輸入作為參數(shù)的SQL方法，需要進(jìn)一步驗(yàn)證程序中是否針對(duì)其SQL參數(shù)進(jìn)行過合法性檢查。

3.2 面向SQL注入漏洞的污點(diǎn)分析

本文提出的靜態(tài)檢測(cè)SQL注入漏洞方法的核心就是對(duì)程序進(jìn)行靜態(tài)污點(diǎn)分析。本文使用的程序靜態(tài)分析部分是基于FindBugs使用的BCEL框架，可對(duì)應(yīng)用的字節(jié)碼進(jìn)行處理。靜態(tài)污點(diǎn)分析通?？煞譃檫^程內(nèi)污點(diǎn)傳播和過程間污點(diǎn)傳播兩類?？紤]到部分應(yīng)用會(huì)使用特定的數(shù)據(jù)結(jié)構(gòu)來存儲(chǔ)數(shù)據(jù)，如數(shù)組、Map等，增加了特殊數(shù)據(jù)結(jié)構(gòu)污點(diǎn)傳播。下面將分別對(duì)3種靜態(tài)污點(diǎn)傳播規(guī)則進(jìn)行介紹。

3.2.1 特殊數(shù)據(jù)結(jié)構(gòu)污點(diǎn)傳播規(guī)則

對(duì)于外部輸入的數(shù)據(jù)，很多程序都是選擇直接通過字符串進(jìn)行存儲(chǔ)和修改。但是，除此之外，有時(shí)會(huì)使用特定的數(shù)據(jù)結(jié)構(gòu)來存儲(chǔ)數(shù)據(jù)，如數(shù)組、Map等。下面分別為數(shù)組結(jié)構(gòu)、實(shí)現(xiàn)Collection接口和Map接口的類中的污點(diǎn)傳播規(guī)則。

（1）數(shù)組結(jié)構(gòu)

對(duì)于數(shù)組結(jié)構(gòu)，可以將其視為一個(gè)整體進(jìn)行處理。如果將一個(gè)污點(diǎn)數(shù)據(jù)傳遞給數(shù)組的一個(gè)元素，那么就將整個(gè)數(shù)組都標(biāo)記為污染，而不是只將該索引位置標(biāo)記。然后，對(duì)污染數(shù)組的所有讀寫操作都會(huì)將污染傳播。

如圖4中所示的代碼片段，字符串taintStr為污染數(shù)據(jù)，在第3行將其賦值給數(shù)組spreadArray的第2個(gè)元素時(shí)，將整個(gè)spreadArray標(biāo)記為污點(diǎn)數(shù)據(jù)。然后在第4行將spreadArray的第一個(gè)元素賦值給字符串str時(shí)，雖然之前并沒有將污點(diǎn)數(shù)據(jù)賦值給spreadArray[0]，但是整個(gè)spreadArray數(shù)組空間都被標(biāo)記為污染了，因此str也會(huì)被標(biāo)記為污點(diǎn)數(shù)據(jù)。

Fig.4 Array taint propagation圖4 數(shù)組污點(diǎn)傳播

（2）Collection接口和Map接口

Java語言中定義了Collection和Map作為所有集合和Map類的接口，開發(fā)者可以通過實(shí)現(xiàn)這些接口的子類來更加方便地組織復(fù)雜的數(shù)據(jù)，如List、Hash-Set、TreeMap等。因此，本文方法也要對(duì)這些結(jié)構(gòu)體進(jìn)行污點(diǎn)傳播處理。這些結(jié)構(gòu)體的污點(diǎn)傳播規(guī)則與數(shù)組類型相似，也是將結(jié)構(gòu)體當(dāng)作一個(gè)整體進(jìn)行污點(diǎn)標(biāo)記，即只要將一個(gè)污染數(shù)據(jù)傳遞給結(jié)構(gòu)體，就將整個(gè)結(jié)構(gòu)體視為污染。然后對(duì)于點(diǎn)運(yùn)算符“.”，取最左邊對(duì)象的污染信息，如a.b.c的污染信息即為a的污染信息。

3.2.2 過程內(nèi)污點(diǎn)傳播規(guī)則

過程內(nèi)污點(diǎn)傳播是以方法為單位進(jìn)行的。圖5為過程內(nèi)污點(diǎn)分析的流程，對(duì)于每個(gè)方法，需要一個(gè)污點(diǎn)數(shù)據(jù)集實(shí)時(shí)記錄方法中的污點(diǎn)信息。先初始化污點(diǎn)數(shù)據(jù)集，并將參數(shù)污點(diǎn)信息和與外部輸入有關(guān)的方法、變量加入污點(diǎn)數(shù)據(jù)集。然后遍歷程序，根據(jù)指令類型進(jìn)行相應(yīng)的操作：對(duì)于變量讀取指令，記錄變量的污點(diǎn)信息；對(duì)于普通賦值指令，若之前讀取了污點(diǎn)數(shù)據(jù)，則該指令把污點(diǎn)數(shù)據(jù)賦值給當(dāng)前變量，并將該變量加入污點(diǎn)數(shù)據(jù)集；對(duì)于特殊結(jié)構(gòu)體讀寫指令，進(jìn)行特殊數(shù)據(jù)結(jié)構(gòu)污點(diǎn)傳播；對(duì)于方法調(diào)用指令，若該指令調(diào)用子方法，則進(jìn)行過程間污點(diǎn)傳播，若其對(duì)結(jié)構(gòu)體進(jìn)行操作，則進(jìn)行特殊數(shù)據(jù)結(jié)構(gòu)污點(diǎn)傳播，若其是預(yù)先定義好的配置文件中的方法，表示其會(huì)把污點(diǎn)標(biāo)記從參數(shù)傳播到方法返回值，則將返回值加入污點(diǎn)數(shù)據(jù)集；對(duì)于方法返回指令，其是方法中最后一條指令，在記錄方法的參數(shù)和返回值的污點(diǎn)信息后，輸出整個(gè)污點(diǎn)數(shù)據(jù)集。其算法描述如算法1。

算法1過程內(nèi)污點(diǎn)傳播算法

輸入：CFGcfg，F(xiàn)ileconfig//污染源配置文件JavaClassjavaclass//字節(jié)碼文件

輸出：HashSetTaintSet//方法污點(diǎn)數(shù)據(jù)集

3.2.3 過程間污點(diǎn)傳播規(guī)則

本文采用的過程間污點(diǎn)傳播規(guī)則為：對(duì)于進(jìn)行了過程內(nèi)污點(diǎn)傳播的方法，傳播結(jié)束時(shí)會(huì)記錄此方法的參數(shù)和返回值污點(diǎn)信息。因此，首先分析被調(diào)用方法參數(shù)，若是之前掃描過該方法，且參數(shù)污點(diǎn)信息相同，則直接獲取掃描時(shí)返回值的污點(diǎn)信息；否則，將參數(shù)的污點(diǎn)信息傳遞給被調(diào)用方法，對(duì)其進(jìn)行過程內(nèi)污點(diǎn)傳播，然后將其返回值的污點(diǎn)信息返回給調(diào)用該方法的位置。其算法描述如算法2所示。

算法2過程間污點(diǎn)傳播算法

輸入：Methodcall//源方法

Methodcalled//子方法

HashMapAnalysisedMap＜StringpamInfo,StringresultInfo＞//記錄進(jìn)行過程內(nèi)污點(diǎn)分析的方法的參數(shù)和返回值污點(diǎn)信息，pamInfo為方法調(diào)用時(shí)參數(shù)污點(diǎn)信息，resultInfo為方法返回值污點(diǎn)信息

輸出：Stringresultinfo//子方法返回值污點(diǎn)信息

1.獲取子方法called參數(shù)污點(diǎn)信息paminfo

Fig.5 In-process taint propagation圖5 過程內(nèi)污點(diǎn)傳播

3.3 合法性檢查

對(duì)于使用了來自外部輸入?yún)?shù)的數(shù)據(jù)庫執(zhí)行方法，還無法確定其中確實(shí)存在SQL注入漏洞。若應(yīng)用中對(duì)數(shù)據(jù)庫查詢語句的參數(shù)進(jìn)行過合法性檢查，就可以避免出現(xiàn)SQL注入的問題。因此，在進(jìn)行污點(diǎn)分析以后，還要判斷應(yīng)用中是否對(duì)使用了污點(diǎn)數(shù)據(jù)的SQL方法中的SQL參數(shù)進(jìn)行過合法性檢查。常見的合法性檢查的方法有以下幾種：

（1）參數(shù)化方法。很多數(shù)據(jù)庫都提供了參數(shù)化的方法，使用這些方法執(zhí)行SQL語句時(shí)，數(shù)據(jù)庫服務(wù)器先是對(duì)SQL指令進(jìn)行編譯，然后再將參數(shù)代入，而不是將參數(shù)也當(dāng)成語句的一部分。因此，即使參數(shù)中存在惡意片段，也不會(huì)被數(shù)據(jù)庫執(zhí)行。比如Android應(yīng)用中可以使用compileStatement方法，將其中外部輸入都用“？”代替，然后通過相應(yīng)的bind方法對(duì)參數(shù)進(jìn)行配置，這樣就不會(huì)存在SQL注入問題。

（2）白名單驗(yàn)證。若開發(fā)者已經(jīng)知道某些形式的參數(shù)不會(huì)導(dǎo)致SQL注入漏洞，則可以在執(zhí)行數(shù)據(jù)庫操作前將參數(shù)與這些安全的形式進(jìn)行驗(yàn)證。比如通過Pattern.matcher與事先定義好的模式進(jìn)行匹配，或者通過String提供的方法判斷參數(shù)中是否存在敏感字符等。而本文在掃描前兩層基本塊中，若是執(zhí)行到調(diào)用了白名單驗(yàn)證使用的方法，且其參數(shù)為正在檢測(cè)的數(shù)據(jù)庫執(zhí)行語句的污點(diǎn)數(shù)據(jù)參數(shù)，就認(rèn)為程序中對(duì)這條SQL方法進(jìn)行過合法性檢查。

（3）過濾、轉(zhuǎn)義敏感字符。實(shí)現(xiàn)過濾或轉(zhuǎn)義敏感字符的一個(gè)常用方法就是使用replace之類的方法對(duì)表1中的敏感字符進(jìn)行操作，如圖6中第6行使用的Matcher.replaceAll方法。當(dāng)掃描的前兩個(gè)基本塊中包含對(duì)敏感字符的過濾或者轉(zhuǎn)義處理，也能認(rèn)為應(yīng)用中進(jìn)行了合法性檢查。

如算法3所示，本文只考慮使用了污染數(shù)據(jù)的SQL方法所在基本塊及前兩層的所有基本塊，掃描這些基本塊中是否對(duì)指定的SQL參數(shù)進(jìn)行過合法性檢查。如圖6中的代碼片段，第10行中的SQL方法rawQuery位于基本塊B4中，且其參數(shù)sql為污點(diǎn)數(shù)據(jù)。則先檢查B4在執(zhí)行該方法前是否對(duì)sql進(jìn)行過合法性檢查，若沒進(jìn)行過就依次掃描上一層基本塊B3、B2，若上一層仍未進(jìn)行合法性檢查，就再依次掃描兩層前的基本塊，該示例中僅有基本塊B1。最終，若SQL方法所在基本塊及前兩層基本塊都未進(jìn)行過合法性檢查，則可以認(rèn)為這個(gè)使用了污點(diǎn)數(shù)據(jù)的SQL方法存在SQL注入漏洞。在這個(gè)示例中，位于基本塊B3的第6行代碼進(jìn)行了合法性檢查，則第10行的數(shù)據(jù)庫執(zhí)行方法是安全的。

Fig.6 Examples of legitimate check圖6 合法性檢查示例

算法3合法性檢查判斷

輸入：Fileconfig//合法性檢查相關(guān)方法配置文件

Stringpam//SQL方法中使用的污染參數(shù)

CFGcfg，Methodmethod，Locationloc

輸出：Boolean//是否進(jìn)行過合法性檢查

4 工具實(shí)現(xiàn)與實(shí)驗(yàn)

4.1 原型工具實(shí)現(xiàn)

在Java代碼靜態(tài)分析工具FindBugs的基礎(chǔ)上，本文實(shí)現(xiàn)了基于污點(diǎn)分析的Android應(yīng)用SQL注入漏洞靜態(tài)檢測(cè)原型工具SQLInj。SQLInj首先靜態(tài)分析Android應(yīng)用的字節(jié)碼文件，在程序中定位SQL注入漏洞的SQL方法和SQL參數(shù)，然后通過靜態(tài)污點(diǎn)分析技術(shù)檢測(cè)SQL語句中的污點(diǎn)數(shù)據(jù)，最后判斷程序是否對(duì)SQL方法中使用的污點(diǎn)數(shù)據(jù)進(jìn)行過合法性檢查來報(bào)告是否存在SQL注入漏洞。如圖7所示，SQLInj的總體框架主要分為程序靜態(tài)分析、污點(diǎn)分析及合法性檢查3個(gè)模塊。

4.1.1 程序靜態(tài)分析

FindBugs中實(shí)現(xiàn)了對(duì)字節(jié)碼的控制流分析，在控制流圖基礎(chǔ)上，能得到每條指令的數(shù)據(jù)流信息。FindBugs中提供了很多種數(shù)據(jù)流信息，如當(dāng)前指令所活躍的數(shù)據(jù)是否為常量、空值等，本文使用ConstantDataflow和ValueNumberDataflow來判斷參數(shù)是否為常量字符串及其名稱，并對(duì)FindBugs中提供的ValueNumberDataflow相關(guān)方法進(jìn)行了修改，使得在進(jìn)行ValueNumber數(shù)據(jù)流分析后，能同時(shí)獲取局部變量和全局變量的名稱。

4.1.2 靜態(tài)污點(diǎn)分析

靜態(tài)污點(diǎn)分析需要兩個(gè)配置文件：source.config和derivation.config。其中，source.config文件中記錄了與污染源有關(guān)的方法，在靜態(tài)污點(diǎn)分析中，根據(jù)其配置污染源并初始化污點(diǎn)數(shù)據(jù)集。derivation.config文件中是能夠?qū)⑽埸c(diǎn)標(biāo)記從污染數(shù)據(jù)傳播給新數(shù)據(jù)的方法。首先，按照配置文件識(shí)別污染數(shù)據(jù)；然后，根據(jù)污點(diǎn)傳播規(guī)則將所有被外部輸入影響的方法和變量進(jìn)行標(biāo)記；最后，判斷當(dāng)前的SQL方法是否使用了被污染的參數(shù)。

4.1.3 合法性檢查

在配置文件legimacy.config中定義了3.3節(jié)中所介紹的合法性檢查相關(guān)的方法。根據(jù)合法性檢查判斷規(guī)則，如果使用了污點(diǎn)數(shù)據(jù)的SQL方法所在的基本塊以及前兩層的基本塊中使用過legimacy.config文件中定義的方法，即認(rèn)為程序中對(duì)這條SQL方法進(jìn)行過合法性檢查。

Fig.7 General framework of SQLInj圖7 SQLInj總體框架

4.1.4 檢測(cè)結(jié)果報(bào)告

當(dāng)掃描完程序所有字節(jié)碼文件后，SQLInj會(huì)輸出最終的SQL注入漏洞檢測(cè)結(jié)果，報(bào)告所有SQL注入漏洞的SQL方法所在的類、方法、在源文件中的具體行數(shù)，以及具體是哪一個(gè)數(shù)據(jù)庫執(zhí)行方法等信息。圖8為檢測(cè)結(jié)果報(bào)告中的一條錯(cuò)誤信息示例，從中能夠看到該SQL注入漏洞發(fā)生在MainActivity類的SQLInjectTest方法中，漏洞產(chǎn)生的原因是在此方法中將一個(gè)污染數(shù)據(jù)傳遞給SQL方法android.database.sqlite.SQLiteDatabase.rawQuery，該SQL方法位于源代碼MainActivity.java的第118行。

Fig.8 Example of SQLInj detection result圖8 SQLInj檢測(cè)結(jié)果示例

4.2 實(shí)驗(yàn)設(shè)計(jì)與分析

使用SQLInj檢測(cè)只需要Android應(yīng)用的APK文件，但由于需要確認(rèn)誤報(bào)情況，因此實(shí)驗(yàn)選擇了SQLInject、sieve等6個(gè)確定存在SQL注入漏洞的開源Android應(yīng)用進(jìn)行實(shí)驗(yàn)。如表2所示，6個(gè)實(shí)驗(yàn)對(duì)象的規(guī)模從500行到20 000行不等，表2中的第3列給出了應(yīng)用功能的簡要描述。

為評(píng)估本文所使用方法在檢測(cè)SQL注入漏洞上的有效性，擴(kuò)展了FindBugs原有的SQL漏洞注入檢測(cè)功能，在不改變其檢測(cè)機(jī)制的基礎(chǔ)上，使其能夠支持檢測(cè)Android應(yīng)用SQL注入漏洞。將FindBugs運(yùn)行的結(jié)果與SQLInj的結(jié)果進(jìn)行對(duì)比，可以驗(yàn)證使用污點(diǎn)分析及合法性檢查判斷對(duì)檢測(cè)結(jié)果精度的影響。

4.3 實(shí)驗(yàn)結(jié)果分析

表3是SQLInj對(duì)6個(gè)應(yīng)用的檢測(cè)結(jié)果，其中已知漏洞為每個(gè)應(yīng)用中已知存在SQL注入漏洞的SQL方法數(shù)量，污染方法是進(jìn)行靜態(tài)污點(diǎn)分析發(fā)現(xiàn)使用了污點(diǎn)數(shù)據(jù)的SQL方法的數(shù)量，疑似漏洞數(shù)是通過合法性檢查判斷后，存在SQL注入漏洞的SQL方法數(shù)量。然后，通過對(duì)每個(gè)應(yīng)用中檢測(cè)出的疑似漏洞進(jìn)行判斷，分析此處是否真實(shí)存在SQL注入漏洞。經(jīng)分析確實(shí)存在的SQL注入漏洞為確認(rèn)漏洞，未被檢測(cè)到的SQL注入漏洞為漏報(bào)漏洞。表中第6列和第7列為SQLInj的漏報(bào)情況。實(shí)驗(yàn)結(jié)果表明，SQLInj在6個(gè)Android應(yīng)用中共檢測(cè)出35個(gè)SQL注入漏洞。對(duì)檢測(cè)出的SQL注入漏洞進(jìn)行檢查發(fā)現(xiàn)，對(duì)其中4個(gè)應(yīng)用的分析未出現(xiàn)漏報(bào)，2個(gè)應(yīng)用的分析存在漏報(bào)，平均漏報(bào)率為9.1%。對(duì)產(chǎn)生漏報(bào)的原因進(jìn)行分析發(fā)現(xiàn)，在進(jìn)行污點(diǎn)分析時(shí)，為了提高分析效率，采取了記錄執(zhí)行過的過程內(nèi)污點(diǎn)分析方法的參數(shù)及返回值等污點(diǎn)信息，當(dāng)再次調(diào)用同一方法時(shí)，不再進(jìn)行過程內(nèi)污點(diǎn)分析，直接采用之前的污點(diǎn)分析信息。這一措施導(dǎo)致若某方法使用的全局變量在首次調(diào)用時(shí)與外部輸入無關(guān)，但在之后的調(diào)用中與外部輸入相關(guān)時(shí)，會(huì)產(chǎn)生漏報(bào)。實(shí)驗(yàn)結(jié)果表明，本文所使用的方法能有效檢測(cè)出Android應(yīng)用中的90%以上的SQL注入漏洞，漏報(bào)率較低。而FindBugs通過檢測(cè)SQL方法的參數(shù)是否為常量字符串來判斷此處是否存在SQL注入漏洞，因此基本不會(huì)發(fā)生漏報(bào)的現(xiàn)象，但精確度較低。

Table 2 Description of experimental objects表2 實(shí)驗(yàn)對(duì)象說明

Table 3 Detection results of SQLInj表3 SQLInj檢測(cè)結(jié)果

SQLInj與FindBugs的誤報(bào)情況對(duì)比如表4所示。使用FindBugs分析的誤報(bào)率最低為33.3%，最高的達(dá)到85.1%，平均誤報(bào)率為62.5%。使用SQLInj的誤報(bào)率最低為0，最高為25.0%，平均誤報(bào)率為7.5%。這是因?yàn)橹灰獢?shù)據(jù)庫執(zhí)行方法的參數(shù)為諸如方法返回值、外部傳參、字符串拼接等，F(xiàn)indBugs就會(huì)認(rèn)為存在SQL注入漏洞，而SQLInj只有當(dāng)SQL方法的參數(shù)與外部輸入有關(guān)且未進(jìn)行合法性檢查時(shí)才認(rèn)為存在SQL注入漏洞。SQLInj存在誤報(bào)的原因是SQLInj不能檢測(cè)出應(yīng)用在SQL方法前兩層基本塊之前進(jìn)行的敏感字符過濾等合法性檢查，誤報(bào)存在SQL注入漏洞。實(shí)驗(yàn)結(jié)果表明，本文所使用的基于污點(diǎn)分析的SQL注入漏洞靜態(tài)檢測(cè)方法有效降低了誤報(bào)率。

Table 4 Comparison of false positive表4 誤報(bào)情況對(duì)比

此外，還使用了綜合評(píng)價(jià)指標(biāo)來評(píng)價(jià)SQLInj和FindBugs檢測(cè)結(jié)果的綜合性能。將檢測(cè)結(jié)果的確認(rèn)漏洞稱為TP，表示檢測(cè)存在SQL注入漏洞且確實(shí)存在SQL注入漏洞的SQL方法數(shù)量。將疑似漏洞與確實(shí)漏洞的差稱為FP，表示檢測(cè)存在SQL注入漏洞，但其實(shí)是安全的SQL方法數(shù)量。將已知漏洞與確實(shí)漏洞的差稱為FN，表示沒有檢測(cè)出但實(shí)際存在SQL注入漏洞的SQL方法數(shù)量。準(zhǔn)確率P=TP/(TP+FP)，表示被正確檢測(cè)出的SQL方法中確實(shí)存在SQL注入漏洞的比例；召回率R=TP/(TP+FN)，表示所有確實(shí)存在SQL注入漏洞的SQL方法中被正確檢測(cè)出來的比例；綜合評(píng)價(jià)指標(biāo)F值F=2PR/(P+R)，表示準(zhǔn)確率和召回率的加權(quán)調(diào)和平均，綜合了準(zhǔn)確率和召回率的結(jié)果，有利于對(duì)檢測(cè)結(jié)果綜合性能的評(píng)價(jià)[15]。

SQLInj與FindBugs的綜合評(píng)價(jià)標(biāo)準(zhǔn)F值對(duì)比結(jié)果如表5所示。FindBugs的F值最低為0.27，最高為0.80，平均值為0.53。SQLInj的F值最低為0.78，最高為1.00，平均值為0.91，比FindBugs高了約38%。因此，本文所使用的基于污點(diǎn)分析的SQL注入漏洞靜態(tài)檢測(cè)方法的綜合性能更好。

Table 5 Comprehensive contrast between FindBugs and SQLInj表5 FindBugs與SQLInj綜合對(duì)比情況

4.4 有效性影響因素分析

本文提出的方法能夠有效地檢測(cè)出Android應(yīng)用中存在的SQL注入漏洞，并降低了誤報(bào)率。但是該方法的效果仍受到以下方面限制：

（1）實(shí)驗(yàn)數(shù)據(jù)集的代表性。為了驗(yàn)證SQLInj檢測(cè)結(jié)果的正確性，選擇使用開源的Android應(yīng)用進(jìn)行實(shí)驗(yàn)，況且樣本數(shù)量也還不夠，需要提高實(shí)驗(yàn)數(shù)據(jù)集的代表性。

（2）本文方法仍存在漏報(bào)問題。主要原因?yàn)镕indBugs按照調(diào)用樹自底向上掃描方法所在class文件中的所有方法，這導(dǎo)致個(gè)別方法在被調(diào)用前就已經(jīng)被掃描過了，當(dāng)此方法被調(diào)用時(shí)若其所在類的全局變量曾被改變，將使得此方法返回值污染信息發(fā)生變化，但如果此方法參數(shù)的污點(diǎn)信息與第一次掃描時(shí)相同，不會(huì)再重新掃描，可能會(huì)產(chǎn)生漏報(bào)。此外，合法性檢查不夠精確也可能會(huì)導(dǎo)致漏報(bào)。通過掃描SQL方法前兩層基本塊中是否進(jìn)行了合法性檢查來判斷是否存在SQL注入，若程序中進(jìn)行了合法性檢查，但檢查條件并不準(zhǔn)確，可能會(huì)導(dǎo)致檢查后SQL參數(shù)中仍存在會(huì)導(dǎo)致SQL注入的字符串，從而引起漏報(bào)。

（3）本文方法仍存在誤報(bào)問題。只掃描SQL方法前兩層基本塊中是否進(jìn)行了合法性檢查，當(dāng)程序中合法性檢查的位置與SQL方法距離較遠(yuǎn)時(shí)，可能會(huì)產(chǎn)生誤報(bào)。

5 相關(guān)研究現(xiàn)狀

由于SQL注入漏洞的風(fēng)險(xiǎn)性以及普遍性，如何檢測(cè)SQL注入漏洞的問題引起了很多國內(nèi)外學(xué)者的關(guān)注，目前已經(jīng)做出了大量的研究工作，主要分為靜態(tài)分析和動(dòng)態(tài)測(cè)試兩大類。另外，因?yàn)楸疚姆椒ㄖ饕谖埸c(diǎn)分析技術(shù)，所以對(duì)使用污點(diǎn)分析的相關(guān)工作也進(jìn)行了總結(jié)。

5.1 靜態(tài)分析技術(shù)

程序靜態(tài)分析是不需要程序?qū)嶋H運(yùn)行，而是在編譯時(shí)就獲得程序的相關(guān)屬性，在此基礎(chǔ)上對(duì)程序進(jìn)行分析的技術(shù)。文獻(xiàn)[16]對(duì)近幾年使用靜態(tài)檢測(cè)SQL注入的方法進(jìn)行了分析。符號(hào)執(zhí)行技術(shù)是靜態(tài)分析的一種，用來決定是哪些輸入導(dǎo)致程序每個(gè)片段執(zhí)行的分析方法。當(dāng)使用符號(hào)執(zhí)行來分析程序時(shí)，程序?qū)⒎?hào)作為值賦給變量，對(duì)程序的路徑進(jìn)行模擬執(zhí)行，精確分析程序的代碼屬性[2,17]。文獻(xiàn)[18-19]使用靜態(tài)方法檢測(cè)Web應(yīng)用中的SQL注入漏洞，文獻(xiàn)[20-22]則是通過靜態(tài)方法針對(duì)Android應(yīng)用進(jìn)行檢測(cè)。

除此之外，Coverity[5]和FindBugs[9]是使用較多的靜態(tài)軟件質(zhì)量及安全漏洞檢測(cè)工具。其中，Coverity使用過程間靜態(tài)分析、字節(jié)精度分析、虛假路徑剪枝等技術(shù)對(duì)軟件源碼進(jìn)行靜態(tài)分析，并提供了完整的路徑覆蓋，確保每一行代碼以及潛在的執(zhí)行路徑都能被測(cè)試；FindBugs則是對(duì)應(yīng)用的字節(jié)碼文件進(jìn)行數(shù)據(jù)流分析，并與漏洞缺陷模式進(jìn)行匹配。但是，兩者的SQL注入漏洞檢測(cè)功能主要是針對(duì)Web應(yīng)用的，無法對(duì)Android應(yīng)用進(jìn)行檢測(cè)。

5.2 動(dòng)態(tài)分析技術(shù)

動(dòng)態(tài)分析技術(shù)是將程序在真實(shí)或虛擬機(jī)上運(yùn)行，并對(duì)運(yùn)行過程進(jìn)行分析的方法。在靜態(tài)分析中，有很多情況被認(rèn)為是可能發(fā)生的，但在動(dòng)態(tài)分析中，其分析的路徑都是動(dòng)態(tài)執(zhí)行，確實(shí)發(fā)生了的，并且可以觀察到程序運(yùn)行時(shí)的狀態(tài)。Chess和West在2008年提出了一種檢測(cè)漏洞的動(dòng)態(tài)分析方法[23]。在SQL注入問題上，也有很多方法是使用動(dòng)態(tài)分析技術(shù)檢測(cè)的，如文獻(xiàn)[24-26]是動(dòng)態(tài)檢測(cè)Web應(yīng)用中的SQL注入漏洞，文獻(xiàn)[27]則將動(dòng)態(tài)技術(shù)應(yīng)用到檢測(cè)Android應(yīng)用上的SQL注入。

5.3 污點(diǎn)分析技術(shù)

污點(diǎn)分析可以分為靜態(tài)和動(dòng)態(tài)污點(diǎn)分析兩種。文獻(xiàn)[28-29]使用靜態(tài)污點(diǎn)分析技術(shù)檢測(cè)Android應(yīng)用中的安全漏洞，文獻(xiàn)[30]則提出一種在Java虛擬機(jī)中的動(dòng)態(tài)污點(diǎn)分析方法，并結(jié)合了靜態(tài)分析方法來收集可到達(dá)的方法，以減少運(yùn)行時(shí)開銷。在Android應(yīng)用污點(diǎn)分析中，F(xiàn)lowDroid[10]和TaintDroid[31]是兩個(gè)具有代表性的工具。FlowDroid是一款針對(duì)Android應(yīng)用的上下文、流、字段、對(duì)象敏感和生存周期感知的靜態(tài)污點(diǎn)分析工具，但其不支持SQL注入漏洞的檢測(cè)。TaintDroid則是通過動(dòng)態(tài)污點(diǎn)分析跟蹤信息流的流動(dòng)，但只會(huì)顯示數(shù)據(jù)流動(dòng)信息，而不會(huì)對(duì)漏洞進(jìn)行檢測(cè)。

6 結(jié)束語

本文針對(duì)Android應(yīng)用中的SQL注入漏洞，提出一種基于污點(diǎn)分析的SQL注入漏洞靜態(tài)檢測(cè)方法。該方法首先對(duì)應(yīng)用進(jìn)行靜態(tài)分析，在程序中定位SQL注入漏洞的SQL方法和SQL參數(shù)；然后通過靜態(tài)污點(diǎn)分析方法檢測(cè)SQL方法是否使用了污點(diǎn)數(shù)據(jù)；最后識(shí)別應(yīng)用中是否存在對(duì)污點(diǎn)數(shù)據(jù)進(jìn)行過合法性檢查?；谏鲜龇椒ǎ瑢?shí)現(xiàn)了原型工具SQLInj，并對(duì)存在SQL注入漏洞的Android應(yīng)用進(jìn)行了實(shí)驗(yàn)。

在本文研究的基礎(chǔ)上，計(jì)劃進(jìn)一步研究如何通過JPF-Android等工具自動(dòng)產(chǎn)生SQL注入攻擊，以驗(yàn)證SQL注入漏洞的存在，并在檢測(cè)出SQL注入后，嘗試在源碼中進(jìn)行漏洞修復(fù)。