1 移動App安全風險分析
1.1 安全威脅分析
安全威脅從三個不同環節進行劃分，主要分為用戶端威脅、資料傳輸端威脅和服務端的威脅。
1.2 面臨的主要風險
1.3 Android測試思維導圖
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
---------------------
作者：凱賓斯基
來源：CNBLOGS
原文：https://www.cnblogs.com/kaibindirver/p/10240728.html
版權聲明：本文為作者原創文章，轉載請附上博文連結！
内容解析By：CSDN,CNBLOG部落格文章一鍵轉載插件