陳希，劉穎卿，葉蘊芳

（1 中國移動通信集團福建有限公司，福州 350001； 2 中國移動通信有限公司研究院，北京 100053）

隨著移動互聯(lián)網(wǎng)的快速發(fā)展，目前移動智能終端已越來越普及，據(jù)相關數(shù)據(jù)報告，2014年我國移動智能終端用戶規(guī)模達10.6億，其中基于Android操作系統(tǒng)的移動終端設備已占據(jù)了超過80%的市場份額。Android操作系統(tǒng)的廣泛使用也帶動了Android應用市場的繁榮發(fā)展。

然而Android應用開發(fā)者的安全意識并沒有跟上應用發(fā)展的步伐，導致應用可以被破解篡改，插入惡意廣告插件，應用自身存儲和處理的用戶數(shù)據(jù)泄露等諸多安全問題。追根究底，一方面原因是Android本身安全機制的不足，另一方面是由于應用開發(fā)者疏忽導致的。Android應用本身存在的可被利用的安全問題。因此需要通過對應用進行安全評估，發(fā)現(xiàn)移動應用中存在的安全風險，幫助提升應用本身的安全性。

面對Android平臺上的威脅，目前發(fā)展較成熟的是惡意代碼檢測。當前國內(nèi)外Android系統(tǒng)的惡意軟件檢測方法主要為基于特征碼的檢測方法和基于靜態(tài)行為的檢測方法。針對Android操作系統(tǒng)的安全監(jiān)控軟件主要分成兩類：其中一類是基于特征碼檢測方法的傳統(tǒng)手機安全監(jiān)控軟件，另外一類是基于靜態(tài)行為檢測方法監(jiān)控軟件。目前有人提出過基于應用程序動態(tài)行為的檢測思想，然而更多的只是一種設計的思路，還沒有比較完整全面的基于Android平臺的應用程序安全評估系統(tǒng)的整體設計與實現(xiàn)。本文基于現(xiàn)有的移動應用評測技術，從程序安全、數(shù)據(jù)安全、通信安全和業(yè)務安全等方面，給出了整套的安全評測體系方法。

1 移動智能終端安全問題

1.1 終端所面臨的安全威脅

近年來移動終端安全事件層出不窮, 病毒傳播是目前移動終端所面臨的一個最大的安全問題。除了病毒的威脅外，移動終端還面臨著空中接口的安全威脅。

這些安全問題的出現(xiàn)，與移動終端智能化的發(fā)展趨勢有著必然的聯(lián)系。首先，移動終端的處理能力越來越強大，硬件技術水平的提高為病毒的傳播帶來便利。其次，開放的操作系統(tǒng)平臺更容易開發(fā)出新的應用，給用戶更好的體驗，同時也很容易導致病毒的泛濫。再次，智能移動終端的外部接口越來越豐富，都為病毒的傳播提供了多種通道。最后，4G時代的來臨，使移動終端接入互聯(lián)網(wǎng)的帶寬大大增加，使用手機進行電子支付等業(yè)務都讓移動終端面臨感染病毒的威脅。

總體來講，移動終端所面臨的安全威脅主要來自以下幾個方面：空中接口帶來的安全威脅、外部接口帶來的安全威脅、高速接入互聯(lián)網(wǎng)帶來的安全威脅、終端本身信息存儲面臨的安全威脅。各方面的安全威脅可能造成的安全問題有病毒感染、信息泄露、資費損失等。其中病毒感染既可能造成信息泄漏、資費損失，如臥底軟件、自動撥打電話發(fā)送短信的病毒等。

1.2 終端安全問題的根源分析

在業(yè)務應用層面，智能終端的生態(tài)鏈通常包括智能終端、應用商店和應用服務器，其信息安全問題的根源也來自于以上3個環(huán)節(jié)。

一方面，智能終端存在的安全隱患遠大于傳統(tǒng)移動終端。任何智能終端操作系統(tǒng)都存在漏洞，使木馬、蠕蟲等惡意代碼的存在成為可能；智能終端采用開放的操作系統(tǒng)及軟件平臺架構，可能會被不法分子用來開發(fā)惡意代碼軟件。此外，絕大多數(shù)操作系統(tǒng)提供商給自己預留了非公開API，由此帶來惡意后門的隱患；智能終端很容易被終端廠商、操作系統(tǒng)提供商和軟件開放商預置SP代碼、SP服務鏈接或SP客戶端進行惡意吸費；智能終端中存儲了包括通信錄、短消息、通話記錄、信息卡信息等大量重要用戶信息，任何安全問題都會對用戶的工作和生活產(chǎn)生巨大的影響；一些水貨手機提供商預先修改手機的ROM，置入自啟動程序，改裝手機操作系統(tǒng)，以在售出后獲得用戶信息或者執(zhí)行惡意操作。

