上下文感知的安卓應(yīng)用程序漏洞檢測研究

秦佳偉，張華，嚴(yán)寒冰，何能強，涂騰飛

（1.北京郵電大學(xué)網(wǎng)絡(luò)與交換技術(shù)國家重點實驗室，北京 100876；2.國家計算機網(wǎng)絡(luò)應(yīng)急技術(shù)處理協(xié)調(diào)中心，北京 100029）

1 引言

近幾年，安卓應(yīng)用一直在快速增長中，但是隨之增長的還有應(yīng)用所產(chǎn)生的漏洞。2020 年，國家信息安全漏洞共享平臺（CNVD,China National Vulnerability Database）收錄安全漏洞中移動互聯(lián)網(wǎng)漏洞占全年收錄數(shù)量的8.0%。因為所有的軟件漏洞都存在被攻擊者潛在利用的可能[1-3]，所以發(fā)現(xiàn)漏洞并修復(fù)它，才是避免軟件遭受攻擊的有效方法。2018 年，PIAnalyzer[4]分析并提取了PendingIntent權(quán)限繞過漏洞的規(guī)則，基于靜態(tài)檢測的方法實現(xiàn)對改漏洞的檢測。目前，與Intent 機制相關(guān)的研究[5-12]主要關(guān)注APP 隱私泄露問題。過辰楷等[5]提出了一種基于安全要素語句插裝的泄露檢測方法。AmanDroid[7]通過跟蹤APP 組件間的交互信息來識別隱私泄露問題。

另外，為了降低人工依賴和提高對未知漏洞的發(fā)現(xiàn)能力，基于學(xué)習(xí)的漏洞檢測成為技術(shù)發(fā)展趨勢之一[13-25]。基于學(xué)習(xí)的漏洞檢測研究主要集中在Java 語言的漏洞方面。早期的基于學(xué)習(xí)的Java 源代碼漏洞檢測研究[21,24]解決了基于規(guī)則的漏洞檢測方法依賴人工經(jīng)驗的問題，但是漏洞代碼的抽象表示缺乏語義特征，從而影響漏洞識別的準(zhǔn)確率。2017 年，Ma 等[22]提出將Java 代碼轉(zhuǎn)換成抽象語法樹（AST,abstract syntax tree）的特征，然后采用機器學(xué)習(xí)模型來對Java 程序進行漏洞檢測。AST 特征可以保留程序?qū)ο笾g的語義信息，但是包含與漏洞代碼無關(guān)的噪聲數(shù)據(jù)會導(dǎo)致誤報[26-28]。Java 程序不具有APP 的生命周期特性和組件間通信機制（ICC,inter-component communication），所以無法適用于檢測無源碼的APP 的漏洞。2018 年，王持恒等[13]依據(jù)APP 的流量數(shù)據(jù)和權(quán)限列表信息采用聚類方法檢測廣告漏洞，但是該方法僅適用于廣告漏洞檢測場景。2021 年，Gencer 等[29]研究直接依賴于時間的APP 漏洞，并采用時間序列、多層感知器等多種模型生成了漏洞預(yù)警模型。

基于學(xué)習(xí)的APP 漏洞檢測缺少針對安卓本身運行機制所導(dǎo)致的漏洞的研究?，F(xiàn)有的2 種特征提取方法會導(dǎo)致漏洞檢測的準(zhǔn)確率下降。其中，基于代碼中關(guān)鍵字符串計數(shù)的特征方法無法表現(xiàn)語義信息，也無法體現(xiàn)漏洞的上下文關(guān)聯(lián)信息；AST 的漏洞提取方法會存在誤報[26-28]。在針對其他編程語言的程序漏洞檢測方面[15-16,19-20,30]，2019 年，Zou 等[15]針對C 語言的程序漏洞提出一種名為code gadgets的程序特征表示方法，由此設(shè)計并實現(xiàn)了基于深度學(xué)習(xí)的漏洞檢測系統(tǒng)。因為C 語言的程序分析不涉及對回調(diào)方法的處理，所以該方法無法直接適用于APP 漏洞檢測。安卓APP 不僅有Java 語言的漏洞，還有不正確地使用平臺的應(yīng)用程序接口（API,application program interface）所導(dǎo)致的漏洞，危害更嚴(yán)重。例如，安卓ICC 不僅允許同一個APP 的不同組件間進行數(shù)據(jù)傳遞，而且允許不同的APP 之間的數(shù)據(jù)傳遞。這就給APP 帶來了安全風(fēng)險——使用該機制實現(xiàn)的功能的各個對象的屬性設(shè)置都可能導(dǎo)致漏洞。因此不能通過Java 代碼的規(guī)則匹配檢測相關(guān)漏洞。

