Android應用的安全隱患＊

轉自： http://www.cnblogs.com/chi0591/p/3864747.html

Android應用的安全隱患包括三個方面：

• 代碼安全
• 數據安全
• 組件安全

代碼安全

　　代碼安全主要是指Android apk有被篡改、盜版等風險，產生代碼安全的主要緣由是apk很容易被反編譯、重打包。咱們能夠採用如下方法對apk進行保護：

1.代碼混淆

　　代碼混淆能夠在必定程度上增長apk逆向分析的難度。Android SDK從2.3開始就加入了ProGuard代碼混淆功能，開發者只需進行簡單的配置就能夠實現對代碼的混淆。

2.Apk簽名校驗

　　每個軟件在發佈時都須要開發人員對其進行簽名，而簽名使用的密鑰文件時開發人員所獨有的，破解者一般不可能擁有相同的密鑰文件，所以可使用簽名校驗的方法保護apk。Android SDK中PackageManager類的getPackageInfo()方法就能夠進行軟件簽名檢測。

3.Dex文件校驗

　　重編譯apk其實就是重編譯了classes.dex文件，重編譯後，生成的classes.dex文件的hash值就改變了，所以咱們能夠經過檢測安裝後classes.dex文件的hash值來判斷apk是否被重打包過。

　　（1）讀取應用安裝目錄下/data/app/xxx.apk中的classes.dex文件並計算其哈希值，將該值與軟件發佈時的classes.dex哈希值作比較來判斷客戶端是否被篡改。

　　（2）讀取應用安裝目錄下/data/app/xxx.apk中的META-INF目錄下的MANIFEST.MF文件，該文件詳細記錄了apk包中全部文件的哈希值，所以能夠讀取該文件獲取到classes.dex文件對應的哈希值，將該值與軟件發佈時的classes.dex哈希值作比較就能夠判斷客戶端是否被篡改。

　　爲了防止被破解，軟件發佈時的classes.dex哈希值應該存放在服務器端。

　　另外因爲逆向c/c++代碼要比逆向Java代碼困難不少，因此關鍵代碼部位應該使用Native C/C++來編寫。

4.逆向工具對抗

　　對apk進行重打包經常使用的工具是apktool，apktool對於後綴爲PNG的文件，會按照PNG格式進行處理，若是咱們將一個非PNG格式文件的文件後綴改成PNG，再使用apktool重打包則會報錯。

　　以上是使用比較多的幾種保護方法，單獨使用其中一種效果不大，應該綜合運用。

5.調試器檢測

　　爲了防止apk被動態調試，能夠檢測是否有調試器鏈接。在Application類中提供了isDebuggerConnected()方法用於檢測是否有調試器鏈接，若是發現有調試器鏈接，能夠直接退出程序。

6.加殼保護

　　使用加殼程序防止apk逆向是一種很是有效的方式，也是一個趨勢。Jack_Jia在《Android APK加殼技術方案》一文中詳細闡述了Android apk加殼原理以及幾種加殼方案的具體實現。咱們能夠利用這幾種方案對apk進行加殼。

　　不過這種加殼方式是在Java層實現的，被反編譯的風險仍然很大。爲了克服這個缺點，從此能夠研究採用以下思路來進行保護：

　　將核心業務邏輯代碼放入加密的.jar或者.apk文件中，在須要調用時使用Native C/C++代碼進行解密，同時完成對解密後文件的完整性校驗。若是須要更加安全的保護方法，能夠考慮對so文件（Native C/C++代碼編譯獲得的文件）進行加殼。Android so加殼主要須要解決兩個問題：

• 對ELF文件加殼；
• 對Android SO的加載、調用機制作特殊處理。

　　這將是之後Android應用安全研究的一個方向。

數據安全

7.存儲安全問題

關於數據存儲可能出現的問題包括以下幾點：

（1）明文存儲敏感數據，致使直接被攻擊者複製或篡改。

• 將隱私數據明文保存在外部存儲
• 將系統數據明文保存在外部存儲
• 將軟件運行時依賴的數據保存在外部存儲
• 將軟件安裝包或者二進制代碼保存在外部存儲
• 全局可讀寫的內部文件存儲

