Android應(yīng)用安全問題與對策思考研究

付亞男

（廣東郵電職業(yè)技術(shù)學(xué)院，廣東 廣州 510630）

0 引 言

近幾年全球信息化的發(fā)展，移動互聯(lián)網(wǎng)的生態(tài)系統(tǒng)日益龐大，市場上豐富的移動應(yīng)用也越來越多，手機(jī)APP 為我們提供便捷服務(wù)的同時，Android 端主要的安全問題如信息泄露、扣費(fèi)短信、惡意廣告、挖礦木馬、勒索軟件等也一直困擾著我們，若對應(yīng)用中潛在的安全隱患不能夠及時發(fā)現(xiàn)和處理，一旦出現(xiàn)問題，無論是對公司或用戶，都將造成不可估量的傷害。因此，做好應(yīng)用技術(shù)開發(fā)的安全策略、讓應(yīng)用更安全更可靠的運(yùn)行，是每個開發(fā)者義不容辭的責(zé)任。

1 Android 應(yīng)用安全問題及對策

本文從安全開發(fā)角度梳理了一個Android APP 需要關(guān)注的安全問題，主要從程序安全和數(shù)據(jù)安全兩個方面進(jìn)行分析，如圖1所示。

圖1 APP 安全組成

1.1 程序安全

在開發(fā)APP 過程中，許多開發(fā)者只關(guān)注如何實(shí)現(xiàn)功能，對Android 的安全機(jī)制理解不夠，導(dǎo)致發(fā)布在應(yīng)用市場上的很多APP 存在安全漏洞。程序安全主要包括程序漏洞、代碼混淆、應(yīng)用簽名、APK 加固這四個方面的安全，下面將對這四方面進(jìn)行詳細(xì)分析。

1.1.1 程序漏洞

程序漏洞主要體現(xiàn)在以下幾個方面：

（1）AllowBackup 漏洞。Android 2.1 以上的系統(tǒng)可以為APP 提供應(yīng)用程序數(shù)據(jù)的備份和恢復(fù)功能，當(dāng)Android Manifest.xml 文件中的allowBackup 被設(shè)置為true 時，攻擊者可通過adb backup、adb restore 來對應(yīng)用數(shù)據(jù)進(jìn)行備份和恢復(fù)，從而獲取到用戶的敏感信息，如證件號、手機(jī)號、身份令牌等，造成用戶隱私數(shù)據(jù)的泄漏和資產(chǎn)損失，在正式發(fā)布應(yīng)用之前，顯式設(shè)置為false，不能對應(yīng)用數(shù)據(jù)備份。

（2）Java 動態(tài)調(diào)試風(fēng)險。應(yīng)用級配置文件build.gradle中的調(diào)試標(biāo)記默認(rèn)是true，即可以通過JDB 等調(diào)試工具進(jìn)行調(diào)試，攻擊者可以訪問和篡改用戶敏感信息，甚至分析并修改相關(guān)業(yè)務(wù)邏輯的代碼，從而實(shí)現(xiàn)竊取用戶密碼，繞過驗(yàn)證碼保護(hù)等違規(guī)操作，因此，應(yīng)該在APP 正式發(fā)布之前，設(shè)置android：debuggable 屬性為false，關(guān)閉Java 動態(tài)調(diào)試功能，不允許被調(diào)試。

（3）程序包日志控制。一些開發(fā)者習(xí)慣在開發(fā)過程中打印調(diào)試日志，用于排查問題，卻沒能在調(diào)試完畢后及時刪除日志。調(diào)試函數(shù)日志中可能輸出重要的調(diào)試信息，諸如組件名、通信數(shù)據(jù)、跟蹤變量等，這些信息的打印會導(dǎo)致用戶信息、重要代碼事件流的泄漏，從而為攻擊者提供便利。對應(yīng)用內(nèi)Log 統(tǒng)一封裝控制基類，并判斷測試環(huán)境允許打印日志，正式環(huán)境關(guān)閉日志的輸出，或修改編譯器配置，對敏感代碼進(jìn)行Inspections 提醒，告知開發(fā)者應(yīng)做到及時刪除。

（4）WebView 漏洞攻防。WebView 漏洞包括四種情況，下面將做詳細(xì)介紹。