另一方面，由于終端制造與網(wǎng)絡服務一體化模式的出現(xiàn)，智能終端與應用商店和應用服務器緊密結合，成為各種應用軟件及數(shù)字內(nèi)容的承載平臺和傳播渠道，可能被不法分子用來傳播反動違法內(nèi)容；智能終端上的微博、即時消息等新應用具有傳播速度快、范圍廣的特點，可能被不法分子利用進行非法群體活動。這些都給國家安全和社會穩(wěn)定帶來了巨大挑戰(zhàn)。

總體來說，智能終端的信息安全問題和計算機面臨的安全問題類似。但智能終端時刻與移動網(wǎng)絡相連，并且其操作系統(tǒng)并不能像計算機一樣隨時安裝，一旦安全事件爆發(fā)，其危害性將遠遠大于計算機。

2 移動應用安全評測技術

2.1 應用權限安全

應用權限機制雖然為系統(tǒng)和應用程序提供了一定的安全保障，如在manifest文件中為應用程序設定權限、應用程序簽名等，盡可能地為應用程序提供安全保障。但是，仍然不可避免地存在濫用權限機制的問題。

如共享用戶ID的特性存在安全隱患，一旦應用程序聲明了一個共享用戶ID，在其運行時，每一個共享這個用戶ID的應用程序都會被授予一組相同的權限，它們之間可以互相訪問資源。這樣一來，攻擊者就有可能利用共享用戶ID進行惡意攻擊。

2.2 應用程序安裝安全分析

Android應用程序以.apk文件形式在設備上進行部署。.apk文件是一個包括.dex文件的歸檔文件，不含有源代碼。軟件包管理器為安裝進程提供服務，檢查.apk的正確性。檢查方式包括但不局限于驗證數(shù)字簽名、共享用戶ID的合法性、權限要求及驗證.dex文件。但是由于Android采用對應用程序簽名的形式，有開發(fā)者自簽名，沒有經(jīng)過權威認證機構的鑒定，所以無法對開發(fā)者身份進行驗證，也無法驗證.apk的完整性。

在Android系統(tǒng)上安裝設備的方式也直接影響到應用程序的安全性。.apk文件有3種安裝方式。第一種方式是通過Android的adb調(diào)試橋安裝：自動授予應用程序正常級別和危險級別的權限。由于缺乏用戶的交互，這種安裝方式具有較高安全風險。其余的兩種方式分別是從應用商店安裝、從SD卡上的.apk文件進行安裝，直接與軟件包管理器交互。

2.3 數(shù)據(jù)庫安全分析

Android采用了開源的SQLite。為了滿足嵌入式系統(tǒng)對數(shù)據(jù)庫本身的輕便型，以及對數(shù)據(jù)庫存儲效率、訪問速度、內(nèi)存占用率等性能的要求，數(shù)據(jù)庫沒有用戶管理、訪問控制和授權機制，凡是操作系統(tǒng)的合法用戶，只要該用戶對文件具有讀寫權限，就可以直接訪問數(shù)據(jù)庫文件。開源SQLite數(shù)據(jù)庫不提供加密機制，因此不提供數(shù)據(jù)級的保密性。Android系統(tǒng)在使用過程中很有可能遭受到SQL注入攻擊。對于數(shù)據(jù)庫查詢，如果開發(fā)者采用字符串連接方式構造SQL語句，就會產(chǎn)生SQL注入。

3 移動應用安全評測體系的構筑

3.1 移動應用安全評測體系

移動應用安全評測體系主要從程序安全、數(shù)據(jù)安全、通信安全、業(yè)務安全4個方面對移動應用的安全性進行評估，并采用代碼靜態(tài)檢測、滲透測試、基于數(shù)據(jù)生命周期的安全測試等手段，發(fā)現(xiàn)移動應用中存在的安全風險。并針對評估結果給出相應的修補方案建議，推動移動應用安全性提升。

3.1.1 程序安全

3.1.1.1 代碼篡改風險

客戶端軟件可以被反編譯時，應當具備防篡改措施，如完整性校驗等。

