Android应用与系统安全防御
Android應(yīng)用安全防御
Android應(yīng)用的安全隱患包括代碼安全、數(shù)據(jù)安全、組件安全、WebView等幾個方面。
1. 代碼安全
代碼安全主要是指Android apk容易被反編譯，從而面臨軟件破解，內(nèi)購破解，軟件邏輯修改，插入惡意代碼，替換廣告商ID等風險。我們可以采用以下方法對apk進行保護：
1.1 代碼混淆
代碼混淆可以在一定程度上增加apk逆向分析的難度。Android SDK從2.3開始就加入了ProGuard代碼混淆功能，開發(fā)者只需進行簡單的配置就可以實現(xiàn)對代碼的混淆。
1.2 Apk簽名校驗
每一個軟件在發(fā)布時都需要開發(fā)人員對其進行簽名，而簽名使用的密鑰文件時開發(fā)人員所獨有的，破解者通常不可能擁有相同的密鑰文件，因此可以使用簽名校驗的方法保護apk。Android SDK中PackageManager類的getPackageInfo()方法就可以進行軟件簽名檢測。
1.3 Dex文件校驗
重編譯apk其實就是重編譯了classes.dex文件，重編譯后，生成的classes.dex文件的hash值就改變了，因此我們可以通過檢測安裝后classes.dex文件的hash值來判斷apk是否被重打包過。
（1）讀取應(yīng)用安裝目錄下/data/app/xxx.apk中的classes.dex文件并計算其哈希值，將該值與軟件發(fā)布時的classes.dex哈希值做比較來判斷客戶端是否被篡改。
（2）讀取應(yīng)用安裝目錄下/data/app/xxx.apk中的META-INF目錄下的MANIFEST.MF文件，該文件詳細記錄了apk包中所有文件的哈希值，因此可以讀取該文件獲取到classes.dex文件對應(yīng)的哈希值，將該值與軟件發(fā)布時的classes.dex哈希值做比較就可以判斷客戶端是否被篡改。
為了防止被破解，軟件發(fā)布時的classes.dex哈希值應(yīng)該存放在服務(wù)器端。
另外由于逆向c/c++代碼要比逆向Java代碼困難很多，所以關(guān)鍵代碼部位應(yīng)該使用Native C/C++來編寫。
1.4 逆向工具對抗
對apk進行重打包常用的工具是apktool，apktool對于后綴為PNG的文件，會按照PNG格式進行處理，如果我們將一個非PNG格式文件的文件后綴改為PNG，再使用apktool重打包則會報錯。
1.5 調(diào)試器檢測
為了防止apk被動態(tài)調(diào)試，可以檢測是否有調(diào)試器連接。在Application類中提供了isDebuggerConnected()方法用于檢測是否有調(diào)試器連接，如果發(fā)現(xiàn)有調(diào)試器連接，可以直接退出程序。
以上是使用比較多的幾種保護方法，單獨使用其中一種效果不大，應(yīng)該綜合運用。
1.6 加殼保護
使用加殼程序防止apk逆向是一種非常有效的方式，也是一個趨勢。Jack_Jia在《Android APK加殼技術(shù)方案》一文中詳細闡述了Android apk加殼原理以及幾種加殼方案的具體實現(xiàn)。我們可以利用這幾種方案對apk進行加殼。
不過這種加殼方式是在Java層實現(xiàn)的，被反編譯的風險仍然很大。為了克服這個缺點，今后可以研究采用如下思路來進行保護：
將核心業(yè)務(wù)邏輯代碼放入加密的.jar或者.apk文件中，在需要調(diào)用時使用Native C/C++代碼進行解密，同時完成對解密后文件的完整性校驗。如果需要更加安全的保護方法，可以考慮對so文件（Native C/C++代碼編譯得到的文件）進行加殼。Android so加殼主要需要解決兩個問題：
（1）對ELF文件加殼；
（2）對Android SO的加載、調(diào)用機制做特殊處理。
其實不管是Linux還是Windows，加殼的思路基本是一致的，簡單點無非加密+拆解+混淆，復(fù)雜點如Stolen Code + VM等。所以確定好一個加殼方案之后，剩下的就是了解elf的文件結(jié)構(gòu)和加載機制，然后自己寫一套殼+loader。
Android上的loader是/system/bin/linker，跟linux上的ld有一些區(qū)別。但主要過程還是一致的：map + relocate + init。
Android so主要充當?shù)慕巧峭ㄟ^JNI與java交互，所以主要是作為一個庫存在（也有一些so是可執(zhí)行的），然后被Android runtime加載，并能被java層調(diào)用。所以對elf加完殼之后，還要對Android so做一些特殊處理：
1. Android so被System.LoadLibrary()加載之后，會將so的信息存儲在一個全局鏈表里，所以要保證脫殼后的so能被這個鏈表訪問到。
2. Android so庫函數(shù)被java調(diào)用有兩種方式：一種是通過registerNative注冊，另一種是通過javah命名規(guī)則命名（參考http://blog.csdn.net/sno_guo/article/details/7688227）。所以一個通用的加殼方案要保證所有的庫函數(shù)都能被調(diào)用，前者好解決，后者需要花點功夫。
解決掉這兩個問題之后，基本上一套Android SO加殼框架就成形了，后續(xù)就可以增加各種Anti tricks來完善殼的強度。
參考文檔：http://www.colordancer.net/blog/2014/01/05/android-native-so%E5%8A%A0%E5%A3%B3%E6%8A%80%E6%9C%AF/
2. 數(shù)據(jù)安全
2.1 存儲安全問題
關(guān)于數(shù)據(jù)存儲可能出現(xiàn)的問題包括如下幾點：外部存儲（SD卡）上的文件沒有權(quán)限管理，所有應(yīng)用都可讀可寫。開發(fā)者把敏感信息明文存在 SD 卡上，或者動態(tài)加載的payload放在SD卡上。
（1）明文存儲敏感數(shù)據(jù)，導(dǎo)致直接被攻擊者復(fù)制或篡改。
- 將隱私數(shù)據(jù)、系統(tǒng)數(shù)據(jù)明文保存在外部存儲
- 將軟件運行時依賴的數(shù)據(jù)保存在外部存儲
- 將軟件安裝包或者二進制代碼保存在外部存儲
- 使用全局可讀寫（MODE_WORLD_READABLE，MODE_WORLD_WRITEABLE）的內(nèi)部存儲方式，或明文存儲敏感信息（用戶賬號密碼等）。
（2）不恰當存儲登陸憑證，導(dǎo)致攻擊者利用此數(shù)據(jù)竊取網(wǎng)絡(luò)賬戶隱私數(shù)據(jù)。
解決方案：
- 對這些數(shù)據(jù)進行加密，密碼保存在內(nèi)部存儲，由系統(tǒng)托管或者由用戶使用時輸入。
- 對應(yīng)用配置文件，較安全的方法是保存到內(nèi)部存儲；如果必須存儲到SD卡，則應(yīng)該在每次使用前檢驗它是否被篡改，與預(yù)先保存在內(nèi)部的文件哈希值進行比較。
- 應(yīng)用如果需要安裝或加載位于SD卡的任何文件，應(yīng)該先對其完整性做驗證，判斷其與實現(xiàn)保存在內(nèi)部存儲中的（或從服務(wù)器下載來的）哈希值是否一致。
- 如果要跨應(yīng)用進行數(shù)據(jù)共享，有種較好的方法是實現(xiàn)一個Content Provider 組件，提供數(shù)據(jù)的讀寫接口并為讀寫操作分別設(shè)置一個自定義的權(quán)限。
- 對于登錄憑證的存儲，使用基于憑據(jù)而不是密碼的協(xié)議滿足這種資源持久訪問的需求，例如OAuth。
Android數(shù)據(jù)存儲機制
| ?????? 存儲方式 | 描述 | 數(shù)據(jù)保密性 |
| Shared preferences | 用來存儲一些簡單配置信息的一種機制，使用Map數(shù)據(jù)結(jié)構(gòu)來存儲數(shù)據(jù)，以鍵值對的方式存儲，采用了XML格式將數(shù)據(jù)存儲到設(shè)備中。例如保存登錄用戶的用戶名和密碼。只能在創(chuàng)建它的應(yīng)用中使用，其他應(yīng)用無法使用。不能指定存儲文件的位置，創(chuàng)建的存儲文件保存在/data/data/<package ? name>/shares_prefs文件夾下。支持的存儲類型有：Boolean、Float、Integer、Long、String等 | 可以設(shè)置四種模式： MODE_PRIVATE（默認模式，文件只能讓創(chuàng)建的應(yīng)用程序訪問）、 MODE_WORLD_WRITEABLE、 MOED_WORLD_READABLE、 MODE_APPEND |
| 內(nèi)部存儲 | 在設(shè)備內(nèi)存中存儲數(shù)據(jù)。通常這些數(shù)據(jù)不允許被其它應(yīng)用甚至終端用戶訪問。即使重啟設(shè)備，這些數(shù)據(jù)仍然存在，不過當終端用戶卸載程序后，這些數(shù)據(jù)就會被刪除。 | 可以設(shè)置三種模式： MODE_PRIVATE（默認模式）、MODE_WORLD_READABLE、 MODE_WORLD_WRITABLE |
| 外部存儲 | 外部存儲（SD卡）的數(shù)據(jù)是全局可讀的。設(shè)備用戶和其它應(yīng)用都能讀取、修改、刪除這些數(shù)據(jù) | 數(shù)據(jù)默認是全局可讀的 |
| SQLite數(shù)據(jù)庫 | 如果需要使用數(shù)據(jù)庫的搜索和數(shù)據(jù)管理功能，則可以使用SQLite數(shù)據(jù)庫存儲機制 | 程序內(nèi)部可以任意訪問，外部程序不能訪問 |
| 網(wǎng)絡(luò)存儲 | 通過web服務(wù)器存儲和獲取數(shù)據(jù) | 基于web 服務(wù)器的設(shè)置 |
2.2 傳輸安全問題
? 不使用加密傳輸
最危險的是直接使用HTTP協(xié)議登錄賬戶或交換數(shù)據(jù)。例如，攻擊者在自己設(shè)置的釣魚網(wǎng)絡(luò)中配置DNS服務(wù)器，將軟件要連接的服務(wù)器域名解析至攻擊者的另一臺服務(wù)器在，這臺服務(wù)器就可以獲得用戶登錄信息，或者充當客戶端與原服務(wù)器的中間人，轉(zhuǎn)發(fā)雙方數(shù)據(jù)。
? 使用加密傳輸?shù)雎宰C書驗證環(huán)節(jié)
如開發(fā)者在代碼中不檢查服務(wù)器證書的有效性，或選擇接受所有的證書。例如，開發(fā)者可以自己實現(xiàn)一個X509TrustManager接口，將其中的CheckServerTrusted()方法實現(xiàn)為空，即不檢查服務(wù)器是否可信或者在SSLSoketFactory的實例中，通過setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIET)，接受所有證書。這可能是因為開發(fā)者使用了自己生成的證書，客戶端發(fā)現(xiàn)證書沒有和可信CA 形成信任鏈，出現(xiàn)了CertificateException等異常，從而不得不做出這種選擇。這種做法可能導(dǎo)致的問題是中間人攻擊。
我們在對敏感數(shù)據(jù)進行傳輸時應(yīng)該采用基于SSL/TLS的HTTPS進行傳輸。由于移動軟件大多只和固定的服務(wù)器通信，我們可以采用“證書鎖定”（certificate pinning）方式在代碼更精確地直接驗證服務(wù)器是否擁有某張?zhí)囟ǖ淖C書。實現(xiàn)“證書鎖定”的方法有二種：一種是實現(xiàn)X509TrustManager接口，另一種則是使用keystore。具體可以參考Android開發(fā)文檔中的HttpsURLConnection類的概述。
3. 組件安全
android應(yīng)用內(nèi)部的Activity、Service、Broadcast Receiver等組件是通過Intent通信的，組件間需要通信就需要在Androidmanifest.xml文件中配置，不恰當?shù)慕M件配置、組件在被調(diào)用時未做驗證、在調(diào)用其他組件時未做驗證都會帶來風險。
可能產(chǎn)生的風險包括：
（1）惡意調(diào)用
（2）惡意接受數(shù)據(jù)
（3）仿冒應(yīng)用，例如（惡意釣魚，啟動登錄界面）
（4）惡意發(fā)送廣播、啟動應(yīng)用服務(wù)。
（5）調(diào)用組件，接受組件返回的數(shù)據(jù)
（6）攔截有序廣播
比如：調(diào)用暴露的組件發(fā)短信、微博等。
解決辦法：?
?（1）最小化組件暴露
? 不參與跨應(yīng)用調(diào)用的組件添加android:exported="false"屬性，這個屬性說明它是私有的，只有同一個應(yīng)用程序的組件或帶有相同用戶ID的應(yīng)用程序才能啟動或綁定該服務(wù)。
? ? ??（2）設(shè)置組件訪問權(quán)限
? 對參與跨應(yīng)用調(diào)用的組件或者公開的廣播、服務(wù)設(shè)置權(quán)限。只有具有該權(quán)限的組件才能調(diào)用這個組件。
? ? （3）暴露組件的代碼檢查
? Android 提供各種API來在運行時檢查、執(zhí)行、授予和撤銷權(quán)限。這些API?是?android.content.Context?類的一部分，這個類提供有關(guān)應(yīng)用程序環(huán)境的全局信息。
4. WebView
存在的漏洞：
- 惡意App可以注入JavaScript代碼進入WebView中的網(wǎng)頁，網(wǎng)頁未作驗證。
- 惡意網(wǎng)頁可以執(zhí)行JavaScript反過來調(diào)用App中注冊過的方法，或者使用資源。
漏洞利用：
- 惡意程序嵌入Web App，然后竊取用戶信息。
- 惡意網(wǎng)頁遠程調(diào)用App代碼。更有甚者，通過Java Reflection調(diào)用Runtime執(zhí)行任意代碼。
解決方式：
1、如果無需與JS交互，請刪除對addJavascriptInterface函數(shù)的調(diào)用；
2、在載入頁面時對URL進行白名單判定，只有存在白名單中的域才允許導(dǎo)出或調(diào)用相關(guān)的Java類或方法。
參考資料：http://www.zhihu.com/question/22933619
5. SQL注入
使用字符串連接方式構(gòu)造SQL語句就會產(chǎn)生SQL注入。
解決方法：使用參數(shù)化查詢。
舉例：http://www.maxwithcoco.com/notes/mobile-sec/apk-drozer-contentprovider
5. 其他漏洞
ROOT后的手機可以修改App的內(nèi)購，或者安裝外掛App等。
Logcat泄露用戶敏感信息。
惡意的廣告包插件（可能存在后門、WebView漏洞等）
UXSS漏洞：
?????? UXSS漏洞可以繞過同源策略訪問存儲在Android應(yīng)用目錄/data/data/[應(yīng)用包名]/下的所有內(nèi)容。
如果產(chǎn)生該漏洞的是web瀏覽器，則攻擊者可以利用該漏洞竊取瀏覽器存儲的所有cookie信息以及其它信息。
測試代碼：
代碼地址：https://github.com/click1/uxss
在線測試地址：http://uxss.sinaapp.com/index.php
解決方法：
1、服務(wù)端禁止iframe嵌套X-FRAME-OPTIONS:DENY。詳見：http://drops.wooyun.org/papers/104
2、客戶端使用setAllowFileAccess(false)方法禁止webview訪問本地域。詳見：setAllowFileAccess(boolean)
3、客戶端使用onPageStarted (WebView view, String url, Bitmap favicon)方法在跳轉(zhuǎn)前進行跨域判斷。
4、客戶端對iframe object標簽屬性進行過濾。
詳情可參考：http://www.80vul.com/webzine_0x06/PSTZine_0x06_0x05.txt
Android系統(tǒng)安全防御
1.?操作系統(tǒng)安全問題
- Android?root問題
- 系統(tǒng)漏洞，補丁更新不及時
- 認證機制問題
2.?系統(tǒng)安全解決方案
2.1?權(quán)限管理與隔離
對運行在Android系統(tǒng)上的應(yīng)用程序進行權(quán)限的細粒度管理和隔離，防止越權(quán)行為的發(fā)生和濫用權(quán)限獲取敏感數(shù)據(jù)。
可以采用MAC（Mandatory?Access?Control）強制訪問控制模型實現(xiàn)。它是一個針對Linux的安全加強系統(tǒng)SELinux中使用的安全模型，即任何進程想在SELinux系統(tǒng)中干任何事情，都必須先在安全策略配置文件中賦予權(quán)限。凡是沒有出現(xiàn)在安全策略配置文件中的權(quán)限，進程就沒有該權(quán)限。Google在Android?4.4上正式推出了一套以SELinux為基礎(chǔ)的系統(tǒng)安全機制SEAndroid。所以如果我們要定制一個Android系統(tǒng)，可以采用具有SEAndroid安全機制的Android?4.4版本。
2.2?內(nèi)核與應(yīng)用層漏洞防護
增加補丁更新功能，如果發(fā)現(xiàn)漏洞，及時提醒用戶進行系統(tǒng)補丁更新。
2.3?惡意程序檢測與防護
建立一套惡意代碼防護模型，對運行在Android系統(tǒng)上的惡意程序進行檢測，抵御惡意代碼的入侵。
2.4?數(shù)據(jù)安全存儲與傳輸：
對Android系統(tǒng)上的數(shù)據(jù)存儲和數(shù)據(jù)傳輸進行加密保護，保證終端上數(shù)據(jù)能夠安全地使用。?
?
原文地址： http://www.cnblogs.com/goodhacker/p/3864680.html
總結(jié)
以上是生活随笔為你收集整理的Android应用与系统安全防御的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： “逃离大厦”游戏的破解
- 下一篇： android sina oauth2.