要實現(xiàn)針對安卓本身運行機制的漏洞檢測，且克服人工提取特征的局限性，需要解決以下3 個問題。1) 目前缺少可供深度學(xué)習(xí)使用的APP 漏洞數(shù)據(jù)集，如何獲取一批可用的數(shù)據(jù)集？2) 面對安卓應(yīng)用特有的ICC 方式和無主程序入口的運行啟動方式，如何進行程序分析和漏洞特征提??？3) APP 漏洞特征表示方法方面，如何在不缺少關(guān)鍵信息的情況下對程序進行語義化的特征抽象？

為了克服上述挑戰(zhàn)，本文以隱式Intent 通信漏洞（IISV,implicit Intent security vulnerability）和PendingIntent 權(quán)限繞過漏洞（BPPAV,bypass PendingIntent permission audit vulnerability）為研究對象，針對安卓運行機制導(dǎo)致的漏洞檢測提出了一種上下文感知的安卓應(yīng)用程序漏洞檢測方法。該方法可以從APP 中提取出只與漏洞相關(guān)的代碼信息，并且將特征代碼中的自定義函數(shù)名與變量名進行統(tǒng)一格式化處理，既保留語義邏輯性也具有可讀性。本文主要貢獻如下。

1) 本文從GooglePlay 獲取了5 000 個樣本，采用工具和人工分析的方法對其進行漏洞標(biāo)記，得到包含IIS 的漏洞樣本1 806 個和包含PLP 的漏洞樣本95 個，提取41 812 條特征代碼段。經(jīng)特征化處理后，本文數(shù)據(jù)集與APP 無直接關(guān)聯(lián)關(guān)系，但是因為漏洞信息的敏感性，該數(shù)據(jù)集僅通過郵件提供。

2) 在APP 漏洞特征表示上，本文提出一種包含語義信息的特征抽象方法——CIS。該方法可以保留程序的執(zhí)行流程的結(jié)構(gòu)信息，從APP 中提取只與漏洞相關(guān)的代碼信息，并且將特征代碼中的自定義函數(shù)名與變量名進行統(tǒng)一格式化處理，既保留語義邏輯性也具有可讀性。針對APP 沒有明確的唯一主函數(shù)入口的情況，本文給出了9 個入口點，可以更全面地構(gòu)建APP 內(nèi)部代碼邏輯與數(shù)據(jù)關(guān)系。

3) 基于CIS 方法，本文選取Bi-LSTM 算法構(gòu)建了一個針對 APP 漏洞的深度學(xué)習(xí)檢測模型VulDGArcher，針對本文分析的2 種漏洞，其識別準(zhǔn)確率達到了96%。

2 代碼語義特征化

漏洞代碼特征化應(yīng)最大化保留語意信息和影響漏洞形成的因素。本文提出了一種特征抽象方法CIS，利用APP 漏洞點的上下文信息，提取與漏洞點有關(guān)的語義信息，減少無關(guān)變量和函數(shù)信息。

2.1 漏洞語義特征

APP 源碼中包含很多邏輯處理流程，一個功能的實現(xiàn)需要用到其他的變量或者方法。在對某一種漏洞分析時，本文只關(guān)注和這個漏洞觸發(fā)點相關(guān)的變量和方法，其他代碼在這種場景下都是噪聲。

以IIS 為例，代碼1 是一個APP（MD5 是51da27661a8eff2f0cb37b7756e576b3）中使用隱式Intent 的方法實現(xiàn)發(fā)送郵件的功能函數(shù)，第11)行～第15)行實現(xiàn)了一個隱式Intent 對象，該對象中加入了過濾條件Intent.ACTION_SENDTO，同時該對象中包含了全部郵件內(nèi)容。該APP 并沒有設(shè)定發(fā)送郵件的APP，也沒有強制設(shè)置用戶選擇所有可以響應(yīng)該Intent 的應(yīng)用程序，這種現(xiàn)象就會導(dǎo)致該APP 存在IIS。

代碼1IIS 的示例代碼

綜上，IIS 風(fēng)險與Intent 的使用有關(guān)。所以從APP 的源代碼角度分析，該風(fēng)險應(yīng)主要關(guān)注Intent的對象及其用到的方法。如代碼1 所示，影響該漏洞的代碼只有第12)行～第18)行，其他是噪聲數(shù)據(jù)。

