安卓應用敏感行為一致性分析案例目錄TOC\o"1-3"\h\u27000安卓應用敏感行為一致性分析案例 124381.1安卓應用敏感行為檢測 1206831.1.1行為檢測方式 1282561.1.2信息流捕獲 2159741.1.3結果分析 628701.2一致性模型 821881.2.1不一致性案例分析 9219961.2.2符號定義 1029631.2.3模型設計 1119111.2.4量化評估 1368331.3實驗分析 15《個人信息安全防范指引》中，明確提出了“隱私政策”信息與實際不符的情形，所以本章節(jié)基于上一章節(jié)的信息提取以及對于關注的每一隱私信息類型的本體，結合中國《個人信息安全規(guī)范》對隱私相關概念的嚴格定義以及《個人信息安全防范指引》中表述的違法違規(guī)行為，設計自動化的一致性量化評估模型，根據特征自動匹配屬于哪種違法違規(guī)行為，并從應用本身和第三方SDK隱私收集的角度為隱私政策文本描述的真實性進行打分。安卓應用敏感行為檢測第二章中已經說明了應用靜態(tài)和動態(tài)行為分析的優(yōu)缺點，通過動靜相結合的方式可以使應用的隱私信息流檢測達到更好的效果。因此本文計劃使用靜態(tài)污點分析與動態(tài)流量分析相結合的方式對安卓應用的真實行為進行捕捉。行為檢測方式GB/T35273—2020中對“收集”概念進行了詳細描述。如果產品或服務的提供者提供工具供個人信息主體使用，提供者不對個人信息進行訪問的，則不屬于本標準所稱的收集。例如，離線導航軟件在終端獲取個人信息主體位置信息后，如果不回傳至軟件提供者，則不屬于個人信息主體位置信息的收集[40]。由此可以看出，僅僅分析代碼中獲取隱私信息的API不足以被認為是“隱私收集”的行為，必須分析隱私信息的流向。Slavin等在對安卓應用隱私泄露行為進行分析時指出90%以上的隱私信息都是通過網絡的形式傳送出去的。因此本章的應用行為檢測主要分析的是，隱私信息在代碼中獲取，到最終通過網絡泄露出去的過程。因此，對隱私信息的敏感API進行簡單的字符串匹配，以及使用Hook工具對敏感API觸發(fā)行為進行日志打印的方法，是不準確的。第二章的技術介紹中指出，靜態(tài)污點分析可以捕獲到信息從設備上被獲取到離開設備的過程。本文選用FlowDroid+IccTa工具進行靜態(tài)污點分析。網絡流量分析也可以捕獲到所有通過網絡傳送出去的隱私信息。但是靜態(tài)污點分析和動態(tài)流量分析都存在一定的局限性。由于國內市場大量應用是受到加固保護的，代碼被加密導致無法通過靜態(tài)反編譯獲取敏感API信息，靜態(tài)污點分析無法捕獲此行為的數據流。網絡流量分析可以彌補靜態(tài)分析的這一缺陷，無論應用是否進行了代碼保護，都可以捕獲到隱私信息的去向。但是網絡流量分析的行為覆蓋面是不全的，很難觸發(fā)應用中的全部行為；而靜態(tài)污點分析則有能力更全面地覆蓋到應用中的隱私泄露信息流。因此，本文采用動靜結合的方式，即靜態(tài)污點分析和動態(tài)流量分析兩種方式相結合，盡可能全面地捕獲到應用中實際行為的隱私信息流。信息流捕獲本節(jié)的目標是實現信息流的捕獲，然后對靜動態(tài)信息流日志進行分析，提取出應用每一條隱私信息流的信息類型，以及流向應用本身，還是哪一種SDK。映射表的創(chuàng)建為完成這一目標，本文首先參照Flowdroid、Susi、IccTa等污點分析工具提供的SourceAndSinks文件，對每一類隱私信息實體術語對應的敏感API進行總結，完成術語與隱私信息實體的映射表，并按照SourceAndSinks文件的格式保存起來，該映射表在附錄A中。然后本文通過DroidBot和mitmProxy工具對100個應用的運行時的網絡流量進行捕捉[52]，并總結規(guī)律，創(chuàng)建了流量特征與隱私信息實體術語的映射表，該映射表在附錄B中。此外，本研究還需要具備第三方庫的識別能力。于是本文對包含第三章數據集中隱私接收者實體在內的120種最常見國內第三方SDK的詳細信息進行總結，包含第三方SDK的服務端域名信息以及包名信息。詳細信息在附錄C中。靜態(tài)分析根據第二章的介紹分析，本研究選擇使用Flowdroid+IccTa靜態(tài)污點分析工具進行信息流的捕獲。本研究只是為了識別隱私泄露信息的類別，并且包含隱私政策的應用遠大于DroidBench等樣本集的應用，需要花費更長的時間以及導致更大的內存開銷，因此本研究為了保證分析時間較短，降低了對精度的要求。SteveZ等將Flowdroid和IccTA集成到一個jar包當中，可以通過選擇不同的參數來決定不同的精度。使用該工具的命令如圖11所示。圖SEQ圖\*ARABIC11flowdroid+iccta命令-d表示合并dex，-ns表示不對靜態(tài)屬性進行污點追蹤，-ne不追蹤異常數據流，-dt120表示數據流分析時間為120s。本研究采用IccTa提供的SourcesAndSinks.txt的內容根據3.1.2節(jié)確定的25個隱私信息術語進行篩選，保留符合本研究目標的Source函數。4.1.1節(jié)明確研究目標是通過網絡泄露的信息流，因此在Sink函數中只保留與網絡相關的API。共Source函數75個，Sink函數32個。然后將75個Source函數與25個術語通過人工分析創(chuàng)建映射關系，映射關系見附錄A。使用FlowDroid+IccTa工具對安卓應用進行分析之后生成xml文件，內容格式下圖12所示。對圖中格式進行解析，解析出每一個Source和Sink標簽中的Method和Statement信息。Source的Statement信息中就包含著安卓敏感API，該敏感API就是信息流的隱私信息；Sink代表著去向，需要對應用本身與第三方SDK進行區(qū)分。圖SEQ圖\*ARABIC12信息流原始格式第三方SDK區(qū)分：需要解析Sink和Source的Method標簽。以圖12所示為例，本研究首先對“com.umeng.S.utils.UClient”字符串人工分析，可知這是UmengSDK的代碼。這種通過UmengSDK代碼將隱私信息發(fā)送出去的行為，可以判定為第三方SDK的收集行為。如果Sink的Method標簽無法匹配到映射表中任何SDK，也不能排除第三方SDK收集的可能性，比如第三方SDK使用第三方網絡框架比如Volley、OkHttp系列等等；因此當出現上述情況時，進一步判斷Source的Method標簽是否符合第三方SDK的特征。因此，靜態(tài)分析的第三方SDK區(qū)分策略是，首先對Sink的Method標簽進行匹配，如果不符合第三方SDK庫的特征，則判斷Source的Method標簽進行匹配。匹配方法是：只截取Method標簽字符串的前三級子串，比如“com.umeng.Socialize”，這個特征就可以匹配到UmengSDK的特征“com.umeng.*”。最終靜態(tài)分析獲得的結果是敏感API和隱私接收者。表SEQ表\*ARABIC13第一方與第三方API區(qū)分算法偽代碼算法：第一方與第三方API區(qū)分算法1輸入：source_label,sink_label,package,mappingC#第三方SDK映射表2輸出：entity#第一方或第三方SDK3Sink_keywords=sink_label.split(‘.’)[:3]#sink調用棧特征4Source_keywords=source_label.split(‘.’)[:3]source調用棧特征5Package_keywords=package.split(‘.’)[:3]#應用包名特征關鍵詞6forsink_keywordinSink_keywords:#sink優(yōu)先級高于source7ifsink_keywordinPackage_keywords:8return“First_Party”9endif10ifsink_keywordinmappingC:#包名特征匹配11returngetSDKName(mappingC.index(sink_keyword))#識別某第三方SDK12else:13forsource_keywordinSource_keywords:14ifsink_keywordinPackage_keywords:15return“First_Party”16endif17ifsource_keywordinmappingC:#包名特征匹配18returngetSDKName(mappingC.index(source_keyword))#識別某第三方SDK19endif20endfor21endif22endfor流量分析本文選擇使用MitmProxy來捕捉流量，為了防止許多應用證書綁定的保護機制導致在中間攔截https的網絡流量時抓不到隱私數據。本文采用Xposed框架的JusttrustmePlus模塊，對保護機制進行運行時破解[53]。通過Droidbot對應用動態(tài)執(zhí)行進行3分鐘的模擬點擊操作，在此過程中對應用產生的HTTP和HTTPS的請求進行捕獲并寫入日志文件當中。分析日志過程中，排除一些常見的網絡行為（白名單），針對get請求的path和post請求的path和body部分進行分析。將網絡請求的數據對總結好的各個隱私信息類型的特征進行正則匹配。get和post請求的path部分字符串特征主要是“^&(Type)=.*$”的內容，而post請求除了path還有content部分，content對收集的隱私信息往往通過json的方式進行存儲的，因此需要將json解開，不斷遞歸來提取json中的key值。第三方域名的區(qū)分：附錄C的映射表中包含第三方SDK的后端服務器域名特征，URL信息的第二三級域名往往與應用開發(fā)組織的名稱相關，應用的后臺服務器域名一般與其相同。比如“”中的taobao等。本研究將隱私政策URL的第二三級域名作為特征詞寫入映射表當中，與捕獲到的流量host信息進行匹配，來判斷屬于第一方還是第三方行為。第三方域名區(qū)分算法偽代碼如表14所示：表SEQ表\*ARABIC14第一方與第三方域名區(qū)分算法偽代碼算法：第一方與第三方域名區(qū)分算法1輸入：domain,package,mappingC#第三方SDK映射表2輸出：entity#第一方或第三方SDK3keywords=domain.split(‘.’)[1:-1]#域名特征4first_party=package.split(‘.’)[1:-1]5forkeywordinkeywords:6ifkeywordinmappingC:#域名特征匹配7returngetSDKName(mappingC.index(keyword))#識別某第三方SDK8elseifkeywordinfirst_party:9return“第一方”#識別第一方應用10else:11return#實體暫不關注12endif13endfor合并分析過程：首先將隱私接收者的第一方和第三方分開，將方法名和域名通過附錄C映射到隱私接收者上，將靜態(tài)分析的敏感API和流量分析的隱私信息特征通過附錄A和附錄B映射到隱私信息術語上，然后將任何一個隱私接收者的隱私信息類型進行合并。通過靜態(tài)分析可以得到集合A：<接收者1，隱私類型術語1>，<接收者2，隱私類型術語2>...，而動態(tài)分析可以得到集合B：<接收者1，隱私類型術語1>，<接收者2，隱私術語2>...通過對動靜態(tài)信息流的兩集合A與B取并集，通過靜態(tài)分析彌補動態(tài)分析行為觸發(fā)不全的缺陷，使用動態(tài)分析彌補靜態(tài)污點分析無法檢測加固應用、無法檢測出“隱私信息先保存進日志，然后再讀日志將信息通過網絡發(fā)出”的情況，二者互相補充，進一步擴充了對隱私信息泄漏行為的檢測范圍。結果分析本文在行為捕獲時，通過創(chuàng)建多進程來實現靜態(tài)污點分析和網絡流量分析的并行。使用Flowdroid+IccTa的jar包直接生成信息流的xml文件，命令中時間控制在2min，當兩分鐘后自動停止分析；使用DroidBot工具執(zhí)行命令，自動啟動App并進行2min的模擬點擊后卸載App，使用mitmdump工具進行流量捕獲。流程圖如圖13所示：圖SEQ圖\*ARABIC13實際行為信息流的捕獲與分析流程圖本文選擇從樣本集中隨機抽取200個樣本進行測試，對App以及映射表C中的全部SDK對各類隱私信息的收集情況如圖14，圖15，圖16所示。圖SEQ圖\*ARABIC14網絡流量分析結果圖SEQ圖\*ARABIC15靜態(tài)污點分析結果針對上述結果，通過對靜態(tài)污點分析和網絡流量的信息流捕獲情況進行分析，由于2min時間的模擬點擊仍然有許多的隱私收集行為未能觸發(fā)，網絡流量捕獲的行為并不全；而在靜態(tài)污點分析方面，在樣本集中存在83個加固應用，導致沒有隱私信息流檢測出來，并且在靜態(tài)污點分析中，由于SourceAndSink文件的限制，本文沒有對通訊錄系統(tǒng)語言等隱私信息進行靜態(tài)污點分析，但是在網絡流量中加入了這些隱私信息類型的特征。并且在應用“作業(yè)假期答案”中的將應用版本信息保存進shared_preference文件當中，然后讀取文件信息上傳到后臺服務器的行為，靜態(tài)污點分析無法捕獲該隱私信息上傳到后臺服務器的行為，而網絡流量中成功捕獲到。圖SEQ圖\*ARABIC16應用敏感行為分析結果結合圖14和圖15的情況，由圖16結果可知，通過動靜態(tài)分析二者相輔相成，可以更全面地捕獲到應用實際行為的隱私信息流。一致性模型第三章已經從隱私政策文本描述中提取出了信息流的信息，并通過隱私政策術語的層級結構將隱私信息類型的實體對應到術語上；本章上節(jié)通過動靜態(tài)分析實現應用實際行為的隱私信息流提取，對移動應用生成文本描述的信息流和實際行為的信息流。本節(jié)的目標是結合國內的各項規(guī)范條例，設計一個從第一方和第三方收集的角度，對隱私政策描述和實際行為一致性的量化評估系統(tǒng)，將隱私政策描述的信息流和實際行為的信息流進行自動對照，結合3.1.3中創(chuàng)建的隱私信息術語層次結構以及第一方和第三方隱私接收者的區(qū)分，判斷信息流是否一致，若不一致，屬于哪種不一致情形，并最終為隱私政策描述的不一致性進行打分。不一致性案例分析本研究已在上文對《個人信息安全規(guī)范》以及《個人信息自評估指南》進行解讀，隱私政策必須對應用本身以及第三方SDK的隱私收集行為進行詳細準確的描述。本文依據《個人信息安全防范指引》所描述的問題，從隱私政策文本描述存在問題的角度總結出幾類不一致的行為。由于《個人信息安全防范指引》中沒有在違法違規(guī)問題中提及第三方SDK聲明過多的情況，因此本模型對此類情形暫不考慮。下面對各種情形進行描述。隱私類型實體描述籠統(tǒng)對照規(guī)則：對于某一隱私接收者實體（第一方或第三方）的信息流，將實際行為和文本描述的隱私類型術語進行逐個比對，判斷文本描述的術語與實際行為的術語是否存在包含關系。案例分析：名為“萬能遙控器”的應用在隱私政策聲明中提及收集設備相關信息，在對應用進行動靜態(tài)分析后，發(fā)現設備型號、安卓ID等信息通過網絡發(fā)送給其后臺服務器。設備相關信息包含設備型號、安卓ID，因此該應用存在隱私實體描述籠統(tǒng)的情況。隱私類型實體描述不全對照規(guī)則：對于某一隱私接收者實體（第一方或第三方）的信息流，逐一判斷實際行為的隱私類型實體是否在文本描述的隱私類型實體中出現。案例分析：美閱小說（版本7.3.1），在隱私政策中沒有提到收集用戶的地理位置信息，而在網絡流量的抓取過程中發(fā)現了地理位置信息的泄露，因此該應用存在隱私實體描述不全的情況。隱私類型實體描述過多對照規(guī)則：對于某一隱私接收者實體（第一方）的信息流，逐一判斷文本描述的隱私類型實體是否在實際行為的隱私類型實體中出現。舉例分析：“萬能遙控器”（版本0.3.12）該樣本在隱私聲明當中提到要收集軟件信息IP地址、移動設備所用的版本以及手機IMEI識別號。但是，在動靜態(tài)分析過程中發(fā)現在上傳圖片時會泄露移動設備版本以及手機IMEI識別號，但并未泄露IP地址信息。因此該應用存在隱私政策過多聲明的情況。隱私類型實體描述不正確對比規(guī)則：對于某一隱私接收者實體（第一方或第三方）的信息流，逐一判斷實際行為的隱私類型實體是否在文本中明確聲明不收集的隱私類型實體中出現。案例分析：“極速天氣”應用（版本0.3.41）中明確聲明應用不會收集唯一設備識別碼和GPS以外的信息，但是在發(fā)送給應用后臺（第一方）網絡流量中發(fā)現系統(tǒng)版本號的信息。系統(tǒng)版本號與唯一設備識別碼、GPS無關，因此該應用存在隱私實體描述不正確的情況。第三方SDK聲明不全對比規(guī)則：判斷實際行為的第三方SDK，是否出現在隱私政策文本聲明的第三方SDK中，并記錄未出現的個數。案例分析：美閱小說（版本7.3.1）中隱私政策中沒有描述對百度SDK的使用，而在實際行為中可以看到百度SDK相關的隱私信息流。因此該應用存在第三方SDK聲明不全的情況。符號定義文本描述的信息流包括：第一方實體QUOTETEapp，第一方隱私信息術語集合為，隱私類型術語為；第三方SDK實體集合為QUOTETEsdki，第三方SDK收集的隱私類型術語集合為QUOTETSi，隱私類型術語為QUOTETSij，其中帶有感嘆號表示明確聲明不收集。文本描述信息流通過字典形式表示為：實際行為的信息流包括：第一方實體QUOTEBEapp，第一方隱私信息術語集合為，隱私類型術語為QUOTEBAi；第三方SDK實體集合為QUOTEBEsdki，第三方SDK收集的隱私類型術語集合為QUOTEBSi，隱私類型術語為QUOTEBSij。實際敏感行為信息流通過字典形式表示為：模型設計4.2.1節(jié)通過對App的各項不一致行為舉例違規(guī)App進行說明，詳細地介紹了可能出現的五種不一致行為。接下來，本節(jié)設計算法對五類不一致行為進行匹配，并實現對隱私政策的不一致性進行打分。五種不一致案例的數學表示方法，其中情形1-4針對第一方和第三方SDK，情形5僅針對第三方SDK。（籠統(tǒng)一致）（描述不全）（描述過多）（描述不正確）（第三方SDK描述不全）第三方SDK描述不全的偽代碼如表15所示，一致性算法設計的偽代碼如表16所示，并且會用到第三章設計的隱私類型詞匯同義與包含識別算法：表SEQ表\*ARABIC15第三方SDK描述不全的檢測算法算法：檢測第三方SDK描述不全1輸入：text_flow_dict,behavior_flow_dict#應用的SDK信息流字典2輸出：sdk_list#隱私政策描述缺少的SDK3text_sdk_list=text_flow_dict.keys()4behavior_sdk_list=behavior_flow_dict.keys()5sdk_list=[]6forbehavior_sdkinrangebehavior_sdk_list:7ifbehavior_sdknotintext_sdk_list:8sdk_list.append(behavior_sdk)9returnsdk_list

