Android應(yīng)用與系統(tǒng)安全防御

來源：荊州網(wǎng)站建設(shè) 時(shí)間：2017-06-07

Android應(yīng)用的安全隱患包括代碼安全、數(shù)據(jù)安全、組件安全、WebView等幾個(gè)方面。

1. 代碼安全

代碼安全主要是指Android apk容易被反編譯，從而面臨軟件破解，內(nèi)購破解，軟件邏輯修改，插入惡意代碼，替換廣告商ID等風(fēng)險(xiǎn)。我們可以采用以下方法對(duì)apk進(jìn)行保護(hù)：

1.1 代碼混淆

　　代碼混淆可以在一定程度上增加apk逆向分析的難度。Android SDK從2.3開始就加入了ProGuard代碼混淆功能，開發(fā)者只需進(jìn)行簡(jiǎn)單的配置就可以實(shí)現(xiàn)對(duì)代碼的混淆。

1.2 Apk簽名校驗(yàn)

　　每一個(gè)軟件在發(fā)布時(shí)都需要開發(fā)人員對(duì)其進(jìn)行簽名，而簽名使用的密鑰文件時(shí)開發(fā)人員所獨(dú)有的，破解者通常不可能擁有相同的密鑰文件，因此可以使用簽名校驗(yàn)的方法保護(hù)apk。Android SDK中PackageManager類的getPackageInfo()方法就可以進(jìn)行軟件簽名檢測(cè)。

1.3 Dex文件校驗(yàn)

　　重編譯apk其實(shí)就是重編譯了classes.dex文件，重編譯后，生成的classes.dex文件的hash值就改變了，因此我們可以通過檢測(cè)安裝后classes.dex文件的hash值來判斷apk是否被重打包過。

　　（1）讀取應(yīng)用安裝目錄下/data/app/xxx.apk中的classes.dex文件并計(jì)算其哈希值，將該值與軟件發(fā)布時(shí)的classes.dex哈希值做比較來判斷客戶端是否被篡改。

　?。?）讀取應(yīng)用安裝目錄下/data/app/xxx.apk中的META-INF目錄下的MANIFEST.MF文件，該文件詳細(xì)記錄了apk包中所有文件的哈希值，因此可以讀取該文件獲取到classes.dex文件對(duì)應(yīng)的哈希值，將該值與軟件發(fā)布時(shí)的classes.dex哈希值做比較就可以判斷客戶端是否被篡改。

　　為了防止被破解，軟件發(fā)布時(shí)的classes.dex哈希值應(yīng)該存放在服務(wù)器端。

　　另外由于逆向c/c++代碼要比逆向Java代碼困難很多，所以關(guān)鍵代碼部位應(yīng)該使用Native C/C++來編寫。

1.4 逆向工具對(duì)抗

　　對(duì)apk進(jìn)行重打包常用的工具是apktool，apktool對(duì)于后綴為PNG的文件，會(huì)按照PNG格式進(jìn)行處理，如果我們將一個(gè)非PNG格式文件的文件后綴改為PNG，再使用apktool重打包則會(huì)報(bào)錯(cuò)。

1.5 調(diào)試器檢測(cè)

　　為了防止apk被動(dòng)態(tài)調(diào)試，可以檢測(cè)是否有調(diào)試器連接。在Application類中提供了isDebuggerConnected()方法用于檢測(cè)是否有調(diào)試器連接，如果發(fā)現(xiàn)有調(diào)試器連接，可以直接退出程序。

　　以上是使用比較多的幾種保護(hù)方法，單獨(dú)使用其中一種效果不大，應(yīng)該綜合運(yùn)用。

1.6 加殼保護(hù)

　　使用加殼程序防止apk逆向是一種非常有效的方式，也是一個(gè)趨勢(shì)。Jack_Jia在《Android APK加殼技術(shù)方案》一文中詳細(xì)闡述了Android apk加殼原理以及幾種加殼方案的具體實(shí)現(xiàn)。我們可以利用這幾種方案對(duì)apk進(jìn)行加殼。

　　不過這種加殼方式是在Java層實(shí)現(xiàn)的，被反編譯的風(fēng)險(xiǎn)仍然很大。為了克服這個(gè)缺點(diǎn)，今后可以研究采用如下思路來進(jìn)行保護(hù)：

　　將核心業(yè)務(wù)邏輯代碼放入加密的.jar或者.apk文件中，在需要調(diào)用時(shí)使用Native C/C++代碼進(jìn)行解密，同時(shí)完成對(duì)解密后文件的完整性校驗(yàn)。如果需要更加安全的保護(hù)方法，可以考慮對(duì)so文件（Native C/C++代碼編譯得到的文件）進(jìn)行加殼。Android so加殼主要需要解決兩個(gè)問題：