代碼2 是某個Android 系統(tǒng)中“設(shè)置”APP（CVE-2014-8609）使用PendingIntent 方法實現(xiàn)添加用戶功能。在第3)行中，一個PendingIntent 對象mPendingIntent 被創(chuàng)建，并帶有一個空的Intent 對象。因為是系統(tǒng)內(nèi)置APP，所以mPendingIntent 對象具有系統(tǒng)權(quán)限。當(dāng)惡意 APP 注冊接收該mPendingIntent 對象時，因為mPendingIntent 注冊的Intent 是空的，所以惡意APP 可以修改Intent 對象中的Action 和Extra data 屬性，再以具有系統(tǒng)權(quán)限的mPendingIntent 對象發(fā)送出去，以此達到權(quán)限繞過目的。

代碼2PLP 的示例代碼

綜上分析，PLP 與PendingIntent 和Intent 的使用都有關(guān)，所以代碼2 中影響該漏洞的代碼只有第3)行和第4)行。

特征化方法既要將漏洞相關(guān)代碼表示出來，又要保留代碼之間的語義信息的特征化方法。本文針對這一需求定義了一種特征化代碼的方式CIS，如式(1)所示。它是由全部影響漏洞存在的相關(guān)變量的上下文內(nèi)容Ci組成的，也是由疑似漏洞點的直接或間接相關(guān)的所有代碼組成的調(diào)用序列。

如式(2)所示，Ci是一個有向圖，由一個相關(guān)變量i的前向關(guān)系語句和后向關(guān)聯(lián)的語句組成；vi是第i個變量的關(guān)系圖中的某個調(diào)用語句。當(dāng)同一個變量的數(shù)據(jù)從vik傳遞到viw時，這2 個點之間存在邊eikw。

代碼3 是代碼1 進行CIS 處理后的結(jié)果。第1)行表示聲明了一個Intent 對象且該對象的臨時編號是10；第2)行表示對編號為10 的這個Intent 對象進行了初始化操作且初始化傳遞的參數(shù)是String 類型；第3)行～第7)行依次表示編號為10 的這個Intent 對象進行設(shè)置屬性等操作；第8)行表示Intent對象被發(fā)送。

代碼3IIS 的CIS 示例代碼

以上結(jié)果顯示CIS 既包含Intent 相關(guān)的代碼也保證了語句的原本調(diào)用序列。CIS 在包含疑似漏洞點的所有相關(guān)對象和語句的同時，去掉了與它無關(guān)的代碼信息，順序性保留了邏輯上的語義信息。

2.2 構(gòu)建CIS

從一個APP 文件構(gòu)建關(guān)于一個疑似漏洞點的CIS 的流程如圖1 所示。

1) 反編譯

本文對APP 進行漏洞分析的目標(biāo)是APK文件，包含編譯好的可執(zhí)行文件。為了對源代碼進行漏洞分析，本文基于WALA 實現(xiàn)了對APK 文件的反編譯操作，從而獲取到了APP 的Smali 形式的代碼。

2) 構(gòu)建控制流圖

本文定義了如表1 所示的入口點，并以此為基礎(chǔ)為安卓APP 構(gòu)建必要的控制流圖（CFG,control flow graph），如式(3)所示。

表1 定義的入口點

其中，N是全部節(jié)點集；程序中的每個語句都對應(yīng)圖中的一個節(jié)點nk，當(dāng)nk存在調(diào)用nw的關(guān)系時，兩者之前存在一條從nk指向nw的邊ekw；nentry 和nexit 分別為程序的入口和出口節(jié)點。經(jīng)過分析安卓的4 種組件的啟動入口點和中間狀態(tài)的轉(zhuǎn)換關(guān)系以及安卓的UI 反射入口等特性。

3) 構(gòu)建程序依賴圖

程序依賴圖（PDG,program dependency graph）是程序的一種圖形表示，是帶有標(biāo)記的有向多重圖，如式(4)所示。構(gòu)建方法是以程序的CFG 為基礎(chǔ)，去掉CFG 的控制流邊，加入數(shù)據(jù)和控制流邊。因此PDG 包括了數(shù)據(jù)依賴圖和程序依賴圖，數(shù)據(jù)依賴圖定義了數(shù)據(jù)之間的約束關(guān)系，控制依賴圖定義了語句執(zhí)行情況的約束關(guān)系。PDG 全部節(jié)點集合為V'，其中任意一個節(jié)點sk表示語句或控制謂詞表達式，邊E'表示程序組成部分之間的依賴關(guān)系，包括控制依賴和數(shù)據(jù)依賴。如果PDG 中的語句sk和sw可以通過控制流或者數(shù)據(jù)流來彼此關(guān)聯(lián)，則兩點之前存在一條邊。因為PDG 既包含程序中語句之間的數(shù)據(jù)依賴關(guān)系，又包含控制依賴關(guān)系，所以可減少漏洞信息搜索空間。

