1 移動APP安全風險分析
1.1 安全威脅分析
安全威脅從三個不同環節進行划分，主要分為客戶端威脅、數據傳輸端威脅和服務端的威脅。
1.2 面臨的主要風險
1.4 反編譯工具
有兩種反編譯方式，dex2jar和apktool，兩個工具反編譯的效果是不一樣的，dex2jar反編譯出
java源代碼，apktool反編譯出來的是java匯編代碼。
dex2jar主要是用來把之前zip解壓出來的classed.dex轉成jar包的
jd-gui主要是用來打開Jar包的
2 本地客戶端安全
2.1 反編譯保護
2.1.1 問題描述
APP源代碼對於一個公司是非常重要的信息資源，對APP的保護也尤為重要，APP的反編譯會造成源代碼被惡意者讀取，以及APP的邏輯設計，
反編譯方法
我們一般想要反編譯一個apk，無非就是想獲得三樣東西：圖片資源、XML資源、代碼資源
一. 圖片資源獲取
首先准備一個apk，這里是一個.apk后綴的文件，我們先把后綴改成,zip，打開zip文件在res目錄下，我們就可以獲取到我們需要的圖片了。
二. XML資源獲取
我們可以在剛剛打開的zip文件目錄下看到很多.xml的文件，這個xml文件是無法直接打開的，當你嘗試着打開的時候都是亂碼或者是空白，那么我們要如何獲取到這個xml資源呢，這時候就需要借助一個jar包，就是它，axmlprinter2.jar，這個東西你只要
百度下，就能搜到。然后 你把他放跟你解壓出來的xml放在同級目錄下，用cmd命令找到這個目錄，
我這邊的示例是將xml放在了E盤，大家根據情況,cd到自己解壓出來的目錄下，然后執行
java -jar AXMLPrinter2.jar xxxxx.xml>xxxxx.txt
這個時候你就能獲取到xml里的東西啦
三. 代碼資源獲取
這個重中之重了，這也是我們主要想要獲取到的東西。但是存在一點，這里能夠正確反編譯出來的只有未加密或者沒有混淆的代碼，如果想要反編譯一些加密或者混淆后代碼，俺們就需要其他途徑解決了
首先要准備兩樣東西：dex2jar.rar和jd-gui.zip這兩個工具。
dex2jar主要是用來把之前zip解壓出來的classed.dex轉成jar包的
jd-gui主要是用來打開Jar包的
dex2jar用法：
把dex2jar 解壓后，然后將之前zip的classes.dex放到 dex2jar目錄下，
注意，必須要跟dex2jar.bat是同級目錄。
然后又要用到cmd，cd 到dex2jar目錄下，打命令行
dex2jar.bat classes.dex
然后你的目錄里會多一個jar包
多了一個 classes-dex2jar.jar的文件
然后在用jd-gui把jar包打開，最終apk的代碼就這樣被剝離出來了
2.1.2 檢測方法
通過反編譯工具看是否能夠對APP進行反編譯
2.1.3 修復方法
采用加密和混淆
技術達到反編譯保護。
混淆技術作用是增加了用戶反編譯后閱讀代碼的難度。
2.2 APP二次打包
2.2.1 二次打包描述
“Android APP二次打包”則是盜版正規Android APP，破解后植入惡意代碼重新打包。不管從性能、用戶體驗、外觀它都跟正規APP一模一樣但是背后它確悄悄運行着可怕的程序，它會在不知不覺中浪費
手機電量、流量，惡意扣費、偷窺隱私等等行為。
面對二次打包不少公司都有自己的防范措施，知名公司的APP幾乎都是自己在程序內部做過處理防止其APP被二次打包，一旦打包后重新運行則程序自動退出。接下來，我就來詳解一下如何防止APP被二次打包。
要實現代碼內部防止APP被二次打包首先得了解APK的機器識別原理，APK的唯一識別是依靠包名和簽名來做鑒定的，類似豌豆夾的洗白白、360手機衛士等安全軟件對APK的山寨識別，他們就是依賴包名來確定APK然后通過簽名來確定其是否山寨。所以說自己的程序內部在啟動的時候可以通過獲取APK本身的簽名然后和正確的簽名做對比來識別自己是否被二次打包。
2.2.2 防二次打包檢測方法
利用二次打包工具對APP進行二次打包，看APP能否成功打包運行，如果重新打包后無法運行程序說明有防二次打包安全措施。
2.2.3 防二次打包修復方法
采用簽名的方法進行保護：獲取二次打包后APK的簽名與正確的APK簽名做對比，判斷APK程序是否進行過二次打包。
建議：客戶端使用從屬方證書進行簽名后進行發布而不是使用第三方開發商的證書進行簽名，以防開發商內部監管異常，證書濫用的情況出現。
2.3 組件導出安全
2.3.1 四大組件描述
Android主要包含4大組件，分別是activity組件、service組件、content provider組件和broadcast receiver組件。
Activity組件
（1）一個Activity通常就是一個單獨的屏幕（窗口）。
（2）Activity之間通過Intent進行通信。
（3）android應用中每一個Activity都必須要在AndroidManifest.xml配置文件中聲明，否則系統將不識別也不執行該Activity。
Service組件
(1)service用於在后台完成用戶指定的操作。
(2)開發人員需要在應用程序AndroidManifest.xml配置文件中聲明全部的service，使用<service></service>標簽。
(3)Service通常位於后台運行，它一般不需要與用戶交互，因此Service組件沒有圖形用戶界面。Service組件需要繼承Service基類。Service組件通常用於為其他組件提供后台服務或監控其他組件的運行狀態。
Content Provider組件
（1）android平台提供了Content Provider使一個應用程序的指定數據集提供給其他應用程序。其他應用可以通過ContentResolver類從該內容提供者中獲取或存入數據。
（2）只有需要在多個應用程序間共享數據是才需要內容提供者。例如，通訊錄數據被多個應用程序使用，且必須存儲在一個內容提供者中。它的好處是統一數據訪問方式。
（3）ContentProvider實現數據共享。ContentProvider用於保存和獲取數據，並使其對所有應用程序可見。這是不同應用程序間共享數據的唯一方式，因為android沒有提供所有應用共同訪問的公共存儲區。
broadcast receiver
（1）你的應用可以使用它對外部事件進行過濾，只對感興趣的外部事件(如當
電話呼入時，或者數據網絡可用時)進行接收並做出響應。廣播接收器沒有用戶界面。然而，它們可以啟動一個activity或serice來響應它們收到的信息，或者用NotificationManager來通知用戶。通知可以用很多種方式來吸引用戶的注意力，例如閃動背燈、震動、播放聲音等。一般來說是在狀態欄上放一個持久的圖標，用戶可以打開它並獲取消息。
（2）廣播接收者的注冊有兩種方法，分別是程序動態注冊和AndroidManifest文件中進行靜態注冊。
（3）動態注冊廣播接收器特點是當用來注冊的Activity關掉后，廣播也就失效了。靜態注冊無需擔憂廣播接收器是否被關閉，只要設備是開啟狀態，廣播接收器也是打開着的。也就是說哪怕app本身未啟動，該app訂閱的廣播在觸發時也會對它起作用。
四大組件總結
（1）4大組件的注冊
4大基本組件都需要注冊才能使用，每個Activity、service、Content Provider都需要在AndroidManifest文件中進行配置。AndroidManifest文件中未進行聲明的activity、服務以及內容提供者將不為系統所見，從而也就不可用。而broadcast receiver廣播接收者的注冊分靜態注冊（在AndroidManifest文件中進行配置）和通過代碼動態創建並以調用Context.registerReceiver()的方式注冊至系統。需要注意的是在AndroidManifest文件中進行配置的廣播接收者會隨系統的啟動而一直處於活躍狀態，只要接收到感興趣的廣播就會觸發（即使程序未運行）。
（2）4大組件的激活
內容提供者的激活：當接收到ContentResolver發出的請求后，內容提供者被激活。而其它三種組件activity、服務和廣播接收器被一種叫做intent的異步消息所激活。
2.3.2 組件安全檢查方法
1、 AndroidManifest.xml文件中activity組件里面有設置android:exported為true，表示此組件可以被外部應用調用。
2、 AndroidManifest.xml文件中activity組件里面有設置android:exported為false，表示此組件不可以被外部應用調用。只有同一個應用的組件或者有着同樣user ID的應用可以
3、 AndroidManifest.xml文件中activity組件里面沒有設置android:exported屬性，但是有intent-filter，則exported默認屬性為true，true表示此組件可以被外部應用調用。
4、 AndroidManifest.xml文件中activity組件里面沒有設置android:exported屬性，也沒有設置intent-filter，則exported默認屬性為false，false表示此組件不可以被外部應用調用。只有同一個應用的組件或者有着同樣user ID的應用可以
備注：采用drozer工具可以進行檢測組件是否存在導出風險
2.3.3 修復建議
(1)如果應用的Service組件不必要導出，或者組件配置了intent filter標簽，建議顯示設置組件的“android:exported”屬性為false
(2)如果組件必須要提供給外部應用使用，建議對組件進行權限控制
2.4 Webview漏洞
2.4.1 WebView任意代碼執行漏洞
2.4.1.1 描述
出現該漏洞的原因有三個
WebView 中 addJavascriptInterface（） 接口
WebView 內置導出的 searchBoxJavaBridge_對象
WebView 內置導出的 accessibility 和 accessibilityTraversalObject 對象
addJavascriptInterface 接口引起遠程代碼執行漏洞
JS調用Android的其中一個方式是通過addJavascriptInterface接口進行對象映射, 當JS拿到Android這個對象后，就可以調用這個Android對象中所有的方法，包括系統類（java.lang.Runtime 類），從而進行任意代碼執行。
searchBoxJavaBridge_接口引起遠程代碼執行漏洞
在Android 3.0以下，Android系統會默認通過searchBoxJavaBridge_的Js接口給 WebView 添加一個JS映射對象：searchBoxJavaBridge_對象
該接口可能被利用，實現遠程任意代碼。
accessibility和 accessibilityTraversal接口引起遠程代碼執行漏洞
問題類似以上
2.4.1.2 檢測方法
addJavascriptInterface 接口引起遠程代碼執行漏洞
檢查是通過addJavascriptInterface接口進行對象映射
searchBoxJavaBridge_接口引起遠程代碼執行漏洞
檢查是否通過searchBoxJavaBridge_的Js接口給 WebView 添加一個JS映射對象
accessibility和 accessibilityTraversal接口引起遠程代碼執行漏洞
問題類似以上
2.4.1.3 修復建議
addJavascriptInterface 接口引起遠程代碼執行漏洞
B1. Android 4.2版本之后
Google 在Android 4.2 版本中規定對被調用的函數以 @JavascriptInterface進行注解從而避免漏洞×××
B2. Android 4.2版本之前
在Android 4.2版本之前采用攔截prompt（）進行漏洞修復。
searchBoxJavaBridge_接口引起遠程代碼執行漏洞
刪除searchBoxJavaBridge_接口
// 通過調用該方法刪除接口
removeJavascriptInterface（）；
accessibility和 accessibilityTraversal接口引起遠程代碼執行漏洞
刪除accessibility和 accessibilityTraversal接口
2.4.2 密碼明文存儲漏洞
2.4.2.1 描述
WebView默認開啟密碼保存功能：
mWebView.setSavePassword(true)
開啟后，在用戶輸入密碼時，會彈出提示框：詢問用戶是否保存密碼；
如果選擇”是”，密碼會被明文保到 /data/data/com.package.name/databases/webview.db 中，這樣就有被盜取密碼的危險
2.4.2.2 檢測方法
方法1、用戶輸入密碼時看是否有彈出提示框，詢問用戶是否保存密碼，如果有詢問則表示存在漏洞，否則不存在。
方法2、檢查代碼中setSavePassword的值是否為false。
2.4.2.3 修復建議
關閉密碼保存提醒
WebSettings.setSavePassword(false)
2.5 數據安全-本地敏感信息安全
2.5.1 APP所在目錄的文件權限
2.5.1.1 問題描述
測試客戶端APP所在目錄的文件權限是否設置正確，非root賬戶是否可以讀，寫，執行APP目錄下的文件。
來源 http://www.51testing.com/html/36/n-4456636.html