　?。?）對(duì)ELF文件加殼；

　?。?）對(duì)Android SO的加載、調(diào)用機(jī)制做特殊處理。

　　其實(shí)不管是Linux還是Windows，加殼的思路基本是一致的，簡(jiǎn)單點(diǎn)無非加密+拆解+混淆，復(fù)雜點(diǎn)如Stolen Code + VM等。所以確定好一個(gè)加殼方案之后，剩下的就是了解elf的文件結(jié)構(gòu)和加載機(jī)制，然后自己寫一套殼+loader。

　　Android上的loader是/system/bin/linker，跟linux上的ld有一些區(qū)別。但主要過程還是一致的：map + relocate + init。

　　Android so主要充當(dāng)?shù)慕巧峭ㄟ^JNI與java交互，所以主要是作為一個(gè)庫存在（也有一些so是可執(zhí)行的），然后被Android runtime加載，并能被java層調(diào)用。所以對(duì)elf加完殼之后，還要對(duì)Android so做一些特殊處理：

　　1. Android so被System.LoadLibrary()加載之后，會(huì)將so的信息存儲(chǔ)在一個(gè)全局鏈表里，所以要保證脫殼后的so能被這個(gè)鏈表訪問到。

　　2. Android so庫函數(shù)被java調(diào)用有兩種方式：一種是通過registerNative注冊(cè)，另一種是通過javah命名規(guī)則命名（參考http://blog.csdn.net/sno_guo/article/details/7688227）。所以一個(gè)通用的加殼方案要保證所有的庫函數(shù)都能被調(diào)用，前者好解決，后者需要花點(diǎn)功夫。

　　解決掉這兩個(gè)問題之后，基本上一套Android SO加殼框架就成形了，后續(xù)就可以增加各種Anti tricks來完善殼的強(qiáng)度。

2. 數(shù)據(jù)安全

2.1 存儲(chǔ)安全問題

　　關(guān)于數(shù)據(jù)存儲(chǔ)可能出現(xiàn)的問題包括如下幾點(diǎn)：外部存儲(chǔ)（SD卡）上的文件沒有權(quán)限管理，所有應(yīng)用都可讀可寫。開發(fā)者把敏感信息明文存在 SD 卡上，或者動(dòng)態(tài)加載的payload放在SD卡上。

（1）明文存儲(chǔ)敏感數(shù)據(jù)，導(dǎo)致直接被攻擊者復(fù)制或篡改。

• 將隱私數(shù)據(jù)、系統(tǒng)數(shù)據(jù)明文保存在外部存儲(chǔ)

• 將軟件運(yùn)行時(shí)依賴的數(shù)據(jù)保存在外部存儲(chǔ)

• 將軟件安裝包或者二進(jìn)制代碼保存在外部存儲(chǔ)

• 使用全局可讀寫（MODE_WORLD_READABLE，MODE_WORLD_WRITEABLE）的內(nèi)部存儲(chǔ)方式，或明文存儲(chǔ)敏感信息（用戶賬號(hào)密碼等）。

（2）不恰當(dāng)存儲(chǔ)登陸憑證，導(dǎo)致攻擊者利用此數(shù)據(jù)竊取網(wǎng)絡(luò)賬戶隱私數(shù)據(jù)。

　　解決方案：

• 對(duì)這些數(shù)據(jù)進(jìn)行加密，密碼保存在內(nèi)部存儲(chǔ)，由系統(tǒng)托管或者由用戶使用時(shí)輸入。

• 對(duì)應(yīng)用配置文件，較安全的方法是保存到內(nèi)部存儲(chǔ)；如果必須存儲(chǔ)到SD卡，則應(yīng)該在每次使用前檢驗(yàn)它是否被篡改，與預(yù)先保存在內(nèi)部的文件哈希值進(jìn)行比較。

• 應(yīng)用如果需要安裝或加載位于SD卡的任何文件，應(yīng)該先對(duì)其完整性做驗(yàn)證，判斷其與實(shí)現(xiàn)保存在內(nèi)部存儲(chǔ)中的（或從服務(wù)器下載來的）哈希值是否一致。

• 如果要跨應(yīng)用進(jìn)行數(shù)據(jù)共享，有種較好的方法是實(shí)現(xiàn)一個(gè)Content Provider 組件，提供數(shù)據(jù)的讀寫接口并為讀寫操作分別設(shè)置一個(gè)自定義的權(quán)限。

• 對(duì)于登錄憑證的存儲(chǔ)，使用基于憑據(jù)而不是密碼的協(xié)議滿足這種資源持久訪問的需求，例如OAuth。