3.1.1.2 安裝包認證數(shù)據(jù)泄露

客戶端軟件的安裝包中不應包含認證數(shù)據(jù)，如密鑰、業(yè)務校驗證書等。

3.1.1.3 代碼關鍵內(nèi)容應混淆

應對客戶端軟件的關鍵部分代碼進行深度混淆，即對所有可修改的類名、函數(shù)名、變量名進行混淆，使其不具備可讀性。

3.1.1.4 組件權限安全性

客戶端包含的receiver、service、content provider、activity組件，應進行權限限制。如果組件無須跨進程交互，應設置exported屬性為false。若需要將exported屬性設置為true，則需要設置android:protectionLevel為signature或signatureOrSystem。

3.1.1.5 日志信息泄漏

需要在設計階段劃分出應用關鍵信息。程序編碼階段，在進行日志輸出、程序調(diào)試輸出的環(huán)節(jié)，需嚴格控制應用關鍵信息的輸出。程序在發(fā)布時，需刪除所有的應用關鍵信息的輸出代碼。

3.1.1.6 程序配置參數(shù)安全性

應將AndroidManifest文件的動態(tài)調(diào)試配置參數(shù)、備份配置參數(shù)進行安全的配置，防止應用被動態(tài)調(diào)試，破解業(yè)務邏輯流程。備份參數(shù)設置不正確，使得用戶可通過adb backup來進行對應用數(shù)據(jù)的備份，在無Root的情況下可以導出應用中存儲的所有數(shù)據(jù)，造成用戶數(shù)據(jù)的嚴重泄露。

3.1.1.7 硬編碼問題

數(shù)據(jù)庫鏈接字符串、用戶名密碼等不宜在程序中寫死，而應采用配置文件來存儲。

3.1.1.8 WebView組件遠程代碼執(zhí)行漏洞

應用應避免使用WebView組件的addjavascript Interface函數(shù)，因為如果沒有對注冊JAVA類的方法調(diào)用進行限制，導致攻擊者可以利用反射機制調(diào)用未注冊的其它任何JAVA類，最終導致javascript代碼對設備進行任意攻擊。若使用了addjavascriptInterface函數(shù)，需要添加如下安全措施。

（1）通過在Java的遠程方法上面聲明一個@JavascriptInterface 來代替addjavascriptInterface。

（2）在使用js2java的bridge時候，需要對每個傳入的參數(shù)進行驗證，屏蔽攻擊代碼。如果使用HTTPS協(xié)議加載URL，應進行證書校驗防止訪問的頁面被篡改掛馬；如果使用HTTP協(xié)議加載URL，應進行白名單過濾、完整性校驗等防止訪問的頁面被篡改；如果加載本地html，應將html文件內(nèi)置在APK中，以及進行對html頁面完整性的校驗。

（3)移除Android系統(tǒng)內(nèi)部的默認內(nèi)置接口：remo veJavascriptInterface（"searchBoxJavaBridge_")； re moveJavascriptInterface（"accessibility")；removeJava scriptInterface（"accessibilityTraversal")。

3.1.1.9 Webview明文存儲密碼漏洞

使用Webview時需要關閉Webview的自動保存密碼功能，防止用戶密碼被Webview明文存儲。

3.1.1.10 Activity釣魚劫持風險

應用程序應當具備防釣魚劫持措施。應用程序自身通過獲取棧頂activity，判斷系統(tǒng)當前運行的程序，一旦發(fā)現(xiàn)應用切換（可能被劫持），給予用戶提示以防范釣魚程序的欺詐。獲取棧頂activity（如圖1所示），當涉及敏感activity（登錄、交易等）切換時，判斷當前是否仍留在原程序，若不是則通過Toast給予用戶提示。

或者使用HTML5架構或Android+HTML5混合開發(fā)，實現(xiàn)登陸、支付等關鍵頁面，降低被劫持的風險。

3.1.1.11 證書合規(guī)性

應用程序應使用正規(guī)的私有證書進行簽名，不能使用調(diào)試證書進行簽名。

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

3.1.2.1 應用關鍵數(shù)據(jù)錄入顯示

輸入用戶口令等應用關鍵信息時，客戶端軟件界面應為非明文顯示。

3.1.2.2 應用關鍵數(shù)據(jù)截獲

客戶端軟件應具備防護措施，保護用戶輸入的數(shù)據(jù)應不被移動終端的其它設備或程序非授權獲取。即用戶輸入的數(shù)據(jù)不應在明文在內(nèi)存進行處理。

