上下文感知的安卓應用程序漏洞檢測研究

秦佳偉，張華，嚴寒冰，何能強，涂騰飛

（1.北京郵電大學網絡與交換技術國家重點實驗室，北京 100876；2.國家計算機網絡應急技術處理協調中心，北京 100029）

1 引言

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

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

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

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

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

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

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

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

2 代碼語義特征化

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

2.1 漏洞語義特征

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

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

代碼1IIS 的示例代碼

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

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

代碼2PLP 的示例代碼

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

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

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

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

代碼3IIS 的CIS 示例代碼

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

2.2 構建CIS

從一個APP 文件構建關于一個疑似漏洞點的CIS 的流程如圖1 所示。

1) 反編譯

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

2) 構建控制流圖

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

表1 定義的入口點

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

3) 構建程序依賴圖

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

4) 構建CIS

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

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

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

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

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

算法2對CIS'進行數據歸一化處理

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

輸出最終的代碼特征CIS

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

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

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

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

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

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

1) 構建CIS

構建CIS 的過程如算法3 所示。

算法3構建APP 的CIS

輸入待分析的安卓應用APP，所有的入口函數EPs，疑似漏洞點集合inps

輸出漏洞特征CISs

21) end for

22) 按照上述過程構建PDG

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

①本文基于WALA 對APP 逆向處理得到smali 格式的代碼。基于所有的入口點EBs 處理得到APP 的代碼塊集合EntryBs。

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

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

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

2) 數據集標注

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

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

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

3) 訓練模型

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

算法4訓練模型算法

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

輸出訓練好的模型model

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

② APP 的漏洞代碼特征是基于數據流和控制流構建的，其中包含了疑似漏洞點的上下文相關調用邏輯代碼。深度學習算法應能夠學習到漏洞代碼塊的調用邏輯。其次，APP 是否存在漏洞受疑似漏洞點的前向代碼和后向代碼的影響。因此選擇的深度學習網絡應當滿足如下特點：具有記憶性可以獲取上下文關系；支持長句子，即長代碼塊；前向語句和后向語句的影響都能覆蓋。技術成熟的深度學習網絡中，Bi-LSTM 網絡同時支持以上3 個特性，可以作為APP 漏洞檢測的深度學習網絡。

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

4 實驗和結果分析

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

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

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

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

4.1 數據集和實驗環境

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

表2 數據集中存在不同的漏洞APP 數量

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

表3 數據集中存在不同的漏洞CIS 數量

表4 數據集中疑似漏洞點原始代碼段數量

4.2 評價指標

實驗環境為一臺64 GB RAM，3 TB SSD，Intel Intel Xeon CPU E5-2640 v2 2.00 GHz 服務器。

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

真正類TPi：樣本的真實類別是i漏洞，模型預測的結果也是i漏洞。

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

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

真負類TNi：樣本的真實類別不是i漏洞，模型預測的結果不是i漏洞。

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

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

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

F-Measure (F1)：精確度和召回率加權調和的平均。

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

4.3 實驗分析

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

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

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

表5 用于模型訓練和驗證的數據集的分布

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

表6 用于模型訓練和驗證的數據集的分布

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

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

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

代碼4IIS 的示例代碼

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

表7 不同類型的代碼特征的數據進行模型訓練的效果

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

代碼5VulDGArcher 對IIS 提取特征的結果

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

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

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

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

表8 不同檢測方法的準確率

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

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

5 結束語

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