APP安全

時間 2019-11-16

標籤 app 安全欄目系統安全简体版

原文原文鏈接

2.1 反編譯保護

2.1.1 問題描述

APP源代碼對於一個公司是很是重要的信息資源，對APP的保護也尤其重要，APP的反編譯會形成源代碼被惡意者讀取，以及APP的邏輯設計，前端

反編譯方法

咱們通常想要反編譯一個apk，無非就是想得到三樣東西：圖片資源、XML資源、代碼資源java

一. 圖片資源獲取android

首先準備一個apk，這裏是一個.apk後綴的文件，咱們先把後綴改爲,zip，打開zip文件在res目錄下，咱們就能夠獲取到咱們須要的圖片了。web

二. 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 組件安全檢查方法

一、 AndroidManifest.xml文件中activity組件裏面有設置android:exported爲true，表示此組件能夠被外部應用調用。

二、 AndroidManifest.xml文件中activity組件裏面有設置android:exported爲false，表示此組件不能夠被外部應用調用。只有同一個應用的組件或者有着一樣user ID的應用能夠

三、 AndroidManifest.xml文件中activity組件裏面沒有設置android:exported屬性，可是有intent-filter，則exported默認屬性爲true，true表示此組件能夠被外部應用調用。

四、 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 檢測方法

方法一、用戶輸入密碼時看是否有彈出提示框，詢問用戶是否保存密碼，若是有詢問則表示存在漏洞，不然不存在。

方法二、檢查代碼中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 來關閉應用程序的備份和恢復功能，以避免形成信息泄露和財產損失。

一、不在 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>

</intent-filter>

</activity>

</application>

</manifest>

二、在 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>

</intent-filter>

</activity>

</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]這種一維形式，以後進行一系列的處理進行發送