Android數(shù)據(jù)存儲(chǔ)機(jī)制

2.2 傳輸安全問題

　　? 不使用加密傳輸

　　最危險(xiǎn)的是直接使用HTTP協(xié)議登錄賬戶或交換數(shù)據(jù)。例如，攻擊者在自己設(shè)置的釣魚網(wǎng)絡(luò)中配置DNS服務(wù)器，將軟件要連接的服務(wù)器域名解析至攻擊者的另一臺(tái)服務(wù)器在，這臺(tái)服務(wù)器就可以獲得用戶登錄信息，或者充當(dāng)客戶端與原服務(wù)器的中間人，轉(zhuǎn)發(fā)雙方數(shù)據(jù)。

　　? 使用加密傳輸?shù)雎宰C書驗(yàn)證環(huán)節(jié)

　　如開發(fā)者在代碼中不檢查服務(wù)器證書的有效性，或選擇接受所有的證書。例如，開發(fā)者可以自己實(shí)現(xiàn)一個(gè)X509TrustManager接口，將其中的CheckServerTrusted()方法實(shí)現(xiàn)為空，即不檢查服務(wù)器是否可信或者在SSLSoketFactory的實(shí)例中，通過setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIET)，接受所有證書。這可能是因?yàn)殚_發(fā)者使用了自己生成的證書，客戶端發(fā)現(xiàn)證書沒有和可信CA 形成信任鏈，出現(xiàn)了CertificateException等異常，從而不得不做出這種選擇。這種做法可能導(dǎo)致的問題是中間人攻擊。

　　我們?cè)趯?duì)敏感數(shù)據(jù)進(jìn)行傳輸時(shí)應(yīng)該采用基于SSL/TLS的HTTPS進(jìn)行傳輸。由于移動(dòng)軟件大多只和固定的服務(wù)器通信，我們可以采用“證書鎖定”（certificate pinning）方式在代碼更精確地直接驗(yàn)證服務(wù)器是否擁有某張?zhí)囟ǖ淖C書。實(shí)現(xiàn)“證書鎖定”的方法有二種：一種是實(shí)現(xiàn)X509TrustManager接口，另一種則是使用keystore。具體可以參考Android開發(fā)文檔中的HttpsURLConnection類的概述。

3. 組件安全

　　android應(yīng)用內(nèi)部的Activity、Service、Broadcast Receiver等組件是通過Intent通信的，組件間需要通信就需要在Androidmanifest.xml文件中配置，不恰當(dāng)?shù)慕M件配置、組件在被調(diào)用時(shí)未做驗(yàn)證、在調(diào)用其他組件時(shí)未做驗(yàn)證都會(huì)帶來風(fēng)險(xiǎn)。

　　可能產(chǎn)生的風(fēng)險(xiǎn)包括：

　　（1）惡意調(diào)用

　?。?）惡意接受數(shù)據(jù)

　　（3）仿冒應(yīng)用，例如（惡意釣魚，啟動(dòng)登錄界面）

　?。?）惡意發(fā)送廣播、啟動(dòng)應(yīng)用服務(wù)。

　?。?）調(diào)用組件，接受組件返回的數(shù)據(jù)

　?。?）攔截有序廣播

　　比如：調(diào)用暴露的組件發(fā)短信、微博等。

　　解決辦法：

　　 （1）最小化組件暴露

　　不參與跨應(yīng)用調(diào)用的組件添加android:exported="false"屬性，這個(gè)屬性說明它是私有的，只有同一個(gè)應(yīng)用程序的組件或帶有相同用戶ID的應(yīng)用程序才能啟動(dòng)或綁定該服務(wù)。

     （2）設(shè)置組件訪問權(quán)限

　　對(duì)參與跨應(yīng)用調(diào)用的組件或者公開的廣播、服務(wù)設(shè)置權(quán)限。只有具有該權(quán)限的組件才能調(diào)用這個(gè)組件。

　  （3）暴露組件的代碼檢查

　　Android 提供各種API來在運(yùn)行時(shí)檢查、執(zhí)行、授予和撤銷權(quán)限。這些API 是 android.content.Context 類的一部分，這個(gè)類提供有關(guān)應(yīng)用程序環(huán)境的全局信息。

4. WebView

　　存在的漏洞：

• 惡意App可以注入JavaScript代碼進(jìn)入WebView中的網(wǎng)頁，網(wǎng)頁未作驗(yàn)證。

• 惡意網(wǎng)頁可以執(zhí)行JavaScript反過來調(diào)用App中注冊(cè)過的方法，或者使用資源。

　　漏洞利用：

• 惡意程序嵌入Web App，然后竊取用戶信息。

