組件測試方法和裝置的制造方法
【技術(shù)領(lǐng)域】
[0001] 本發(fā)明涉及測試領(lǐng)域，具體而言，涉及一種組件測試方法和裝置。
【背景技術(shù)】
[0002] 隨著移動終端平臺的興起，人們的生活越來越依賴移動智能設(shè)備，移動平臺涌現(xiàn) 出成千上萬各式各樣的應(yīng)用程序（即，app)。由于系統(tǒng)的開放性，Amlroidapp的安全性受 到越來越多的關(guān)注和研究。組件是Amlroidapp的基礎(chǔ)，用于構(gòu)建app的各類功能和服務(wù)， 其中活動組件（即，Activity組件）用于可視化界面展現(xiàn)，廣播接收器組件（即，Broadcast Receiver組件）用于接收并響應(yīng)廣播，服務(wù)組件（即，Service組件）用于實現(xiàn)后臺服務(wù)， 內(nèi)容提供者組件（即，ContentProvider組件）用于數(shù)據(jù)訪問，可在a卵之間共享數(shù)據(jù)。
[0003]An化oid系統(tǒng)提供了一套獨有的組件間通信機制，用于a卵組件間的調(diào)用和交互。 在同一個app之中或不同app之間，Activity組件、化oadcastReceiver組件和Service 組件使用Intent相互調(diào)用，使用系統(tǒng)提供的接口ContentResolver訪問ContentProvider 組件，共同實現(xiàn)app的功能。
[0004] 組件間的通信由于An化oidManifest文檔配置不規(guī)范或代碼實現(xiàn)不嚴謹存在兩 類安全問題；Intent劫持和組件暴露。Intent劫持指組件通過Intent調(diào)用其他組件時，由 于沒有顯式地指定接收組件導致Intent可能逃出當前app而被其他app惡意劫持，如圖1 所示，組件A發(fā)送一個Intent消息，在多個目標組件都可W響應(yīng)的情況下，系統(tǒng)W隨機順序 或讓用戶選擇的方式?jīng)Q定哪個組件響應(yīng)，惡意app的組件B可能先被響應(yīng)，從而導致釣魚、 信息泄漏等安全風險；組件暴露指組件訪問權(quán)限完全對外開放，第H方a卵不需要任何特 殊權(quán)限就可隨時調(diào)用暴露組件，如圖1中的組件C若是暴露的，惡意app的組件D可隨時調(diào) 用組件C執(zhí)行相關(guān)邏輯，從而導致拒絕服務(wù)、數(shù)據(jù)泄漏或被污染、能力或權(quán)限泄漏等安全風 險。目標組件（被調(diào)用者）不可信導致Intent劫持安全風險，源組件（調(diào)用者）不可信導 致組件暴露安全風險，圖2為組件暴露導致a卵接收到特定消息即崩潰的示意圖，其中，*** 表示app的名稱，在圖2中示意性W字符代替。
[0005] 針對組件權(quán)限安全問題，現(xiàn)有技術(shù)中已提出若干技術(shù)方案，有的采用靜態(tài)分析 An化oidManifest.xml文檔和反編譯的smali代碼完成安全分析，其中，smali代碼為APK 反編譯生成的文件格式，是Amlroid系統(tǒng)的虛擬機指令語言；有的則通過生成測試a卵模擬 發(fā)送特定Intent消息進行動態(tài)安全測試。目前業(yè)界已有幾款組件安全分析工具，如靜態(tài)分 析工具Co血roid、C肥X和Woodpecker等，動態(tài)測試工具IntentF'uzzer、Drozer等。
[0006]Co血roid靜態(tài)檢查APK的An化oidManifest.xml文檔中組件屬性和smali代碼 中發(fā)送Intent的代碼點，判定是否存在隱式發(fā)送的Intent、隱式啟動的Activity組件和 Service組件及用于接收系統(tǒng)廣播的化oadcastReceiver組件；CHEX靜態(tài)分析app的所有 可用入口，采用數(shù)據(jù)流分析并獲取可用的路徑，判定是否存在組件劫持問題，如權(quán)限泄漏、 Intent劫持和私有數(shù)據(jù)泄漏等安全風險；Woo化ecker靜態(tài)檢測a卵暴露的組件，模擬數(shù)據(jù) 流分析，識別可能的執(zhí)行路徑并確定可用路徑，判定app是否存在使用敏感權(quán)限的行為。
[0007] Intent化zzer是一款動態(tài)組件權(quán)限安全測試工具，Wapp形式提供可視化測試界 面，通過界面點擊選擇a卵的某一組件，自動發(fā)送空Intent消息，并觀察被測a卵是否存在 崩潰或其他異?，F(xiàn)象。
[0008]Drozer(原Mer州ry)是一款開源的An化oid動態(tài)安全評估框架，由運行在 PC任ersonalComputer,簡稱PC)上的客戶端和運行在An化oid設(shè)備上的服務(wù)端代理兩個模 塊組成，通過客戶端命令行發(fā)送不同指令進行安全測試。Drozer首先進行攻擊面分析，靜態(tài) 檢查app中的暴露組件，然后采用命令行指令依次測試每個暴露的組件W確認是否出現(xiàn)應(yīng) 用崩潰、數(shù)據(jù)泄漏及能力泄漏等安全風險。
[0009] 現(xiàn)有技術(shù)方案從靜態(tài)和動態(tài)兩個不同側(cè)面進行組件權(quán)限安全分析。靜態(tài)分析方 案通過檢查An化oidManifest.xml文檔和反編譯的代碼，分析app中存在的Intent劫持、 能力泄漏及數(shù)據(jù)泄漏等安全問題，現(xiàn)有靜態(tài)分析方案可自動化完成，但存在大量誤報，且對 組件暴露的檢查不全面；動態(tài)分析工具Intent化zzer和化ozer需額外安裝app到設(shè)備， Intent化zzer未對非暴露組件進行過濾，且需人工選擇點擊，效率和準確性較低；Drozer 測試框架整體較繁重，在PC客戶端遠程控制An化oid設(shè)備，組件暴露的判定規(guī)則仍有遺漏， 且對每個暴露組件需人工命令行指令逐一測試。
[0010] 現(xiàn)有技術(shù)主要采用靜態(tài)分析配置文檔和反編譯的源碼判定app中的暴露組件，手 工選擇或命令行指令對每個暴露組件逐一進行安全測試，并由測試人員觀察是否存在安全 風險，存在W下缺點：
[0011] (1)對組件暴露的判定規(guī)則不完備；
[0012] (2)靜態(tài)分析方案存在大量誤報，影響安全測試效率；
[0013] (3)動態(tài)測試方案需額外安裝app到An化oid設(shè)備；
[0014] (4)動態(tài)測試方案需大量人工參與，未實現(xiàn)自動化測試和異常識別。
[0015] 針對相關(guān)技術(shù)中無法對應(yīng)用程序進行自動化測試的問題，目前尚未提出有效的解 決方案。