4) 構(gòu)建CIS

本文按照算法1 所描述的過程，選取一個疑似存在漏洞的風(fēng)險點。如圖1 所示，IIS 漏洞的疑似漏洞點是Intent 。本文首先提取疑似漏洞點的前向切片和后向切片；然后選取其中的配置方法，如put Extra 等；最后對這類方法中的對象再次進行前向切片和后向切片提取。所有提取的中間切片結(jié)果使用Construct Tree 存儲在樹結(jié)構(gòu)中。因為本文最終得到的代碼抽象結(jié)果要保持相對的邏輯順序性，本文將使用Search Tree 方法前序遍歷讀取樹結(jié)構(gòu)中的結(jié)果，并將所有結(jié)果匯總到一起形成這個疑似漏洞點的代碼抽象形式CIS'。

算法1基于疑似漏洞點構(gòu)建代碼抽象表示CIS'

輸入存儲切片代碼tree Node，一個疑似漏洞點inp，APP 的程序依賴圖PDG

輸出疑似漏洞點的代碼抽象表達式CIS'

CIS'包含自定義的變量名和API 等噪聲數(shù)據(jù)，因此本節(jié)進一步優(yōu)化數(shù)據(jù)特征以便模型更好地識別漏洞，優(yōu)化過程如算法2 所示。

算法2對CIS'進行數(shù)據(jù)歸一化處理

輸入初步提取的所有疑似漏洞點的抽象代碼特征CIS's

輸出最終的代碼特征CIS

①從APP 提出來的CIS'中包含了方法的異常處理信息，這些信息不會影響漏洞是否存在，但是會降低模型檢測漏洞的準(zhǔn)確率。經(jīng)分析，這部分信息是在符號@后的字符。所以先獲取@在CIS'中的位置Index，移除掉Index 后面的表示異常處理的字符串，得到新的CIS'。

②CIS'包含開發(fā)者自定義的變量信息。因為每個開發(fā)者自定義的變量命名不同，所以自定義變量就是噪聲數(shù)據(jù)，會影響模型對漏洞的識別。本文將自定義方法進行統(tǒng)一的重新定義，計算出CIS'中每個自定義的變量vari，然后按照先后順序i對其進行替換變成統(tǒng)一的命名VERi，這樣CIS'中不同的自定義的變量只是編號不同，其他的都是用統(tǒng)一的VER 字符串表示。利用同樣的方法，依次將自定義的方法名變成FUNi，自定義的類名變成CLASSi。不同的類、方法和變量將按照后邊的序號i進行區(qū)分，相同的類、方法和變量在不同位置命名保持一致。

③代碼特征化的結(jié)果中，系統(tǒng)API 的方法都是展示的完整的全限定位名，如Java/lang/String，也就是包含了類所在的包名。因為API 的類名就可以表現(xiàn)出該API 的行為和意義，包名對于漏洞的識別是無意義的變量信息。盡管存在少量的API 具有同樣的類名，但是存在于不同的包名下，這些少量的API 主要是監(jiān)聽類，并沒有實際的行為意義，即不會影響漏洞的存在。所以計算出CIS'中的每個以上類別的系統(tǒng)API（apii），去掉所有的包名只保留類名。例如，Java/lang/String 簡化后為String。

④對于上述幾步的處理優(yōu)化后，本文對同對象的調(diào)用方法進行再一次的組合，最大限度地還原APP 的原本語句表達形式。最后得到含有最小噪聲數(shù)據(jù)的代碼特征值即CIS。

3 基于語義代碼片段的漏洞識別模型

本文基于CIS 采用Bi-LSTM 算法構(gòu)建了一個保留語意信息的APP 漏洞檢測模型VulDG Archer，圖2 為其訓(xùn)練過程。采用深度學(xué)習(xí)模型可以解決人工提取漏洞規(guī)則的漏報問題，并能克服依賴專家經(jīng)驗對新漏洞識別的局限性。

1) 構(gòu)建CIS

構(gòu)建CIS 的過程如算法3 所示。

算法3構(gòu)建APP 的CIS

輸入待分析的安卓應(yīng)用APP，所有的入口函數(shù)EPs，疑似漏洞點集合inps

輸出漏洞特征CISs

21) end for

22) 按照上述過程構(gòu)建PDG

23) 按照算法1 構(gòu)建一個疑似漏洞點inp 的CISs