（2）不恰當存儲登錄憑證，致使攻擊者利用此數據竊取網絡帳戶隱私數據。

解決方案：

• 對這些數據進行加密，密碼保存在內部存儲，由系統託管或者由用戶使用時輸入。
• 對應用配置文件，較安全的方法是保存到內部存儲；若是必須存儲到SD卡，則應該在每次使用前檢驗它是否被篡改，與預先保存在內部的文件哈希值進行比較。
• 應用若是須要安裝或加載位於SD卡的任何文件，應該先對其完整性作驗證，判斷其與實現保存在內部存儲中的（或從服務器下載來的）哈希值是否一致。
• 若是要跨應用進行數據共享，有種較好的方法是實現一個Content Provider 組件，提供數據的讀寫接口併爲讀寫操做分別設置一個自定義的權限。
• 對於登陸憑證的存儲，使用基於憑據而不是密碼的協議知足這種資源持久訪問的需求，例如OAuth。

8.傳輸安全問題

• 不使用加密傳輸

• 使用加密傳輸但忽略證書驗證環節

　　如開發者在代碼中不檢查服務器證書的有效性，或選擇接受全部的證書時，這種作法可能會致使中間人攻擊。

　　咱們在對敏感數據進行傳輸時應該採用基於SSL/TLS的HTTPS進行傳輸。因爲移動軟件大多隻和固定的服務器通訊，咱們能夠採用「證書鎖定」（certificate pinning）方式在代碼更精確地直接驗證服務器是否擁有某張特定的證書。

組件安全

　　android應用內部的Activity、Service、Broadcast Receiver等組件是經過Intent通訊的，組件間須要通訊就須要在Androidmanifest.xml文件中配置，不恰當的組件配置則會帶來風險。

9.可能產生的風險

• 惡意調用
• 惡意接受數據
• 仿冒應用，例如（惡意釣魚，啓動登陸界面）
• 惡意發送廣播、啓動應用服務。
• 調用組件，接受組件返回的數據
• 攔截有序廣播

10.解決辦法

• 最小化組件暴露

 不參與跨應用調用的組件添加android:exported="false"屬性，這個屬性說明它是私有的，只有同一個應用程序的組件或帶有相同用戶ID的應用程序才能啓動或綁定該服務。

• 設置組件訪問權限

 對參與跨應用調用的組件或者公開的廣播、服務設置權限。只有具備該權限的組件才能調用這個組件。

• 暴露組件的代碼檢查

　　Android 提供各類API來在運行時檢查、執行、授予和撤銷權限。這些 API 是 android.content.Context 類的一部分，這個類提供有關應用程序環境的全局信息。

　　另外，Android應用也會存在不少傳統web漏洞，好比SQL注入，xss漏洞等，代碼級防止出現這些漏洞的方法與web應用防護方法相同。

Android系統安全防護

11.操做系統安全問題

• Android root問題
• 系統漏洞，補丁更新不及時
• 認證機制問題

12.系統安全解決方案

12.1 權限管理與隔離

　　對運行在Android系統上的應用程序進行權限的細粒度管理和隔離，防止越權行爲的發生和濫用權限獲取敏感數據。

　　能夠採用MAC（Mandatory Access Control）強制訪問控制模型實現。它是一個針對Linux的安全增強系統SELinux中使用的安全模型，即任何進程想在SELinux系統中幹任何事情，都必須先在安全策略配置文件中賦予權限。凡是沒有出如今安全策略配置文件中的權限，進程就沒有該權限。Google在Android 4.4上正式推出了一套以SELinux爲基礎的系統安全機制SEAndroid。因此若是咱們要定製一個Android系統，能夠採用具備SEAndroid安全機制的Android 4.4版本。

12.2 內核與應用層漏洞防禦

　　增長補丁更新功能，若是發現漏洞，及時提醒用戶進行系統補丁更新。

12.3 惡意程序檢測與防禦

　　創建一套惡意代碼防禦模型，對運行在Android系統上的惡意程序進行檢測，抵禦惡意代碼的入侵。

12.4 數據安全存儲與傳輸

　　對Android系統上的數據存儲和數據傳輸進行加密保護，保證終端上數據可以安全地使用。