表SEQ表\*ARABIC16一致性對比匹配算法算法：一致性對比匹配算法1輸入：text_flow_list,behavior_flow_list#某一個隱私接收者實體的隱私類型實體列表2輸出：不一致的情形3negative_text_term=get_negative_text_term(text_flow_list)#提取出否定含義的隱私類型實體4text_flow_list.remove(negative_text_term)#將否定含義的實體從原列表刪除5fortextintext_flow_list:#隱私類型實體描述不全6iftextnotinbehavior_flow_list:7returncase2#匹配到case28endfor9forbehaviorinbehavior_flow_list:#隱私類型實體描述過多10ifbehaviornotintext_flow_list:11returncase3#匹配到case312endfor13forbehaviorinbehavior_flow_list:#隱私類型實體描述籠統(tǒng)14Flag=015fortextintext_flow_list:16ifself.termAndterm(text,behavior)==1:17Flag=1#匹配到case118ifself.termAndterm(text,behavior)==0:#發(fā)現文本描述中有同義詞時，跳出該循環(huán)19Flag=020break21returnFlag22endfor23forbehaviorinbehavior_flow_list：#隱私類型實體描述不正確24ifbehaviorinnegative_text_term:25returncase426endfor量化評估國內個人信息安全受到高度重視，對隱私政策和實際行為的一致性也提出了要求，但是目前仍舊沒有研究在此一致性角度對隱私政策的描述進行自動化的量化評估。因此，本文設計并實現了該量化評估模型，從而更加準確具體地表現隱私政策描述應用隱私收集行為的真實程度。本研究計劃根據上述各類不一致情形的危害程度制定扣分規(guī)則，然后對第一方隱私接收者和第三方SDK隱私接收者的不一致狀況進行量化評估。為實現量化評估模型，本文從2021年2月20日到3月30日期間發(fā)布調查問卷，首先在問卷中介紹個人信息安全標準文件的相關內容，然后對第一方和第三方的各個不一致情形進行舉例描述，讓答卷者依據自己的理解判斷其危害等級并對扣分細則進行設置。問卷設計細節(jié)：總分設置為100分。首先讓答卷者對應用本身以及第三方SDK分數占比進行設置。然后對第一方和第三方各類不一致情形的扣分細則進行設置，扣分細則主要包括單位隱私信息類型實體的扣分分數以及該不一致情形的扣分上限。設置扣分上限的原因是，各類不一致情形的危害程度不同，如果命中某一危害程度較弱的不一致情形的隱私類型實體過多，導致大量扣分，這會在一定程度上降低評分的可靠性。問卷如圖18所示。圖18調查問卷設計圖分析87名同學的問卷情況可知，普遍認為隱私類型實體的“描述籠統(tǒng)”和“描述過多”的危害程度較低，“描述不全”和“描述不正確”危害程度很高。本文對答卷者設置的分數進行平均運算，并進行四舍五入得出扣分規(guī)則。對于第一方（即應用本身），總分設置為40分。對于第三方SDK，總分設置為60分，每個SDK的扣分上限為10分，如果SDK未在隱私政策中提及，則10分全部扣除；如果SDK被提及，則按照不一致情形的具體規(guī)則進行扣分。如表17所示。表SEQ表\*ARABIC17一致性對照的扣分規(guī)則第一方（總計40分）隱私類型實體描述籠統(tǒng)（case1）2分（上限10分）隱私類型實體描述不全（case2）5分（上限30分）隱私類型實體描述過多（case3）4分（上限16分）隱私類型實體描述不正確（case4）10分（上限30分）第三方（總計60分）SDK實體描述不全（case5）10分（上限60分）隱私類型實體描述籠統(tǒng)（case1）1分（上限3分）隱私類型實體描述不全（case2）2分（上限6分）隱私類型實體描述不正確（case4）4分（上限8分）打分規(guī)則如下：（4.1）（4.2）（4.3）其中，，。設最終評分為，設描述籠統(tǒng)的隱私類型實體個數為，描述不全的隱私類型實體為，描述過多的隱私類型實體為，描述不正確的隱私類型實體為，SDK實體描述不全的實體個數為。n表示隱私政策文本聲明和實際行為中都檢測出來的SDK個數。本研究設置第一方和第三方SDK的分數比重為40%和60%，因此在百分制下，當大于40分時，記為40分；當大于60分時，記為60分。實驗分析由于國家的大力整治，許多頭部應用已經進行整改，因此本研究聚焦于對用戶量較小、排行榜排名中下的應用。本文選擇小米應用市場中的實用工具類和閱讀類排行榜中部的樣本進行爬取應用100