3.1.2.3 應用關鍵數(shù)據(jù)存儲安全

客戶端軟件在進行終端本地的文件或數(shù)據(jù)庫數(shù)據(jù)存儲時，應保留最少的應用關鍵數(shù)據(jù)，并限制數(shù)據(jù)存儲時間。

3.1.2.4 用戶身份認證信息存儲安全

圖1 獲取棧頂activity

客戶端程序如果必要身份認證信息進行存儲，則必須加密存儲，不可明文存儲或使用可逆向的處理方式（如Base64處理）。

3.1.2.5 應用關鍵信息的顯示安全

客戶端軟件對在運行中必須要顯示的應用關鍵信息，應當進行部分隱藏處理，如身份證號可顯示為110***********1234等。

3.1.2.6 界面切換后輸入的應用關鍵數(shù)據(jù)需清空

客戶端軟件不應對界面應用關鍵數(shù)據(jù)進行緩存。如在界面A輸入應用關鍵信息（如注冊頁面輸入姓名、銀行卡號等）后，進入其它頁面B后，再次返回界面A時，應用關鍵信息應當清空，不能留存。

3.1.2.7 卸載后是否清除全部應用關鍵數(shù)據(jù)

客戶端軟件應當將加密后的應用關鍵數(shù)據(jù)存儲在應用卸載后系統(tǒng)會自動清空的目錄下。如系統(tǒng)data/data/程序包名目錄下。

3.1.3 通信安全

3.1.3.1 網(wǎng)絡通信協(xié)議安全性

客戶端軟件若存在支付功能，進行支付相關操作時，應采用端到端的加密手段保護通信過程中數(shù)據(jù)傳輸?shù)陌踩?。和服務器間的通信應使用SSL/TLS或IPSec等安全協(xié)議，或采用WAP模式，并支持WTLS?？蛻舳伺c服務器之間所有經(jīng)過認證的連接都需要使用不低于SSL安全級別的加密通信方式。使用SSL協(xié)議時，其版本應3.0及更高以上版本，應取消對低版本SSL協(xié)議的支持，確保SSL證書使用正確的domain name，且證書時間沒有過期。加密的數(shù)據(jù)包括身份鑒別信息，銀行卡賬戶密碼等應用關鍵信息。

3.1.3.2 網(wǎng)絡通信內(nèi)容應用關鍵數(shù)據(jù)檢查

客戶端軟件和服務器間的通信內(nèi)容，不應包含明文的應用關鍵數(shù)據(jù)和配置信息等。

3.1.3.3 中間人攻擊漏洞

使用HTTPS時應禁止使用ALLOW_ALL_HOSTNAME_VERIFIER，因為這樣會存在中間人攻擊的風險。必須使用STRIC_HOSTNAME_VERIFIER，并校驗證書。

3.1.4 業(yè)務安全

3.1.4.1 鑒別失敗處理機制安全

客戶端軟件具備登錄功能時，應提供連續(xù)鑒別失敗處理功能。運行程序時，連接多次輸入錯誤的用戶鑒別數(shù)據(jù)，應采取鎖定或需要輸入驗證碼等防護措施。

3.1.4.2 登錄超時后是否重鑒別

客戶端軟件具備登錄功能時，軟件保護內(nèi)若涉及用戶利益（資費、銀行卡等金融信息、公司內(nèi)部機密信息等待）時，應當具備會話超時處理機制，會話超時后應重鑒別。

3.1.4.3 登錄錯誤時密碼或賬戶提示混淆

客戶端軟件具備登錄功能時，在登錄失敗時，應當混淆提示密碼和賬戶，如“用戶名或密碼錯誤”，而不是分別進行不同的提示。

3.1.4.4 支付過程是否輸入支付密碼

客戶端軟件存在支付功能時，應當設置在使用支付功能時，需要輸入不同于登錄密碼的支付密碼。

3.1.4.5 認證方式的安全性

客戶端軟件在大額支付、重要信息修改等關鍵業(yè)務操作時，應采用除密碼以外的安全認證機制。如短信驗證碼、動態(tài)口令卡、移動口令牌、移動數(shù)字證書等認證機制。

3.1.4.6 認證信息輸入驗證風險

應用應對所有的輸入信息的長度和類型進行驗證，防止輸入不合規(guī)信息。

3.1.4.7 SQL注入