①本文基于WALA 對APP 逆向處理得到smali 格式的代碼?；谒械娜肟邳cEBs 處理得到APP 的代碼塊集合EntryBs。

② 從集合EntryBs 中取出任意2 個不同的代碼塊ebi和ebj，如果從ebi的最后一個語句到ebj的前項存在條件分支或無條件分支，或者如果ebj以程序順序緊隨ebi且ebi不以無條件分支結(jié)束，則在ebi的基本塊中添加一個有向邊eij指向ebj。依次對所有的代碼塊進行同樣的操作，就構(gòu)建了APP 的CFG。

③CFG 只能呈現(xiàn)APP 的不同塊之間的調(diào)用關(guān)系，為了分析具體APP 內(nèi)部的數(shù)據(jù)傳遞過程，還要進一步得到APP 的數(shù)據(jù)傳遞情況?；贑FG 計算所有偏序PO 和所有的控制依賴關(guān)系CD。針對CD中的每一個偏序關(guān)系bbi→bbj，對于bbj中的每一個語句表達式vjk，都存在一條從bbi指向vjk的邊eijk。這樣就會得到語句之間的控制關(guān)系。對于任意2 個存在數(shù)據(jù)依賴關(guān)系的語句u與v，如果其所在的偏序關(guān)系為bb(u)

④ 基于PDG，本文使用算法1 對所有的疑似漏洞點構(gòu)建對應(yīng)的代碼特征CIS。這樣得到的是關(guān)于每一個疑似漏洞點的包含語義的代碼特征，其中還記錄了這個疑似漏洞點所在的類名和方法名。

2) 數(shù)據(jù)集標(biāo)注

CIS 的抽象特征沒有包含它是否存在漏洞的標(biāo)簽，這一步將提取的代碼特征進行漏洞打標(biāo)簽。

①本文將APP 文件中的疑似漏洞點所在的函數(shù)使用MobSF（mobile security framework）進行漏洞識別，對于識別出來的漏洞信息，本文再一次進行人工校驗，最終整理出每個APP 的漏洞信息。漏洞信息包含包名（pj）、類名（cj）、方法名（mj）和漏洞類型（vjq），如式(5)所示。

② CIS 中的一個疑似漏洞點ipj如式(6)所示，其中表示包名，表示類名，表示方法名。

3) 訓(xùn)練模型

經(jīng)過上述階段后的代碼特征仍然是字符串的形式，這種格式的特征模型是無法直接識別的，所以也就無法將它當(dāng)作輸入變量。本文通過算法4 將其轉(zhuǎn)換成模型可接收的向量，具體過程如下。

算法4訓(xùn)練模型算法

輸入所有漏洞特征CISs，模型定義的向量長度閾值w

輸出訓(xùn)練好的模型model

①本文使用word2vector 對字符串形式的代碼特征CIS 進行向量化處理，得到模型可使用的詞向量binData。因為訓(xùn)練數(shù)據(jù)需要保證統(tǒng)一的長度，所以應(yīng)對binData 進行歸一化處理。如果bin Data 長度小于規(guī)定的閾值w（本文w=200），在bin Data 后進行補0 操作；如果bin Data 長度大于閾值w，從后邊進行截斷操作。最后統(tǒng)一存在訓(xùn)練數(shù)據(jù)集train Data 中。

② APP 的漏洞代碼特征是基于數(shù)據(jù)流和控制流構(gòu)建的，其中包含了疑似漏洞點的上下文相關(guān)調(diào)用邏輯代碼。深度學(xué)習(xí)算法應(yīng)能夠?qū)W習(xí)到漏洞代碼塊的調(diào)用邏輯。其次，APP 是否存在漏洞受疑似漏洞點的前向代碼和后向代碼的影響。因此選擇的深度學(xué)習(xí)網(wǎng)絡(luò)應(yīng)當(dāng)滿足如下特點：具有記憶性可以獲取上下文關(guān)系；支持長句子，即長代碼塊；前向語句和后向語句的影響都能覆蓋。技術(shù)成熟的深度學(xué)習(xí)網(wǎng)絡(luò)中，Bi-LSTM 網(wǎng)絡(luò)同時支持以上3 個特性，可以作為APP 漏洞檢測的深度學(xué)習(xí)網(wǎng)絡(luò)。

由于漏洞代碼特征CIS 都是較長的語句，為了學(xué)習(xí)長句子的語義信息，本文選取的Bi-LSTM 模型中加入注意力機制，訓(xùn)練后得到漏洞識別模型。

4 實驗和結(jié)果分析