第一種JS 注入漏洞。惡意APP 可以注入JavaScript 代碼進(jìn)入WebView 中的網(wǎng)頁，網(wǎng)頁未作驗(yàn)證。惡意網(wǎng)頁可以執(zhí)行JavaScript 反過來調(diào)用APP 中注冊過的方法，或者使用資源。這些惡意程序嵌入Web APP，然后竊取用戶信息，遠(yuǎn)程調(diào)用APP 代碼。更有甚者，通過Java Reflection 調(diào)用Runtime 執(zhí)行任意代碼。解決辦法主要：對于Android 4.2 及其以上版本，google 已經(jīng)fix 該漏洞，只需要native interface上增加@addJavaInterface 標(biāo)示即可；對于Android 4.2 以前的版本，則需要覆寫addJavaInterface（）方法。

第二種WebView 釣魚漏洞。釣魚是最難使用技術(shù)手段解決的最常見攻擊，防釣魚技術(shù)層面可以做兩件事：一是檢查WebView 加載的目標(biāo)鏈接是否存在安全風(fēng)險；二是對WebView 關(guān)閉腳本環(huán)境。

第三種WebView 跨域漏洞。 主要是因?yàn)镴S 的XmlHttpRequest 可以讀取系統(tǒng)存放cookie 的本地文件webviewCookiesChromium.db，等同于提供了對cookie 的讀訪問權(quán)限。針對Android 4.1 以及以上系統(tǒng)，本身不存在這個跨域漏洞，沒有針對性修改，其他版本系統(tǒng)可通過設(shè)置禁止從本地html 加載頁面來防止這個漏洞的出現(xiàn)。

第四種WebView 數(shù)據(jù)漏洞。安卓WebView 組件默認(rèn)會引導(dǎo)用戶把明文形式的密碼保存到應(yīng)用數(shù)據(jù)目錄的databases/webview.db 中，從而攻擊者可通過root 的方式訪問該文件，從而竊取用戶的用戶名和密碼。為了預(yù)防這個漏洞，可以通過設(shè)置savePassword（）為false 來顯式關(guān)閉密碼存儲功能：WebView.getSettings（）.setSavePassword（false）。

（5）應(yīng)用組件暴露。Android 系統(tǒng)共有四大組件：活動組件、服務(wù)組件、廣播組件、內(nèi)容組件。如果組件暴露，攻擊者可以通過外部傳入Intent 來越權(quán)訪問，從而引起數(shù)據(jù)泄露、DOS 攻擊和應(yīng)用連續(xù)崩潰等問題。所以在APP 應(yīng)用中如果非必要，組件不要進(jìn)行導(dǎo)出，在AndroidManifest.xml文件中，設(shè)置組件的exported 屬性為false；如果組件一定要提供給外部進(jìn)行調(diào)用的話，可以對組件的權(quán)限進(jìn)行控制。

（6）第三方sdk 組件。目前，大部分Android 應(yīng)用都集成了很多的第三方SDK，有些第三方SDK 可能來自開源社區(qū)，安全性并沒有被驗(yàn)證，如果存在安全問題，會產(chǎn)生用戶的隱私和財(cái)產(chǎn)安全被損耗等嚴(yán)重的后果。目前發(fā)生的第三方SDK 安全事件主要原因在以下兩方面：

1）第三方SDK 的開發(fā)者只關(guān)注實(shí)現(xiàn)功能，在安全方面的投入少，并且相關(guān)安全技術(shù)不高；

2）部分惡意開發(fā)者滲入了SDK 開發(fā)環(huán)節(jié)并通過吸引合法APP 的開發(fā)者來集成他們的SDK，從而躲避應(yīng)用市場和安全廠商的檢測。因此，為保障第三方sdk 安全，可以采取下面措施：一是培養(yǎng)開發(fā)人員的安全意識。在開發(fā)過程的各個環(huán)節(jié)建立安全評估檢查點(diǎn)；開發(fā)環(huán)節(jié)嚴(yán)格遵守開發(fā)規(guī)范，防止類似調(diào)試后門等安全威脅的產(chǎn)生；應(yīng)用發(fā)布前交給獨(dú)立的內(nèi)部或外部測評組織進(jìn)行安全性評估。二是防止APP被惡意篡改。規(guī)范APP 發(fā)布流程；防止應(yīng)用簽名證書泄露；選擇正規(guī)渠道發(fā)布APP；應(yīng)用升級更新時為防止運(yùn)行被劫持的安裝包，一定要先校驗(yàn)下載安裝包。

1.1.2 代碼混淆