【發(fā)明內(nèi)容】

[0016] 本發(fā)明實施例的主要目的在于提供一種組件測試方法和裝置，W解決現(xiàn)有技術(shù)中 無法對應(yīng)用程序進行自動化測試的問題。
[0017]為了實現(xiàn)上述目的，根據(jù)本發(fā)明實施例的一個方面，提供了 一種組件測試方法。
[0018] 根據(jù)本發(fā)明實施例的組件測試方法包括；獲取待測試應(yīng)用程序中的目標組件的組 件類型，其中，所述目標組件為允許被第H方應(yīng)用程序訪問的組件；獲取與所述組件類型對 應(yīng)的測試指令；發(fā)送所述測試指令至安裝有所述待測試應(yīng)用程序的目標設(shè)備；獲取所述目 標設(shè)備對所述測試指令的響應(yīng)結(jié)果；W及根據(jù)所述響應(yīng)結(jié)果確定所述目標組件的狀態(tài)。
[0019] 為了實現(xiàn)上述目的，根據(jù)本發(fā)明實施例的另一方面，提供了 一種組件測試裝置。
[0020] 根據(jù)本發(fā)明實施例的組件測試裝置包括；第一獲取單元，用于獲取待測試應(yīng)用程 序中的目標組件的組件類型，其中，所述目標組件為允許被第H方應(yīng)用程序訪問的組件；第 二獲取單元，用于獲取與所述組件類型對應(yīng)的測試指令；發(fā)送單元，用于發(fā)送所述測試指令 至安裝有所述待測試應(yīng)用程序的目標設(shè)備；第H獲取單元，用于獲取所述目標設(shè)備對所述 測試指令的響應(yīng)結(jié)果；W及第一確定單元，用于根據(jù)所述響應(yīng)結(jié)果確定所述目標組件的狀 態(tài)。
[0021] 在本發(fā)明實施例中，采用獲取待測試應(yīng)用程序中的目標組件的組件類型，其中，所 述目標組件為允許被第H方應(yīng)用程序訪問的組件；獲取與所述組件類型對應(yīng)的測試指令； 發(fā)送所述測試指令至安裝有所述待測試應(yīng)用程序的目標設(shè)備；獲取所述目標設(shè)備對所述測 試指令的響應(yīng)結(jié)果；W及根據(jù)所述響應(yīng)結(jié)果確定所述目標組件的狀態(tài)。通過對目標組件的 組件類型進行獲取，進而發(fā)送與目標組件的組件類型相對應(yīng)的測試指令至目標設(shè)備，實現(xiàn) 了根據(jù)不同類型的組件，自動發(fā)送相應(yīng)的測試指令至目標設(shè)備，測試過程不需要人工干預， 解決了現(xiàn)有技術(shù)中無法對應(yīng)用程序進行自動化測試的問題，進而達到了提高測試效率的效 果。
【附圖說明】
[0022] 構(gòu)成本申請的一部分的附圖用來提供對本發(fā)明的進一步理解，本發(fā)明的示意性實 施例及其說明用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的不當限定。在附圖中：
[0023] 圖1是根據(jù)相關(guān)技術(shù)的組件權(quán)限安全的示意圖；
[0024] 圖2是根據(jù)相關(guān)技術(shù)的因組件權(quán)限安全導致app崩潰的示意圖；
[0025] 圖3a和圖3b是執(zhí)行本發(fā)明實施例的組件測試方法的計算機的結(jié)構(gòu)框圖；
[0026] 圖4是根據(jù)本發(fā)明實施例的組件測試方法的流程圖；
[0027] 圖5是根據(jù)本發(fā)明又一實施例的組件測試方法的流程圖；
[0028] 圖6是根據(jù)本發(fā)明又一實施例的組件測試方法的流程圖；
[0029] 圖7是根據(jù)本發(fā)明又一實施例的組件測試方法的流程圖；
[0030] 圖8是根據(jù)本發(fā)明又一實施例的組件測試方法的流程圖；
[0031] 圖9是圖8中步驟S7061的一種【具體實施方式】的流程圖；
[0032] 圖10是圖8中步驟S7061的又一種【具體實施方式】的流程圖；
[0033] 圖11是圖8中步驟S7062的一種【具體實施方式】的流程圖；
[0034] 圖12是根據(jù)本發(fā)明實施例的組件測試裝置的示意圖；
[0035] 圖13是根據(jù)本發(fā)明又一實施例的組件測試裝置的示意圖；
[0036] 圖14是根據(jù)本發(fā)明又一實施例的組件測試裝置的示意圖；
[0037] 圖15是根據(jù)本發(fā)明又一實施例的組件測試裝置的示意圖；
[0038] 圖16是根據(jù)本發(fā)明又一實施例的組件測試裝置的示意圖；
[0039] 圖17是圖16中第H確定子單元的一種具體結(jié)構(gòu)的示意圖；
[0040] 圖18是圖16中第H確定子單元的又一種具體結(jié)構(gòu)的示意圖；W及
[0041] 圖19是圖16中第四確定子單元的一種具體結(jié)構(gòu)的示意圖。
【具體實施方式】
[0042] 為了使本技術(shù)領(lǐng)域的人員更好地理解本發(fā)明方案，下面將結(jié)合本發(fā)明實施例中的 附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是 本發(fā)明一部分的實施例，而不是全部的實施例。基于本發(fā)明中的實施例，本領(lǐng)域普通技術(shù) 人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都應(yīng)當屬于本發(fā)明保護的范 圍。
[0043] 需要說明的是，本發(fā)明的說明書和權(quán)利要求書及上述附圖中的術(shù)語"第一"、"第 二"等是用于區(qū)別類似的對象，而不必用于描述特定的順序或先后次序。應(yīng)該理解送樣使用 的數(shù)據(jù)在適當情況下可W互換，W便送里描述的本發(fā)明的實施例能夠W除了在送里圖示或 描述的郝些W外的順序?qū)嵤?。此外，術(shù)語"包括"和"具有"W及他們的任何變形，意圖在于 覆蓋不排他的包含，例如，包含了一系列步驟或單元的過程、方法、系統(tǒng)、產(chǎn)品或設(shè)備不必限 于清楚地列出的郝些步驟或單元，而是可包括沒有清楚地列出的或?qū)τ谒托┻^程、方法、產(chǎn) 品或設(shè)備固有的其它步驟或單元。
[0044] 對本發(fā)明實施例所涉及的技術(shù)術(shù)語介紹如下：
[0045] Amlroid;是一種基于Linux的自由及開放源代碼的操作系統(tǒng)，主要用于移動設(shè) 備、如智能手機和平板電腦，在智能手機市場占有率達到80%左右；
[0046] App;本文指An化oid平臺的應(yīng)用程序；
[0047] APK;是ApplicationPackageFile的縮寫，指An化oid系統(tǒng)的應(yīng)用程序安裝包的 文件格式；
[0048] 組件；指An化iod系統(tǒng)提供給開發(fā)者實現(xiàn)app的基礎(chǔ)實體，包括活動組件（即， Activity組件）、廣播接收器組件（即，BroadcastReceiver組件）、服務(wù)組件（即，Service 組件）和內(nèi)容提供者組件（即，ContentProvider組件）四種組件；
[0049]