本文用實驗回答以下3 個研究問題。

RQ1：CIS 能否識別出APP 的多種漏洞？

RQ2：與現(xiàn)有的APP 漏洞檢測方法相比，VulDGArcher 的效果如何？

RQ3：VulDGArcher 的效率如何，是否具有實用性？

4.1 數(shù)據(jù)集和實驗環(huán)境

因為相關(guān)的研究成果還沒有開放出可用的安卓漏洞樣本數(shù)據(jù)集，所以本文從Google Play 獲取了5 000 個APP 樣本，先用安卓漏洞檢測工具MobSF 識別出APP 的疑似漏洞點和初步的漏洞標(biāo)記，再對檢測后的APP 進行人工的源碼分析，分析應(yīng)用程序中的疑似漏洞點上下文的數(shù)據(jù)流，標(biāo)定出的所有APP 中存在IIS 或PLP 的樣本數(shù)量如表2 所示。表2 中的安全是指APP 使用對應(yīng)的API 操作且安全的樣本。因為存在同一個APP 同時存在IIS 和PLP 這2 種漏洞，所以在數(shù)據(jù)統(tǒng)計時沒有去重。

表2 數(shù)據(jù)集中存在不同的漏洞APP 數(shù)量

對APP 進行CIS 代碼特征化處理后，現(xiàn)有APP樣本中，屬于某種漏洞的CIS 特征條數(shù)如表3 所示。為了對比實驗，本文統(tǒng)計了現(xiàn)有APP 中存在漏洞的原始代碼文件（.class）的數(shù)量，如表4 所示。因為同樣一個源代碼文件（.class）可能存在多個同類別的漏洞且表4 中記錄的是原始代碼的文件數(shù)（.class文件數(shù)），所以各種漏洞的數(shù)量和表3 所展示的特征化后的結(jié)果不一樣。

表3 數(shù)據(jù)集中存在不同的漏洞CIS 數(shù)量

表4 數(shù)據(jù)集中疑似漏洞點原始代碼段數(shù)量

4.2 評價指標(biāo)

實驗環(huán)境為一臺64 GB RAM，3 TB SSD，Intel Intel Xeon CPU E5-2640 v2 2.00 GHz 服務(wù)器。

本文的實驗是檢測多個漏洞，所以是一個多分類問題。本文分別計算每個漏洞的對應(yīng)的指標(biāo)值，然后將全部類別的對應(yīng)指標(biāo)值進行取平均值。以第i類漏洞的檢測為例，本文的評價指標(biāo)如下。

真正類TPi：樣本的真實類別是i漏洞，模型預(yù)測的結(jié)果也是i漏洞。

假負類FNi：樣本的真實類別是i漏洞，模型預(yù)測的結(jié)果不是i漏洞。

假正類FPi：樣本的真實類別不是i漏洞，模型預(yù)測的結(jié)果是i漏洞。

真負類TNi：樣本的真實類別不是i漏洞，模型預(yù)測的結(jié)果不是i漏洞。

誤報率（FPR,false positive rate）：不是i漏洞的樣本被預(yù)測成i漏洞的占比。

召回率（TPR,true positive rate）：真實存在漏洞的樣本判定為存在漏洞。

精確度（P,precision）：i漏洞的樣本被預(yù)測為漏洞的比例。

F-Measure (F1)：精確度和召回率加權(quán)調(diào)和的平均。

精度（Acc,accuracy）：判為漏洞的樣本數(shù)量占據(jù)樣本總數(shù)量的比例。

4.3 實驗分析

1) 回答RQ1：CIS 特征在漏洞檢測上的有效性

本文想驗證基于CIS 特征的深度學(xué)習(xí)檢測模型是否能夠正確地檢測出漏洞，并且是否可以實現(xiàn)多種漏洞的檢測。本文選取了2 種安卓漏洞IIS 與PLP。在算法的選擇上，由于CIS 的特征包含了interest point 的上下文，因此選取了具有后向反饋的Bi-LSTM 作為模型的算法。

如表5 所示，本文按照一定的比例將每種漏洞的數(shù)據(jù)拆分成了訓(xùn)練集、驗證集和測試集。雖然其中IIS 的數(shù)量大于PLP 的數(shù)據(jù)量，但是在針對漏洞的CIS 特征中包含了interest point 的上下文語義信息，這樣不同的漏洞之間的實現(xiàn)語句的明顯不同，所以CIS 會有明顯的差別。這樣不同漏洞之間的數(shù)據(jù)量的差距也不會影響模型識別的結(jié)果出現(xiàn)樣本不均衡的假陽性問題。從圖3 中可以看出，CIS 特征在訓(xùn)練過程中隨著訓(xùn)練迭代次數(shù)的增加，訓(xùn)練集和驗證集的auc 參數(shù)都在逐步增加并逐漸達到一定的平穩(wěn)狀態(tài)，采用時訓(xùn)練集和驗證集的loss 參數(shù)都在逐步的下降并達到平穩(wěn)態(tài)。這說明基于CIS 的特征是可以實現(xiàn)針對安卓多種漏洞檢測。