• 惡意網(wǎng)頁遠(yuǎn)程調(diào)用App代碼。更有甚者，通過Java Reflection調(diào)用Runtime執(zhí)行任意代碼。

　　解決方式：

　　1、如果無需與JS交互，請(qǐng)刪除對(duì)addJavascriptInterface函數(shù)的調(diào)用；

　　2、在載入頁面時(shí)對(duì)URL進(jìn)行白名單判定，只有存在白名單中的域才允許導(dǎo)出或調(diào)用相關(guān)的Java類或方法。

　　參考資料：http://www.zhihu.com/question/22933619

5. SQL注入

　　使用字符串連接方式構(gòu)造SQL語句就會(huì)產(chǎn)生SQL注入。

　　解決方法：使用參數(shù)化查詢。

5. 其他漏洞

　　ROOT后的手機(jī)可以修改App的內(nèi)購，或者安裝外掛App等。

　　Logcat泄露用戶敏感信息?！　?/span>

　　惡意的廣告包插件（可能存在后門、WebView漏洞等）

　　UXSS漏洞：

     　　UXSS漏洞可以繞過同源策略訪問存儲(chǔ)在Android應(yīng)用目錄/data/data/[應(yīng)用包名]/下的所有內(nèi)容。

　　　　如果產(chǎn)生該漏洞的是web瀏覽器，則攻擊者可以利用該漏洞竊取瀏覽器存儲(chǔ)的所有cookie信息以及其它信息。

　　　　測(cè)試代碼：

　　　　代碼地址：https://github.com/click1/uxss

　　　　在線測(cè)試地址：http://uxss.sinaapp.com/index.php

　　　　解決方法：

　　　　1、服務(wù)端禁止iframe嵌套X-FRAME-OPTIONS:DENY。

　　　　2、客戶端使用setAllowFileAccess(false)方法禁止webview訪問本地域。

　　　　3、客戶端使用onPageStarted (WebView view, String url, Bitmap favicon)方法在跳轉(zhuǎn)前進(jìn)行跨域判斷。

　　　　4、客戶端對(duì)iframe object標(biāo)簽屬性進(jìn)行過濾。

Android系統(tǒng)安全防御

1. 操作系統(tǒng)安全問題

• Android root問題

• 系統(tǒng)漏洞，補(bǔ)丁更新不及時(shí)

• 認(rèn)證機(jī)制問題

2. 系統(tǒng)安全解決方案

2.1 權(quán)限管理與隔離

　　對(duì)運(yùn)行在Android系統(tǒng)上的應(yīng)用程序進(jìn)行權(quán)限的細(xì)粒度管理和隔離，防止越權(quán)行為的發(fā)生和濫用權(quán)限獲取敏感數(shù)據(jù)。

　　可以采用MAC（Mandatory Access Control）強(qiáng)制訪問控制模型實(shí)現(xiàn)。它是一個(gè)針對(duì)Linux的安全加強(qiáng)系統(tǒng)SELinux中使用的安全模型，即任何進(jìn)程想在SELinux系統(tǒng)中干任何事情，都必須先在安全策略配置文件中賦予權(quán)限。凡是沒有出現(xiàn)在安全策略配置文件中的權(quán)限，進(jìn)程就沒有該權(quán)限。Google在Android 4.4上正式推出了一套以SELinux為基礎(chǔ)的系統(tǒng)安全機(jī)制SEAndroid。所以如果我們要定制一個(gè)Android系統(tǒng)，可以采用具有SEAndroid安全機(jī)制的Android 4.4版本。

2.2 內(nèi)核與應(yīng)用層漏洞防護(hù)

　　增加補(bǔ)丁更新功能，如果發(fā)現(xiàn)漏洞，及時(shí)提醒用戶進(jìn)行系統(tǒng)補(bǔ)丁更新。

2.3 惡意程序檢測(cè)與防護(hù)

　　建立一套惡意代碼防護(hù)模型，對(duì)運(yùn)行在Android系統(tǒng)上的惡意程序進(jìn)行檢測(cè)，抵御惡意代碼的入侵。

2.4 數(shù)據(jù)安全存儲(chǔ)與傳輸：

　　對(duì)Android系統(tǒng)上的數(shù)據(jù)存儲(chǔ)和數(shù)據(jù)傳輸進(jìn)行加密保護(hù)，保證終端上數(shù)據(jù)能夠安全地使用。

以上內(nèi)容由湖北國菱計(jì)算機(jī)科技有限公司荊州網(wǎng)站建設(shè)荊州軟件開發(fā)組轉(zhuǎn)載自:http://www.cnblogs.com/goodhacker/p/3864680.html