無意中發現一篇關于APP安全測試的文章，深以為然，原文搬至鄙人的部落格以做知識儲備，現附上原文連結，已示對大佬辛勤付出的緻敬和對知識産權的尊重。原文原始連結。
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、任意檔案上傳漏洞等等。