表5 用于模型訓(xùn)練和驗證的數(shù)據(jù)集的分布

為了進一步驗證基于CIS 特征的模型的其他指標(biāo)項隨著訓(xùn)練樣本數(shù)量的不同的變化情況，本文采用不同的訓(xùn)練集進行模型訓(xùn)練，訓(xùn)練后的模型都采用同樣的測試數(shù)據(jù)集進行測評模型的各種指標(biāo)項。在保證測試集不變的情況下，本文將表5 中的訓(xùn)練集分別拆分成8 組，詳細如表6 所示。本文針對每組訓(xùn)練集都采用同樣的模型和參數(shù)配置，圖4顯示的是不同的訓(xùn)練集下的CIS 的特征的模型的漏洞檢測指標(biāo)變化。從圖4 可以看出，隨著訓(xùn)練樣本集的擴增，模型的精確度、召回率、F-Measure和精度都在逐步增長并達到最好的98%，誤報率逐步下降到2%。

表6 用于模型訓(xùn)練和驗證的數(shù)據(jù)集的分布

基于CIS 特征的深度學(xué)習(xí)檢測模型VulDGArcher可以正確地檢測出APP 中的多種漏洞。Bi-LSTM 算法可以捕獲長句子的雙向語義信息，基于該算法的漏洞檢測模型精確度可以達到98%，所以Bi-LSTM 算法更適用于VulDGArcher 的檢測任務(wù)。

2) 回答RQ2：VulDGArcher 與不同的漏洞檢測方法進行對比漏洞檢測效果

為了驗證VulDGArcher 中CIS 的漏洞特征方法的有效性，本文采用不同的模型算法和不同的特征提取方法進行交叉實驗。本文在模型算法方面選取Bi-LSTM 和CNN；在APP 的漏洞特征表示方法方面選取APP 的Java 源代碼文本特征[24]、APP 的AST 特征[22]和CIS。APP 的Java 源代碼文本特征（CB,code block），就是對待檢測的目標(biāo)APP 進行逆向處理，獲取其源代碼信息，去掉這些源代碼信息中無意義的標(biāo)記符號，最后轉(zhuǎn)換成深度學(xué)習(xí)模型可識別的向量。代碼4 是一個APP 的IIS 漏洞原始代碼樣例。APP 的AST 特征就是將APP逆向獲取出來的源代碼信息進行AST 表示，去掉其中的特殊標(biāo)記符，然后將其轉(zhuǎn)換成深度學(xué)習(xí)可識別的向量信息。圖5 是代碼4 所示的漏洞方法的AST 表示，由于篇幅限制，圖5 中只展示了與Intent 相關(guān)的AST。

代碼4IIS 的示例代碼

表7 是不同模型在相同測試集上的結(jié)果。從表7 可以看出，基于原始的代碼做漏洞檢測模型的誤報比較高，達到51%的原因包括：1) 原始的代碼中包含了大量和漏洞形成無關(guān)的噪聲數(shù)據(jù)；2) 原始代碼中的自定義方法在每個APP 中都是不一樣的。相比較，VulDGArcher 在代碼特征化的過程中提取的是疑似漏洞點的語義上下文信息，去除了所有無關(guān)的代碼，并且對于APP 自定義的方法名和類名也進行了歸一化處理，這樣才能使VulDGArcher 的誤報率和漏報率很低。圖6 可以更加直觀地反映VulDGArcher 與基于其他2 種特征化方法的模型的效果。由圖6 可知，VulDGArcher的APP 漏洞檢測效果更好。CNN 的漏洞檢測模型雖然也可以識別出漏洞，但是模型測試的各個指標(biāo)都低于Bi-LSTM 算法。圖7 是同樣的數(shù)據(jù)下2 種算法的ROC 曲線。從圖7 可以直觀地看出，Bi-LSTM 算法更適合CIS 特征。

表7 不同類型的代碼特征的數(shù)據(jù)進行模型訓(xùn)練的效果