應對應用程序的輸入信息進行過濾，防止被SQL注入，如使用正則表達式驗證輸入的格式。

3.2 移動應用安全評測平臺的框架

移動應用安全評測平臺軟件架構按照邏輯分層、功能模塊化思想進行設計，整個系統(tǒng)邏輯上分為展示層、服務層、數(shù)據(jù)層。使用具有高度的內(nèi)聚性和透明性的分布式數(shù)據(jù)存儲，服務與功能采用組件模型，以達到高可擴展/可伸縮的目的，模塊之間數(shù)據(jù)交換采用協(xié)同化的工作流構建實現(xiàn)，從而保證了系統(tǒng)結構的合理劃分和在系統(tǒng)擴展情況下的穩(wěn)定性。系統(tǒng)架構圖如圖2所示。

系統(tǒng)采用分層構架設計思想，從下至上分別如下。

（1）展示層：向系統(tǒng)管理員、評估專家提供系統(tǒng)可操作功能、系統(tǒng)評估報告、監(jiān)測結果、風險分析等功能；同時向管理員提供基礎數(shù)據(jù)、應用等錄入、維護的操作界面。

（2）服務層：平臺提供系統(tǒng)運行基礎服務與業(yè)務支撐相關服務，是整個系統(tǒng)的核心業(yè)務功能體現(xiàn)。

（3）數(shù)據(jù)層：提供平臺運行的各種數(shù)據(jù)，基于分布式架構設計，完成系統(tǒng)各類業(yè)務數(shù)據(jù)的統(tǒng)一存儲管理，包括安全特征信息、應用程序分組、業(yè)務數(shù)據(jù)等3類數(shù)據(jù)，為系統(tǒng)業(yè)務層、展示層提供數(shù)據(jù)存取訪問服務。針對不同業(yè)務數(shù)據(jù)的訪問要求進行數(shù)據(jù)存儲層的設計，采用基于SQL查詢的關系型數(shù)據(jù)庫、方便文件存儲訪問的文件服務器等不同的數(shù)據(jù)存儲技術和產(chǎn)品。

系統(tǒng)的功能圖如圖3所示。

平臺整體功能架構根據(jù)功能分類的不同，結合對總技術規(guī)范的要求和理解，對平臺的整體功能進行了功能域的劃分，分為展示層、服務層和數(shù)據(jù)層。

（1）展示域：實現(xiàn)系統(tǒng)用戶的交互操作門戶，為系統(tǒng)管理人員、安全管理員、評估專家等不同角色提供統(tǒng)一的系統(tǒng)訪問門戶。

（2）服務層：服務層是系統(tǒng)所有業(yè)務流程邏輯的集中體現(xiàn)，涵蓋系統(tǒng)提供的所有管理功能，包括基礎數(shù)據(jù)管理、安全評估、安全監(jiān)測管理、統(tǒng)計分析、爬蟲任務調(diào)度、病毒查殺引擎、靜態(tài)掃描引擎、代碼審計引擎、代碼分析引擎、動態(tài)監(jiān)控引擎等業(yè)務模塊以及系統(tǒng)對外提供的服務接口等。

（3）數(shù)據(jù)層：提供支持系統(tǒng)正常運行的各類數(shù)據(jù)庫，是連接展示層和服務層的關鍵節(jié)點，包括評估標準庫、專家?guī)?、應用庫、系統(tǒng)管理庫、開發(fā)者等。

3.3 移動應用安全評測體系的應用效果

根據(jù)研究成果和項目實現(xiàn)，從2013年起開始對某電信運營商的應用進行安全評測和風險修復。共計對近70款APP進行評測，發(fā)現(xiàn)近400個安全風險并進行修復和修復結果復核。通過移動應用的安全評測，可以提高APP的整體安全性，提高用戶對企業(yè)品牌信譽的信賴。

圖2 系統(tǒng)架構圖

圖3 系統(tǒng)功能圖

4 下一步研究方向

隨著在電信運營商內(nèi)部應用評測服務的推廣，APP評測的工作量在逐步增長，同時隨著對APP安全關注度的提升，目前對APP評估的研究開始增加，市場上出現(xiàn)更多的評測技術。需要跟進新技術的發(fā)展，提升評估體系的全面性。

研究安全評估自動化方面的技術，人工工作的自動化一直是難點，現(xiàn)有系統(tǒng)只能支撐少部分評估項的自動化，其余項仍需大量人工參與，因此需要研究相關的自動化評估技術方案,緩解人工壓力。