APP 中的一些關(guān)鍵資源文件沒有進(jìn)行加密保護(hù)，攻擊者可以從APP 中提取關(guān)鍵的資源文件，進(jìn)行二次使用或從資源文件中獲取本地業(yè)務(wù)邏輯代碼，從而對APP 發(fā)起攻擊。例如對APP 進(jìn)行關(guān)鍵邏輯篡改、植入惡意代碼、網(wǎng)絡(luò)協(xié)議分析等等。開啟代碼混淆minifyEnabled=true，有利于增加攻擊者反編譯獲取代碼的成本，且打包時移除無用資源，減少APK 體積；引入資源混淆如AndResGuard，將原本冗余的資源路徑變短，如“res/drawable/newerIcon”將變?yōu)椤皉/d/i”，可以再次優(yōu)化減APK 體積，且混淆資源路徑后，使用APKTool 工具無法直接回編生成二次APK，也在一定程度上提升了APK 反破解難度。

1.1.3 應(yīng)用簽名

應(yīng)用簽名在保障設(shè)備安全方面發(fā)揮著重要作用，可用于進(jìn)行權(quán)限檢查以及軟件更新。簽名一是保證消息來源的真實(shí)性，二是確保消息不會被第三方篡改，早期的V1 簽名會將APK 內(nèi)文件進(jìn)行逐一簽名并將簽名結(jié)果保存在ETA-INF 目錄下，V1 簽名的缺點(diǎn)一是簽名校驗(yàn)速度較慢，在APK 安裝校驗(yàn)過程中需要對所有文件進(jìn)行摘要計(jì)算，在APK 資源較多、性能較差的機(jī)器上簽名校驗(yàn)將花費(fèi)較長時間，導(dǎo)致安裝速度慢，影響用戶體驗(yàn)，且META-INF 目錄用來存放簽名，自然此目錄本身是不計(jì)入簽名校驗(yàn)過程的，可以隨意在這個目錄中添加文件。升級到V2 版本簽名，V2 簽名將驗(yàn)證歸檔中的所有字節(jié)，而不是單個ZIP 條目，因此在簽署后無法再運(yùn)行重壓ZIP 包等，能夠及時發(fā)現(xiàn)對APK 的受保護(hù)部分進(jìn)行的所有更改，從而有助于加快驗(yàn)證速度并增強(qiáng)完整性保證。后續(xù)Android 9.0 引入了V3 版本簽名，在V2 插入的簽名塊中又插入了一個新塊，以秘鑰輪轉(zhuǎn)的方案，來做簽名的替換和升級，圖2為是推薦使用的APK 簽名流程圖。

圖2 APK 簽名流程圖

1.1.4 APK 加固

普通的APK 文件對攻擊者來說屬于裸奔狀態(tài)，被反編譯后能夠輕易得到明文資源和DEX 原代碼文件，因?yàn)槌Ｒ?guī)的Android 程序代碼都將打包在DEX 和so 文件中，這些文件經(jīng)過反編譯工具可以得到對應(yīng)的源代碼閱讀。圖3為APK 加固圖，應(yīng)用加固技術(shù)首先將原DEX 文件加密或者隱藏起來，然后放入一個新的殼DEX 到APK 中，最后程序啟動時先運(yùn)行這個殼DEX，然后殼DEX 在運(yùn)行時再加載原DEX，使得攻擊者不能直接通過APK 解壓輕易獲取到原代碼資料。

圖3 APK 加固圖

建議通過引入第三方加固平臺對混淆簽名后的APK 進(jìn)行安全加固，從而進(jìn)一步保證DEX、so、資源文件、數(shù)據(jù)文件等重要的APK 文件信息的安全性，加固后的APK 通過代碼插花、虛假控制流、字符串加密等手段提高了程序被破解的難度，能夠一定程度上防止靜態(tài)逆向、防篡改和二次打包，有效保護(hù)APP 的安全性。

1.2 數(shù)據(jù)安全

數(shù)據(jù)安全包括網(wǎng)絡(luò)數(shù)據(jù)和本地?cái)?shù)據(jù)兩個方面。早期的Http 協(xié)議是明文傳輸攻擊者可以輕易地通過Charles 或Fiddler 等抓包工具來攔截和篡改請求數(shù)據(jù)，雖然Android 9.0以后谷歌官方限制了默認(rèn)不允許非加密的鏈接來改進(jìn)對設(shè)備和數(shù)據(jù)安全的保護(hù)，但是Https 并不能直接阻擋攻擊者分析請求接口并發(fā)起惡意請求攻擊，數(shù)據(jù)之間的傳遞仍可被攻擊者輕易抓取到并進(jìn)行篡改。

1.2.1 網(wǎng)絡(luò)數(shù)據(jù)

對于終端之間的通訊的數(shù)據(jù)安全，主要存在三個問題：

（1）傳輸內(nèi)容可能被竊聽。

（2）傳輸內(nèi)容可能被篡改。

（3）無法驗(yàn)證雙方的身份。