為了驗證上述觀點，本文提取一個存在IIS 風(fēng)險的APP，在實驗驗證過程中，VulDGArcher 可以識別出它存在該風(fēng)險，但是基于原始代碼文件的模型無法正確判斷該APP 的這個風(fēng)險。代碼5 是代碼4經(jīng)過VulDGArcher將原始代碼進行語義特征處理化后的結(jié)果。從代碼5 中可以看出，特征化后的代碼只包含和IIS 風(fēng)險相關(guān)的語法信息。

代碼5VulDGArcher 對IIS 提取特征的結(jié)果

相較于原始代碼，代碼5 去除了很多無用的噪聲數(shù)據(jù)。這也反映了VulDGArcher 在漏洞識別上具有很好的效果，主要取決于基于語義的代碼特征化處理。

通過上述結(jié)果可以看出，基于CIS 漏洞特征化的深度學(xué)習(xí)檢測模型在APP 漏洞檢測上效果更優(yōu)。因為CIS 相較其他2 種方法提取的漏洞特征去掉了無用的代碼信息，且包含的信息是疑似漏洞點的上下文相關(guān)的代碼信息。

3) 回答RQ3：VulDGArcher 與不同的漏洞檢測方法驗證實用性

本文通過實驗從檢測漏洞的效率角度評估VulDGArcher 是否具有實用性。本實驗增加2 種開源的基于規(guī)則的安卓漏洞檢測器：AndroBugs 和Marvin-static-Analyzer。它們在Github 上具有很多的forks and stars，都支持IIS 脆弱性檢測，但是不支持PLP 漏洞檢測。本文將基于PIAnalyzer[4]分析出的 PLP 檢測規(guī)則配置在 AndroBugs 和Marvin-static-Analyzer 工具中，使工具支持對2 個漏洞的檢測。本文從測試的數(shù)據(jù)集中隨機地選取了100 個APP，然后分別采用Andro Bugs、Marvinstatic-Analyzer、基于AST 的深度學(xué)習(xí)漏洞檢測模型和VulDGArcher 進行漏洞檢測。如表8 所示，針對同樣的漏洞，基于學(xué)習(xí)的漏洞檢測方法的準(zhǔn)確率高于基于規(guī)則的檢測方法。因為這2 個漏洞的檢測方法需要考慮到漏洞點的上下文環(huán)境中涉及的多種對象屬性配置，而基于規(guī)則的檢測方法無法覆蓋上述條件，所以檢測準(zhǔn)確率相對較低。

表8 不同檢測方法的準(zhǔn)確率

圖8 是不同工具的耗時情況。VulDGArcher 的耗時主要是代碼特征化處理，模型的漏洞識別部分接近毫秒級。因為VulDGArcher 需要構(gòu)建APP 的PDG，然后對提取出來的特征進行向量化處理，所以這部分處理是耗時的過程。雖然如此，VulDGArcher 平均在5 s 以內(nèi)就可以完成對一個APP 的漏洞檢測。圖9 和圖10 分別是各漏洞檢測工具的CPU 消耗比例和內(nèi)存消耗比例。從圖9 和圖10可以看出，VulDGArcher 的內(nèi)存消耗最多為22%，遠低于Marvin-static-Analyzer 的48%；CPU 資源使用最多為30%，并且隨著運行逐漸保持低于10%。

同種運行環(huán)境下，本文將VulDGArcher 與其他3 種漏洞檢測引擎進行比較，從準(zhǔn)確率、耗時和資源消耗等方面衡量發(fā)現(xiàn)，VulDGArcher 的代碼特征化是相對耗時的，但是并不是極其耗費資源的。所以本文建議通過并發(fā)運行平衡掉耗時的缺點。

5 結(jié)束語

本文針對現(xiàn)有基于學(xué)習(xí)的APP 漏洞檢測方法的特征表示結(jié)果缺乏語義信息而影響漏洞檢測準(zhǔn)確率的問題，提出了一種包含上下文語義信息的特征抽象方法CIS，并對由APP 的API 誤用導(dǎo)致的漏洞提出了一種上下文感知的檢測方法。CIS 可以從APP 中提取只和漏洞相關(guān)的變量信息，并且可以消除開發(fā)者自定義代碼的類名、方法名和變量名對模型檢測效果的影響。本文基于CIS 采用Bi-LSTM 和注意力機制構(gòu)建了一個 APP 漏洞檢測模型VulDGArcher。與基于AST 和原始代碼為特征化的檢測方法相比，VulDGArcher 可以有效識別APP 不正確使用安卓平臺的API 所導(dǎo)致的漏洞。此外，本文構(gòu)建了一個包含41 812 條特征代碼段的數(shù)據(jù)集。