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目錄下的文件。
2.5.1.2 檢測方法
採用ls –l查看app目錄的文件權限，其它組成員不允許讀寫權限。Linux文件權限爲第一個爲文件所有者對此文件的權限，第二個爲所有者所在組的其它成員對此文件的權限，第三個爲其他組成員對此文件的權限。
2.5.1.3 修復建議
檢查App所在的目錄，其權限必須爲不允許其他組成員讀寫
2.5.2 SQLite數據庫文件的安全性
2.5.2.1 描述
SQLite，是一款輕型的數據庫，是遵守ACID的關係型數據庫管理系統.是開源的，高效率的，可嵌入且程序驅動的數據庫。
我們都知道，Android系統內置了SQLite數據庫，並且提供了一整套的API用於對數據庫進行增刪改查操作。數據庫存儲是我們經常會使用到的一種存儲方式，相信大多數朋友對它的使用方法都已經比較熟悉了吧。在Android中，我們既可以使用原生的SQL語句來對數據進行操作，也可以使用Android API提供的CRUD方法來對數據庫進行操作，兩種方式各有特點，選擇使用哪一種就全憑個人喜好了。
不過，使用SQLite來存儲數據卻存在着一個問題。因爲大多數的Android手機都是Root過的，而Root過的手機都可以進入到/data/data//databases目錄下面，在這裏就可以查看到數據庫中存儲的所有數據。如果是一般的數據還好，但是當涉及到一些賬號密碼，或者聊天內容的時候，我們的程序就會面臨嚴重的安全漏洞隱患。
2.5.2.2 檢測方法
手機進行root之後，查看/data/data//databases下的數據庫文件是否包含敏感信息。
2.5.2.3 修復建議
重要信息進行加密存儲
2.5.3 Logcat日誌
2.5.3.1 描述
檢測客戶端對應的Logcat日誌是否會打印一些用戶或服務器的敏感信息。
2.5.3.2 檢測方法
通過usb連接手機，然後使用adb logcat -v time > d:\xx的方式獲取logcat信息
或者使用DDMS工具查看logcat信息。
2.5.3.3 修復建議
具有敏感信息的調試信息開關一定要關閉。
對於安卓開發來講，我們解決敏感信息問題就是對重要數據進行加密存儲，log日誌不打印敏感信息。切記不要把賬號密碼等敏感信息保存在本地明文存儲，如果一定要存儲敏感信息務必進行加密存儲重要信息。
2.5.4 敏感數據明文存儲於Sdcard
2.5.4.1 描述
Android提供了幾種保存持久化應用數據的選擇，其中之一就是外部存儲（/sdcard, /mnt/sdcard）。外部存儲包括設備內部的微型或標準大小的SD卡，掛載到PC上的Android設備存儲卡以及Android/obb目錄。
Android4.1之前的版本，存放在外部存儲的文件是world-readable（能夠被任何用戶讀取的）和world-writable（能夠被任何用戶寫入）。從Android4.1到Android4.3，一個app想要寫入外部存儲的任意文件時，只需在AndroidManifest文件中聲明WRITE_EXTERNAL_STORAGE權限。但從Android4.4開始，引入了基於目錄結構創建分組和文件模式，這使得一個app在外部存儲中的只能在以自己包名命名的目錄下才具有文件的讀寫權限。非系統級的app只允許在Android/data/<package-name>/目錄下操作。因此，每個app的文件讀寫權限被獨立開來，不能互相訪問。
上面描述的訪問權限限制的不足，導致寫入到外部存儲的文件可能存在被同一設備上不同的app修改和讀取的風險（Android4.4之前版本）。
2.5.4.2 檢測方法
查看是否有代碼把內容寫入到外部存儲設備。
2.5.4.3 修復建議
在將文件保存到外部存儲之前，先對文件內容進行加密。
2.6 鍵盤安全風險
2.6.1 鍵盤劫持測試
2.6.1.1 描述
安卓應用中的輸入框默認使用系統軟鍵盤，手機安裝×××後，×××可以通過替換系統軟鍵盤，記錄應用的密碼。
2.6.1.2 檢測方法
通過觀察app在輸入密碼的地方是否會彈出自定義的軟鍵盤。
2.6.1.3 修復建議
建議客戶端開發自定義軟鍵盤而不是使用系統軟件盤以防止鍵盤劫持×××。
2.6.2 軟鍵盤安全性測試
2.6.2.1 描述
測試客戶端是否使用隨機佈局的密碼軟鍵盤。
2.6.2.2 檢測方法
用眼觀察每次彈出來的自定義的軟鍵盤是否隨機變化佈局
2.6.2.3 修復建議
建議客戶端對自定義軟鍵盤進行隨機化處理，同時在每次點擊輸入框時都進行隨機初始化。
2.7 屏幕錄像測試
2.7.1 描述
測試通過連續截圖，是否可以捕捉到用戶密碼輸入框的密碼。
2.7.2 檢測方法
通過連續截圖，是否可以捕捉到用戶密碼輸入框的密碼。
2.7.3 修復建議
建議客戶端針對第三方或系統截屏編寫抵抗邏輯，例如屏蔽和截屏相關的函數或是當客戶端處於進程棧頂層時將截屏圖片用純黑×××片對象進行覆蓋。
2.8 界面劫持保護
2.8.1 界面劫描述
Activity劫持是指當啓動某個窗口組件時，被惡意應用探知，若該窗口界面是惡意程序預設的×××對象，惡意應用將啓動自己仿冒的界面覆蓋原界面，用戶在毫無察覺的情況下輸入登錄信息，惡意程序在把獲取的數據返回給服務端。
需要理解，Android啓動一個Activity時，是這樣設計的，給Activity加入一個標誌位FLAG_ACTIVITY_NEW_TASK，就能使它置於棧頂並立馬呈現給用戶。但是這樣的設計卻有一個缺陷。如果這個Activity是用於盜號的僞裝Activity呢？這種現象在XcodeGhost事件中，已經被證實是可以實現的。
在Android系統當中，程序可以枚舉當前運行的進程而不需要聲明其他權限，這樣的話，就可以編寫一個程序，啓動一個後臺的服務，這個服務不斷地掃描當前運行的進程，當發現目標進程啓動時，就啓動一個僞裝的Activity。如果這個Activity是登錄界面，那麼就可以從中獲取用戶的賬號密碼，具體的過程如下圖：
2.8.2 界面劫持防護方法
作爲一名移動應用開發者，要防禦APP被界面劫持，最簡單的方法是在登錄窗口等關鍵Activity的onPause方法中檢測最前端Activity應用是不是自身或者是系統應用。如果檢測到不是自己，則彈出告警或者退出。
2.8.3 界面劫持案例
應用存在釣魚劫持風險。應用程序沒有做防釣魚劫持措施，通過劫持應用程序的登錄界面，可以獲取用戶的賬號和密碼，可能導致用戶賬號信息的泄露。
2.8.4 整改建議
應用程序自身通過獲取棧頂activity，判斷系統當前運行的程序，一旦發現應用切換（可能被劫持），給予用戶提示以防範釣魚程序的欺詐。
獲取棧頂activity（如下圖），當涉及敏感activity（登錄、交易等）切換時，判斷當前是否仍留在原程序，若不是則通過Toast給予用戶提示。
使用HTML5架構或android+HTML5混合開發，實現登陸、支付等關鍵頁面，降低被劫持的風險。
2.9 本地拒絕服務
2.9.1 漏洞描述
Android系統提供了Activity、Service和Broadcast Receiver等組件，並提供了Intent機制來協助應用間的交互與通訊，Intent負責對應用中一次操作的動作、動作涉及數據、附加數據進行描述，Android系統則根據此Intent的描述，負責找到對應的組件，將Intent傳遞給調用的組件，並完成組件的調用[1]。Android應用本地拒絕服務漏洞源於程序沒有對Intent.getXXXExtra()獲取的異常或者畸形數據處理時沒有進行異常捕獲，從而導致×××者可通過向受害者應用發送此類空數據、異常或者畸形數據來達到使該應用crash的目的，簡單的說就是×××者通過intent發送空數據、異常或畸形數據給受害者應用，導致其崩潰。
本地拒絕服務漏洞影響範圍：Android系統所有版本
2.9.2 漏洞檢測方法
使用Android掃描工具可以進行掃描。
2.9.3 修復建議
本地拒絕服務漏洞修復建議：
1) 將不必要的導出的組件設置爲不導出
出於安全考慮，應將不必要的組件導出，防止引起拒絕服務，尤其是殺毒、安全防護、鎖屏防盜等安全應用; 在AndroidMenifest.xml文件中，將相應組件的“android:exported”屬性設置爲“false”,如下示例：<android:exported="false">
2) intent處理數據時進行捕獲異常
建議處理通過Intent.getXXXExtra()獲取的數據時進行以下判斷，以及用try catch方式進行捕獲所有異常，以防止應用出現拒絕服務漏洞：
1) 空指針異常;
2) 類型轉換異常;
3) 數組越界訪問異常;
4) 類未定義異常;
5) 其他異常;
2.10 數據備份allowBackup
2.10.1 漏洞描述
Android API Level 8 及其以上 Android 系統提供了爲應用程序數據的備份和恢復功能，此功能的開關決定於該應用程序中 AndroidManifest.xml 文件中的 allowBackup 屬性值，其屬性值默認是 True。當 allowBackup 標誌爲 true 時，用戶即可通過 adb backup 和 adb restore 來進行對應用數據的備份和恢復，這可能會帶來一定的安全風險。
Android 屬性 allowBackup 安全風險源於 adb backup 容許任何一個能夠打開 USB 調試開關的人從Android 手機中複製應用數據到外設，一旦應用數據被備份之後，所有應用數據都可被用戶讀取；adb restore 容許用戶指定一個恢復的數據來源（即備份的應用數據）來恢復應用程序數據的創建。因此，當一個應用數據被備份之後，用戶即可在其他 Android 手機或模擬器上安裝同一個應用，以及通過恢復該備份的應用數據到該設備上，在該設備上打開該應用即可恢復到被備份的應用程序的狀態。
尤其是通訊錄應用，一旦應用程序支持備份和恢復功能，×××者即可通過 adb backup 和 adb restore 進行恢復新安裝的同一個應用來查看聊天記錄等信息；對於支付金融類應用，×××者可通過此來進行惡意支付、盜取存款等；因此爲了安全起見，開發者務必將 allowBackup 標誌值設置爲 false 來關閉應用程序的備份和恢復功能，以免造成信息泄露和財產損失。
1、不在 AndroidManifest.xml 文件設置 allowBackup 屬性值，其默認值爲 true，則應用可通過 adb 命令進行備份整個應用的數據
AndroidManifest.xml文件內容：
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.alibaba.jaq.allowbackuppoc" android:versionCode="1" android:versionName="1.0"> <uses-sdk android:minSdkVersion="10"/> <uses-permission android:name="android.permission.READ_PHONE_STATE" /> <application android:label="@string/app_name"> <activity android:name="LoginActivity" android:label="@string/app_name"> <intent-filter> <action android:name="android.intent.action.MAIN"/> <category android:name="android.intent.category.LAUNCHER"/> </intent-filter> </activity> <activity android:name=".HomeActivity"/> </application> </manifest> |
2、在 AndroidManifest.xml 文件顯示設置 allowBackup 屬性值爲 false，即android:allowBackup="false"，則 Android 應用不可通過 adb 命令進行備份和恢復整個應用的數據
AndroidManifest.xml文件內容：
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.alibaba.jaq.allowbackuppoc" android:versionCode="1" android:versionName="1.0"> <uses-sdk android:minSdkVersion="10"/> <uses-permission android:name="android.permission.READ_PHONE_STATE" /> <application android:allowBackup="false" android:label="@string/app_name"> <activity android:name="LoginActivity" android:label="@string/app_name"> <intent-filter> <action android:name="android.intent.action.MAIN"/> <category android:name="android.intent.category.LAUNCHER"/> </intent-filter> </activity> <activity android:name=".HomeActivity"/> </application> </manifest> |
2.10.2 檢測方法
查看AndroidManifest.xml文件中是否有allowBackup，如果沒有則allowBackup屬性值，默認allowBackup值爲True，則默認爲可以備份應用數據，存在安全風險；如果allowBackup屬性值爲false，則不可以備份應用數據。
2.10.3 修復方法
把AndroidManifest.xml文件中allowBackup屬性值設置爲false。
2.11 Debug調試
2.11.1 描述
在準備發佈應用之前要確保關閉debug屬性，即設置AndroidMainifest.xml中android:debuggable="false"，false表示關閉debug調試功能，true表示開啓debug調試功能，但是有時候會忘記關掉這個屬性。Debug調試開啓會存在應用被調試的風險。
2.11.2 檢測方法
在發佈之前最好進行測試，使用aapt工具：
aapt list -v -a myfile.apk
這個命令將會打印和apk相關的所有詳細信息，找到“android:debuggable"，它的值分爲：
0x0: debuggable false
0xffffffff: debugabble true
例如，在我的測試中，這一行的信息是：
A: android ebuggable(0x0101000f)=(type 0x12)0x0
這說明我的Release Build已經關閉了debuggable！
2.11.3 修復建議
把debuggable關閉
android:debuggable=false
3 通信過程安全
3.1 通信保密性
3.1.1 採用HTTPS通信
3.1.1.1 描述
驗證客戶端和服務器之前的通信是否使用https加密信道，採用https協議通信可以防止信息在傳輸過程被竊聽的風險。。
3.1.1.2 檢測方法
通過抓包工具（例如burpsuite、fiddler）抓取通信信息，看是否進行加密通信。
3.1.1.3 修復建議
使用https進行加密通信。
3.1.2 SSL劫持×××——證書校驗
3.1.2.1 描述
目前雖然很多Android APP使用了https通信方式，但是隻是簡單的調用而已，並未對SSL證書有效性做驗證，https通信只是對通信信道進行了加密，可以防止監聽數據的風險，但是無法防止中間人×××方式，通過中間人攔截代理方式可以讓採用https通信的數據暴露無遺，這樣×××者就可以利用中間人攔截代理來做劫持×××，這種漏洞讓https形同虛設，可以輕易獲取手機用戶的明文通信信息。
證書校驗是爲了防止中間人劫持×××，分爲強校驗和弱校驗。強校驗就是在手段端先預埋好服務端的證書，當手機端與服務端通信時獲取證書，並且與手機本地預埋的服務端證書做對比，一旦不一致，則認爲遭到了中間人劫持×××，自動斷開與服務端的通信。弱校驗則是在手機端校驗證書的域名和手機真實訪問的域名是否一致、證書頒發機構等信息。
強校驗流程圖：
弱校驗流程圖：
方案對比
方案 | 優點 | 缺點 |
強校驗：服務器證書鎖定 | 安全性最高，實施×××必須拿到對應服務器私鑰證書。 | 更換證書時APP影響大 |
弱校驗：根證書鎖定+域名驗證 | 更換服務器證書不受影響 | 安全性和CA機構以及域名驗證機制有關。 |
3.1.2.2 檢測方法
通過抓包看手機端程序是否運行正常，如果通過代理方式抓包，手機APP自動強制退出，說明手機APP有做證書校驗。
3.1.2.3 整改方法
採用強校驗或者弱校驗方法。
3.2 訪問控制
3.2.1 描述
測試客戶端訪問的URL是否僅能由手機客戶端訪問。是否可以繞過登錄限制直接訪問登錄後才能訪問的頁面，對需要二次驗證的頁面（如私密問題驗證），能否繞過驗證。
3.2.2 檢測方法
利用截包工具獲取url，能用瀏覽器打開該url。
3.2.3 修復建議
建議服務器進行相應的訪問控制，控制對應頁面僅能通過手機客戶端訪問。同時進行頁面訪問控制，防止繞過登陸直接訪問頁面的非法訪問。
4 服務端安全
4.1 安全策略設置
4.1.1 密碼複雜度策略
4.1.1.1 描述
測試客戶端程序是否檢查用戶輸入的密碼，禁止用戶設置弱口令
4.1.1.2 檢測方法
修改設置用戶名密碼時，可以設置111111類似弱口令
4.1.1.3 修復建議
建議在服務器編寫檢測密碼複雜度的安全策略，並將其運用到賬號註冊，密碼修改等需要進行密碼變更的場景，以防止×××者通過弱密鑰遍歷賬戶的方式進行暴力猜解。
4.1.2 認證失敗鎖定策略
4.1.2.1 描述
測試客戶端是否限制登錄嘗試次數。防止×××使用窮舉法暴力破解用戶密碼
4.1.2.2 檢測方法
錯誤密碼登錄請求多次（10次以上還沒有就有問題了，一般都是3次）
4.1.2.3 修復建議
建議在服務端編寫賬戶鎖定策略的邏輯，當一天內多次輸入密碼錯誤時進行賬號鎖定以防止×××者通過暴力猜解密碼。
4.1.3 單點登錄限制策略
4.1.3.1 描述
測試能否在兩個設備上同時登錄同一個帳號。
4.1.3.2 檢測方法
測試能否在兩個設備上同時登錄同一個帳號。
4.1.3.3 修復建議
建議在服務器進行賬號登陸限制相應邏輯代碼的編寫，通過Session或數據庫標誌位的方式控制同一時間只有一個設備可以登陸某一賬號。
4.1.4 會話超時策略
4.1.4.1 描述
測試客戶端在一定時間內無操作後，是否會使會話超時並要求重新登錄。超時時間設置是否合理。
4.1.4.2 檢測
客戶端在一定時間內無操作（20分鐘足夠），是否會話超時登錄
4.1.4.3 建議
建議在客戶端編寫會話安全設置的邏輯，當10分鐘或20分鐘無操作時自動退出登錄狀態或是關閉客戶端。
4.1.5 界面切換保護
4.1.5.1 描述
檢查客戶端程序在切換到後臺或其他應用時，是否能恰當響應（如清除表單或退出會話），防止用戶敏感信息泄露
4.1.5.2 檢測方法
應用切換到後臺但程序沒有結束運行，再返回應用的時候是否有身份驗證 ，手勢密碼或者登陸密碼。
4.1.5.3 修復建議
建議客戶端添加響應的邏輯，在進行進程切換操作時提示用戶確認是否爲本人操作。
4.1.6 UI敏感信息安全
4.1.6.1 描述
檢查客戶端的各種功能，看是否存在敏感信息泄露問題。
4.1.6.2 檢測方法
比如登錄時，密碼輸入錯誤，APP是否會提示密碼輸入錯誤
4.1.6.3 修復建議
建議用戶名或密碼輸入錯誤均提示“用戶名或密碼錯誤”，若客戶端同時還希望保證客戶使用的友好性，可以在登陸界面通過溫馨提示的方式提示輸入錯誤次數，密碼安全策略等信息，以防用戶多次輸入密碼錯誤導致賬號鎖定。
4.1.7 安全退出
4.1.7.1 描述
驗證客戶端在用戶退出登錄狀態時是否會和服務器進行通信以保證退出的及時性
4.1.7.2 檢測方法
客戶端在用戶退出登錄時，查看session是否可用
4.1.7.3 修復建議
保證客戶端和服務器同步退出，APP退出時服務器端的清除會話
4.1.8 密碼修改驗證
4.1.8.1 描述
驗證客戶端在進行密碼修改時的安全性
4.1.8.2 檢測方法
是否存在原密碼驗證
4.1.8.3 修復建議
建議在修改密碼時，客戶端及服務器系統增添原密碼輸入驗證身份的邏輯，以防Cookie登陸修改密碼的×××。
4.1.9 手勢密碼
4.1.9.1 手勢密碼修改和取消
4.1.9.1.1 描述
檢測客戶端在取消手勢密碼時是否會驗證之前設置的手勢密碼，檢測是否存在其他導致手勢密碼取消的邏輯問題
4.1.9.1.2 檢測方法
檢測客戶端在取消手勢密碼時是否會驗證之前設置的手勢密碼，檢測是否存在其他導致手勢密碼取消的邏輯問題
4.1.9.1.3 修復建議
不應該存在其他導致手勢密碼取消的邏輯，客戶端在取消手勢密碼時應驗證之前設置的手勢密碼
4.1.9.2 手勢密碼本地信息保存
4.1.9.2.1 描述
檢測在輸入手勢密碼以後客戶端是否會在本地記錄一些相關信息，例如明文或加密過的手勢密碼。
4.1.9.2.2 檢測方法
找到存儲文件，看其是否加密
4.1.9.2.3 修復建議
應該進行加密
4.1.9.3 手勢密碼鎖定策略
4.1.9.3.1 描述
測試客戶端是否存在手勢密碼多次輸入錯誤被鎖定的安全策略。防止×××使用窮舉法暴力破解用戶密碼。因爲手勢密碼的存儲容量非常小，一共只有9！=362880種不同手勢，若手勢密碼不存在鎖定策略，×××可以輕易跑出手勢密碼結果。手勢密碼在輸入時通常以a[2][2]這種3*3的二維數組方式保存，在進行客戶端同服務器的數據交互時通常將此二維數組中數字轉化爲類似手機數字鍵盤的b[8]這種一維形式，之後進行一系列的處理進行發送
4.1.9.3.2 檢測方法
嘗試多次輸入手勢密碼錯誤，例如連續輸入3次或者5次密碼錯誤，看是否會鎖定賬號。
4.1.9.3.3 修復方法
手勢密碼策略建議連續輸入3次或者5次進行鎖定。
4.2 任意賬號註冊
4.2.1 描述
使用任意賬號可以進行註冊，造成非實名制註冊風險，惡意註冊者可以註冊大量賬號。大量賬號可以用於薅羊毛等惡意操作。
4.2.2 檢測方法
使用手機號139****1234註冊某個APP，獲取驗證碼060503，在確認提交時，攔截請求，修改註冊的手機號碼，即可註冊任意賬號，這裏修改爲136****5678（任意手機號）；即可使用136****5678（任意手機號）登錄，均可以通過驗證登錄。
4.2.3 修復建議
註冊過程最後的確認提交時，服務器應驗證提交的賬號是否是下發驗證碼的手機號。
4.3 短信重放×××
4.3.1 描述
檢測應用中是否存在數據包重放×××的安全問題。是否會對客戶端用戶造成短信轟炸的困擾。
4.3.2 檢測方法
利用burpsuite抓包，然後進行重放操作。
4.3.3 修復建議
token和手機號一起，重放無法造成短信轟炸，另外就是限制每個手機號每天只能發送短信次數，例如10次。每個ip每分鐘只能發送3次。
4.4 短信驗證碼
4.4.1 描述
短信驗證碼對於防止暴力破解是一種有效的手段，但是如果驗證碼沒有使用有效，則會導致其無法發揮防暴力破解的效果。
4.4.2 檢測方法
檢測短信驗證碼是否可以多次重複使用。一般驗證碼使用一次及失效。
檢測短信驗證碼的有效期，一般驗證碼5分鐘內有效即可。
4.4.3 修復建議
設置短信驗證碼使用一次即失效，並且每個短信驗證碼在5分鐘內有效。
4.5 業務邏輯漏洞
此處主要是一些越權漏洞。
4.6 服務端其他漏洞
此處和web端漏洞類似，例如SQL注入、XSS、任意文件上傳漏洞等等。