為了保證數(shù)據(jù)的真實(shí)性和可靠性，一般通過加簽和加密兩種方式來提高數(shù)據(jù)交互的安全性。簽名校驗(yàn)是對請求數(shù)據(jù)、請求頭參數(shù)進(jìn)行一定規(guī)則的拼接和運(yùn)算并進(jìn)行結(jié)果簽名，生成唯一的結(jié)果sign 作為校驗(yàn)字段，服務(wù)端接收到請求后進(jìn)行唯一性驗(yàn)簽校驗(yàn)，至于簽名規(guī)則可雙方約定，這里的簽名規(guī)則相當(dāng)于秘鑰的作用，可將簽名代碼Native 化，或增加花指令來進(jìn)一步提高破解難度。數(shù)據(jù)加密是對提交到服務(wù)器和從服務(wù)器接收到的數(shù)據(jù)都進(jìn)行加密后再傳輸。加密類型有多種手段，一般使用對稱加密和非對稱加密的混合方式進(jìn)行，對稱加密的耗時較大，對大數(shù)據(jù)加密時存在一定的性能問題，Https 本身的加密處理也是類似，另外可以由后端控制公鑰的過期時間和刷新來保持秘鑰的動態(tài)性，進(jìn)一步提高安全等級。

1.2.2 本地?cái)?shù)據(jù)

本地?cái)?shù)據(jù)包括三種情況：代碼中敏感URL、APP 中敏感數(shù)據(jù)、通用加密算法參數(shù)，如圖4所示。

圖4 本地?cái)?shù)據(jù)情況組成

（1）代碼中敏感URL。直接將訪問的網(wǎng)址或訪問的IP地址硬編碼寫到代碼中，那么攻擊者通過反編譯APP 進(jìn)行靜態(tài)分析，搜索URL 或IP 相關(guān)的信息，那么這些URL 或IP 信息就會成為攻擊者的一個利用目標(biāo)。

（2）APP 中敏感數(shù)據(jù)。Android 主要有五種數(shù)據(jù)存儲方式：文件存儲、SharedPreferences 輕量級存儲、SQLite 數(shù)據(jù)庫存儲、ContentProvider 數(shù)據(jù)共享、網(wǎng)絡(luò)存儲。APP 運(yùn)行時候會進(jìn)行記錄或存儲一些敏感信息：個人隱私、登錄信息、本地驗(yàn)證碼、聊天記錄，等等。SharedPreferences 存儲數(shù)據(jù)主要記錄存儲一些數(shù)據(jù)量較小的信息。存儲的信息直接可以用MT 管理工具或者直接用adb 復(fù)制傳輸?shù)酵獠侩娔X主機(jī)上，再通過可視化工具進(jìn)行打開查看文件，會造成配置信息或敏感的賬號信息泄露。攻擊方式有兩種方式：一是利用apktool 反編譯APP 應(yīng)用，并進(jìn)行查看二進(jìn)制代碼數(shù)據(jù)就能直觀地看到敏感的操作調(diào)用敏感數(shù)據(jù)。二是通過代理模式進(jìn)行抓包就可以直接抓到APP 運(yùn)行中的操作的敏感數(shù)據(jù)。

（3）通用加密算法參數(shù)。代碼中往往會出現(xiàn)一些保護(hù)敏感信息的常量字符串，例如在代碼中硬編碼AES 加密的key、iv 等，或者用戶的VPN 密碼等等。因此，本地?cái)?shù)據(jù)同樣需要進(jìn)行加密存儲，如Sqlite 數(shù)據(jù)庫、SP 文件、SD 卡緩存、程序運(yùn)行日志、本地資源文件等，加密過程可根據(jù)數(shù)據(jù)重要程度進(jìn)行對稱加密或非對稱加密，且同樣建議將加密過程N(yùn)ative 化，相對于Java 代碼容易被反編譯，C++代碼編譯后生成的庫是一個二進(jìn)制文件，能夠初步阻擋住一些逆向者。一些重要數(shù)據(jù)（用戶賬號密碼等），或者標(biāo)記存儲本地的時候也應(yīng)該進(jìn)行加密，或者直接存儲hash 碼，而不能直接存儲明文。有些存儲本地的數(shù)據(jù)，比如令牌，就需要進(jìn)行加密處理。登錄成功后的重要信息，如需要存儲本地，也需要加密。

2 結(jié) 論

本文通過探討Android APP 可能存在的安全問題，并從開發(fā)者角度提出相應(yīng)的防護(hù)措施來加強(qiáng)Android APP應(yīng)用的安全，從而對于保護(hù)Android應(yīng)用程序的安全具有很高的價值和意義。