移動APP安全測試

1        移動APP安全風險分析

1.1     安全威脅分析

安全威脅從三個不同環(huán)節(jié)進行劃分，主要分為客戶端威脅、數(shù)據(jù)傳輸端威脅和服務端的威脅。

在山南等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務理念，為客戶提供做網(wǎng)站、網(wǎng)站制作 網(wǎng)站設計制作按需策劃設計,公司網(wǎng)站建設,企業(yè)網(wǎng)站建設,品牌網(wǎng)站制作,成都全網(wǎng)營銷,成都外貿(mào)網(wǎng)站建設,山南網(wǎng)站建設費用合理。

移動APP安全測試

1.2     面臨的主要風險

移動APP安全測試

1.3     Android測試思維導圖

 

移動APP安全測試

1.4     反編譯工具

有兩種反編譯方式，dex2jar和apktool，兩個工具反編譯的效果是不一樣的，dex2jar反編譯出java源代碼，apktool反編譯出來的是java匯編代碼。

dex2jar主要是用來把之前zip解壓出來的classed.dex轉(zhuǎn)成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盤，大家根據(jù)情況,cd到自己解壓出來的目錄下，然后執(zhí)行

java  -jar AXMLPrinter2.jar xxxxx.xml>xxxxx.txt

這個時候你就能獲取到xml里的東西啦

三.代碼資源獲取

這個重中之重了，這也是我們主要想要獲取到的東西。但是存在一點，這里能夠正確反編譯出來的只有未加密或者沒有混淆的代碼，如果想要反編譯一些加密或者混淆后代碼，俺們就需要其他途徑解決了

 

首先要準備兩樣東西：dex2jar.rar和jd-gui.zip這兩個工具。

dex2jar主要是用來把之前zip解壓出來的classed.dex轉(zhuǎn)成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   檢測方法

通過反編譯工具看是否能夠?qū)PP進行反編譯

2.1.3   修復方法

采用加密和混淆技術達到反編譯保護。

混淆技術作用是增加了用戶反編譯后閱讀代碼的難度。

2.2     APP二次打包

2.2.1   二次打包描述

“Android APP二次打包”則是盜版正規(guī)Android APP，破解后植入惡意代碼重新打包。不管從性能、用戶體驗、外觀它都跟正規(guī)APP一模一樣但是背后它確悄悄運行著可怕的程序，它會在不知不覺中浪費手機電量、流量，惡意扣費、偷窺隱私等等行為。

      面對二次打包不少公司都有自己的防范措施，知名公司的APP幾乎都是自己在程序內(nèi)部做過處理防止其APP被二次打包，一旦打包后重新運行則程序自動退出。接下來，我就來詳解一下如何防止APP被二次打包。

      要實現(xiàn)代碼內(nèi)部防止APP被二次打包首先得了解APK的機器識別原理，APK的唯一識別是依靠包名和簽名來做鑒定的，類似豌豆夾的洗白白、360手機衛(wèi)士等安全軟件對APK的山寨識別，他們就是依賴包名來確定APK然后通過簽名來確定其是否山寨。所以說自己的程序內(nèi)部在啟動的時候可以通過獲取APK本身的簽名然后和正確的簽名做對比來識別自己是否被二次打包。

2.2.2   防二次打包檢測方法

利用二次打包工具對APP進行二次打包，看APP能否成功打包運行，如果重新打包后無法運行程序說明有防二次打包安全措施。

2.2.3   防二次打包修復方法

采用簽名的方法進行保護：獲取二次打包后APK的簽名與正確的APK簽名做對比，判斷APK程序是否進行過二次打包。

建議：客戶端使用從屬方證書進行簽名后進行發(fā)布而不是使用第三方開發(fā)商的證書進行簽名，以防開發(fā)商內(nèi)部監(jiān)管異常，證書濫用的情況出現(xiàn)。

2.3     組件導出安全

2.3.1   四大組件描述

Android主要包含4大組件，分別是activity組件、service組件、content provider組件和broadcast receiver組件。

?   Activity組件

（1）一個Activity通常就是一個單獨的屏幕（窗口）。

（2）Activity之間通過Intent進行通信。

（3）android應用中每一個Activity都必須要在AndroidManifest.xml配置文件中聲明，否則系統(tǒng)將不識別也不執(zhí)行該Activity。

 

?   Service組件

(1)service用于在后臺完成用戶指定的操作。

(2)開發(fā)人員需要在應用程序AndroidManifest.xml配置文件中聲明全部的service，使用<service></service>標簽。

(3)Service通常位于后臺運行，它一般不需要與用戶交互，因此Service組件沒有圖形用戶界面。Service組件需要繼承Service基類。Service組件通常用于為其他組件提供后臺服務或監(jiān)控其他組件的運行狀態(tài)。

 

?   Content  Provider組件

（1）android平臺提供了Content  Provider使一個應用程序的指定數(shù)據(jù)集提供給其他應用程序。其他應用可以通過ContentResolver類從該內(nèi)容提供者中獲取或存入數(shù)據(jù)。

（2）只有需要在多個應用程序間共享數(shù)據(jù)是才需要內(nèi)容提供者。例如，通訊錄數(shù)據(jù)被多個應用程序使用，且必須存儲在一個內(nèi)容提供者中。它的好處是統(tǒng)一數(shù)據(jù)訪問方式。

（3）ContentProvider實現(xiàn)數(shù)據(jù)共享。ContentProvider用于保存和獲取數(shù)據(jù)，并使其對所有應用程序可見。這是不同應用程序間共享數(shù)據(jù)的唯一方式，因為android沒有提供所有應用共同訪問的公共存儲區(qū)。

 

?   broadcast  receiver

（1）你的應用可以使用它對外部事件進行過濾，只對感興趣的外部事件(如當電話呼入時，或者數(shù)據(jù)網(wǎng)絡可用時)進行接收并做出響應。廣播接收器沒有用戶界面。然而，它們可以啟動一個activity或serice來響應它們收到的信息，或者用NotificationManager來通知用戶。通知可以用很多種方式來吸引用戶的注意力，例如閃動背燈、震動、播放聲音等。一般來說是在狀態(tài)欄上放一個持久的圖標，用戶可以打開它并獲取消息。

（2）廣播接收者的注冊有兩種方法，分別是程序動態(tài)注冊和AndroidManifest文件中進行靜態(tài)注冊。

（3）動態(tài)注冊廣播接收器特點是當用來注冊的Activity關掉后，廣播也就失效了。靜態(tài)注冊無需擔憂廣播接收器是否被關閉，只要設備是開啟狀態(tài)，廣播接收器也是打開著的。也就是說哪怕app本身未啟動，該app訂閱的廣播在觸發(fā)時也會對它起作用。

 

?   四大組件總結(jié)

（1）4大組件的注冊

4大基本組件都需要注冊才能使用，每個Activity、service、Content Provider都需要在AndroidManifest文件中進行配置。AndroidManifest文件中未進行聲明的activity、服務以及內(nèi)容提供者將不為系統(tǒng)所見，從而也就不可用。而broadcast  receiver廣播接收者的注冊分靜態(tài)注冊（在AndroidManifest文件中進行配置）和通過代碼動態(tài)創(chuàng)建并以調(diào)用Context.registerReceiver()的方式注冊至系統(tǒng)。需要注意的是在AndroidManifest文件中進行配置的廣播接收者會隨系統(tǒng)的啟動而一直處于活躍狀態(tài)，只要接收到感興趣的廣播就會觸發(fā)（即使程序未運行）。

（2）4大組件的激活

內(nèi)容提供者的激活：當接收到ContentResolver發(fā)出的請求后，內(nèi)容提供者被激活。而其它三種組件activity、服務和廣播接收器被一種叫做intent的異步消息所激活。

2.3.2   組件安全檢查方法

1、AndroidManifest.xml文件中activity組件里面有設置android:exported為true，表示此組件可以被外部應用調(diào)用。

2、AndroidManifest.xml文件中activity組件里面有設置android:exported為false，表示此組件不可以被外部應用調(diào)用。只有同一個應用的組件或者有著同樣user ID的應用可以

3、AndroidManifest.xml文件中activity組件里面沒有設置android:exported屬性，但是有intent-filter，則exported默認屬性為true，true表示此組件可以被外部應用調(diào)用。

4、AndroidManifest.xml文件中activity組件里面沒有設置android:exported屬性，也沒有設置intent-filter，則exported默認屬性為false，false表示此組件不可以被外部應用調(diào)用。只有同一個應用的組件或者有著同樣user ID的應用可以

 

備注：采用drozer工具可以進行檢測組件是否存在導出風險

2.3.3   修復建議

(1)如果應用的Service組件不必要導出，或者組件配置了intent  filter標簽，建議顯示設置組件的“android:exported”屬性為false

(2)如果組件必須要提供給外部應用使用，建議對組件進行權限控制

2.4     Webview漏洞

2.4.1   WebView任意代碼執(zhí)行漏洞

2.4.1.1 描述

?   出現(xiàn)該漏洞的原因有三個

WebView  中 addJavascriptInterface（） 接口

WebView  內(nèi)置導出的 searchBoxJavaBridge_對象

WebView  內(nèi)置導出的 accessibility 和 accessibilityTraversalObject  對象

 

?   addJavascriptInterface  接口引起遠程代碼執(zhí)行漏洞

JS調(diào)用Android的其中一個方式是通過addJavascriptInterface接口進行對象映射, 當JS拿到Android這個對象后，就可以調(diào)用這個Android對象中所有的方法，包括系統(tǒng)類（java.lang.Runtime  類），從而進行任意代碼執(zhí)行。

 

?   searchBoxJavaBridge_接口引起遠程代碼執(zhí)行漏洞

在Android 3.0以下，Android系統(tǒng)會默認通過searchBoxJavaBridge_的Js接口給 WebView 添加一個JS映射對象：searchBoxJavaBridge_對象

該接口可能被利用，實現(xiàn)遠程任意代碼。

 

?   accessibility和 accessibilityTraversal接口引起遠程代碼執(zhí)行漏洞

問題類似以上

2.4.1.2 檢測方法

?   addJavascriptInterface  接口引起遠程代碼執(zhí)行漏洞

檢查是通過addJavascriptInterface接口進行對象映射

 

?   searchBoxJavaBridge_接口引起遠程代碼執(zhí)行漏洞

檢查是否通過searchBoxJavaBridge_的Js接口給 WebView 添加一個JS映射對象

 

?   accessibility和 accessibilityTraversal接口引起遠程代碼執(zhí)行漏洞

問題類似以上

2.4.1.3 修復建議

?   addJavascriptInterface  接口引起遠程代碼執(zhí)行漏洞

B1.  Android 4.2版本之后

Google  在Android 4.2 版本中規(guī)定對被調(diào)用的函數(shù)以  @JavascriptInterface進行注解從而避免漏洞×××

 

B2.  Android 4.2版本之前

在Android 4.2版本之前采用攔截prompt（）進行漏洞修復。

 

?   searchBoxJavaBridge_接口引起遠程代碼執(zhí)行漏洞

刪除searchBoxJavaBridge_接口

//  通過調(diào)用該方法刪除接口

removeJavascriptInterface（）；

 

?   accessibility和 accessibilityTraversal接口引起遠程代碼執(zhí)行漏洞

刪除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     數(shù)據(jù)安全-本地敏感信息安全

2.5.1   APP所在目錄的文件權限

2.5.1.1 問題描述

測試客戶端APP所在目錄的文件權限是否設置正確，非root賬戶是否可以讀，寫，執(zhí)行APP目錄下的文件。 

2.5.1.2檢測方法

采用ls –l查看app目錄的文件權限，其它組成員不允許讀寫權限。Linux文件權限為第一個為文件所有者對此文件的權限，第二個為所有者所在組的其它成員對此文件的權限，第三個為其他組成員對此文件的權限。

2.5.1.3 修復建議

檢查App所在的目錄，其權限必須為不允許其他組成員讀寫

2.5.2   SQLite數(shù)據(jù)庫文件的安全性

2.5.2.1 描述

SQLite，是一款輕型的數(shù)據(jù)庫，是遵守ACID的關系型數(shù)據(jù)庫管理系統(tǒng).是開源的，高效率的，可嵌入且程序驅(qū)動的數(shù)據(jù)庫。

我們都知道，Android系統(tǒng)內(nèi)置了SQLite數(shù)據(jù)庫，并且提供了一整套的API用于對數(shù)據(jù)庫進行增刪改查操作。數(shù)據(jù)庫存儲是我們經(jīng)常會使用到的一種存儲方式，相信大多數(shù)朋友對它的使用方法都已經(jīng)比較熟悉了吧。在Android中，我們既可以使用原生的SQL語句來對數(shù)據(jù)進行操作，也可以使用Android API提供的CRUD方法來對數(shù)據(jù)庫進行操作，兩種方式各有特點，選擇使用哪一種就全憑個人喜好了。

不過，使用SQLite來存儲數(shù)據(jù)卻存在著一個問題。因為大多數(shù)的Android手機都是Root過的，而Root過的手機都可以進入到/data/data//databases目錄下面，在這里就可以查看到數(shù)據(jù)庫中存儲的所有數(shù)據(jù)。如果是一般的數(shù)據(jù)還好，但是當涉及到一些賬號密碼，或者聊天內(nèi)容的時候，我們的程序就會面臨嚴重的安全漏洞隱患。

2.5.2.2 檢測方法

手機進行root之后，查看/data/data//databases下的數(shù)據(jù)庫文件是否包含敏感信息。

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 修復建議

具有敏感信息的調(diào)試信息開關一定要關閉。

對于安卓開發(fā)來講，我們解決敏感信息問題就是對重要數(shù)據(jù)進行加密存儲，log日志不打印敏感信息。切記不要把賬號密碼等敏感信息保存在本地明文存儲，如果一定要存儲敏感信息務必進行加密存儲重要信息。

2.5.4   敏感數(shù)據(jù)明文存儲于Sdcard

2.5.4.1 描述

Android提供了幾種保存持久化應用數(shù)據(jù)的選擇，其中之一就是外部存儲（/sdcard, /mnt/sdcard）。外部存儲包括設備內(nèi)部的微型或標準大小的SD卡，掛載到PC上的Android設備存儲卡以及Android/obb目錄。

Android4.1之前的版本，存放在外部存儲的文件是world-readable（能夠被任何用戶讀取的）和world-writable（能夠被任何用戶寫入）。從Android4.1到Android4.3，一個app想要寫入外部存儲的任意文件時，只需在AndroidManifest文件中聲明WRITE_EXTERNAL_STORAGE權限。但從Android4.4開始，引入了基于目錄結(jié)構(gòu)創(chuàng)建分組和文件模式，這使得一個app在外部存儲中的只能在以自己包名命名的目錄下才具有文件的讀寫權限。非系統(tǒng)級的app只允許在Android/data/<package-name>/目錄下操作。因此，每個app的文件讀寫權限被獨立開來，不能互相訪問。

上面描述的訪問權限限制的不足，導致寫入到外部存儲的文件可能存在被同一設備上不同的app修改和讀取的風險（Android4.4之前版本）。

2.5.4.2 檢測方法

查看是否有代碼把內(nèi)容寫入到外部存儲設備。

2.5.4.3 修復建議

在將文件保存到外部存儲之前，先對文件內(nèi)容進行加密。

2.6     鍵盤安全風險

2.6.1   鍵盤劫持測試

2.6.1.1 描述

安卓應用中的輸入框默認使用系統(tǒng)軟鍵盤，手機安裝×××后，×××可以通過替換系統(tǒng)軟鍵盤，記錄應用的密碼。 

2.6.1.2 檢測方法

通過觀察app在輸入密碼的地方是否會彈出自定義的軟鍵盤。

2.6.1.3 修復建議

建議客戶端開發(fā)自定義軟鍵盤而不是使用系統(tǒng)軟件盤以防止鍵盤劫持×××。

2.6.2   軟鍵盤安全性測試

2.6.2.1 描述

測試客戶端是否使用隨機布局的密碼軟鍵盤。 

2.6.2.2 檢測方法

用眼觀察每次彈出來的自定義的軟鍵盤是否隨機變化布局

2.6.2.3 修復建議

建議客戶端對自定義軟鍵盤進行隨機化處理，同時在每次點擊輸入框時都進行隨機初始化。

2.7     屏幕錄像測試

2.7.1   描述

測試通過連續(xù)截圖，是否可以捕捉到用戶密碼輸入框的密碼。 

2.7.2   檢測方法

通過連續(xù)截圖，是否可以捕捉到用戶密碼輸入框的密碼。 

2.7.3   修復建議

建議客戶端針對第三方或系統(tǒng)截屏編寫抵抗邏輯，例如屏蔽和截屏相關的函數(shù)或是當客戶端處于進程棧頂層時將截屏圖片用純黑×××片對象進行覆蓋。

2.8     界面劫持保護

2.8.1   界面劫描述

Activity劫持是指當啟動某個窗口組件時，被惡意應用探知，若該窗口界面是惡意程序預設的×××對象，惡意應用將啟動自己仿冒的界面覆蓋原界面，用戶在毫無察覺的情況下輸入登錄信息，惡意程序在把獲取的數(shù)據(jù)返回給服務端。

 

需要理解，Android啟動一個Activity時，是這樣設計的，給Activity加入一個標志位FLAG_ACTIVITY_NEW_TASK，就能使它置于棧頂并立馬呈現(xiàn)給用戶。但是這樣的設計卻有一個缺陷。如果這個Activity是用于盜號的偽裝Activity呢？這種現(xiàn)象在XcodeGhost事件中，已經(jīng)被證實是可以實現(xiàn)的。

在Android系統(tǒng)當中，程序可以枚舉當前運行的進程而不需要聲明其他權限，這樣的話，就可以編寫一個程序，啟動一個后臺的服務，這個服務不斷地掃描當前運行的進程，當發(fā)現(xiàn)目標進程啟動時，就啟動一個偽裝的Activity。如果這個Activity是登錄界面，那么就可以從中獲取用戶的賬號密碼，具體的過程如下圖：

2.8.2   界面劫持防護方法

作為一名移動應用開發(fā)者，要防御APP被界面劫持，最簡單的方法是在登錄窗口等關鍵Activity的onPause方法中檢測最前端Activity應用是不是自身或者是系統(tǒng)應用。如果檢測到不是自己，則彈出告警或者退出。

2.8.3   界面劫持案例

應用存在釣魚劫持風險。應用程序沒有做防釣魚劫持措施，通過劫持應用程序的登錄界面，可以獲取用戶的賬號和密碼，可能導致用戶賬號信息的泄露。

移動APP安全測試

2.8.4   整改建議

應用程序自身通過獲取棧頂activity，判斷系統(tǒng)當前運行的程序，一旦發(fā)現(xiàn)應用切換（可能被劫持），給予用戶提示以防范釣魚程序的欺詐。

獲取棧頂activity（如下圖），當涉及敏感activity（登錄、交易等）切換時，判斷當前是否仍留在原程序，若不是則通過Toast給予用戶提示。

    使用HTML5架構(gòu)或android+HTML5混合開發(fā)，實現(xiàn)登陸、支付等關鍵頁面，降低被劫持的風險。

 

2.9     本地拒絕服務

2.9.1   漏洞描述

Android系統(tǒng)提供了Activity、Service和Broadcast Receiver等組件，并提供了Intent機制來協(xié)助應用間的交互與通訊，Intent負責對應用中一次操作的動作、動作涉及數(shù)據(jù)、附加數(shù)據(jù)進行描述，Android系統(tǒng)則根據(jù)此Intent的描述，負責找到對應的組件，將Intent傳遞給調(diào)用的組件，并完成組件的調(diào)用[1]。Android應用本地拒絕服務漏洞源于程序沒有對Intent.getXXXExtra()獲取的異常或者畸形數(shù)據(jù)處理時沒有進行異常捕獲，從而導致×××者可通過向受害者應用發(fā)送此類空數(shù)據(jù)、異常或者畸形數(shù)據(jù)來達到使該應用crash的目的，簡單的說就是×××者通過intent發(fā)送空數(shù)據(jù)、異?；蚧螖?shù)據(jù)給受害者應用，導致其崩潰。

本地拒絕服務漏洞影響范圍：Android系統(tǒng)所有版本

2.9.2   漏洞檢測方法

使用Android掃描工具可以進行掃描。

2.9.3   修復建議

本地拒絕服務漏洞修復建議：

　1) 將不必要的導出的組件設置為不導出

　出于安全考慮，應將不必要的組件導出，防止引起拒絕服務，尤其是殺毒、安全防護、鎖屏防盜等安全應用; 在AndroidMenifest.xml文件中，將相應組件的“android:exported”屬性設置為“false”,如下示例：<android:exported="false">

　2) intent處理數(shù)據(jù)時進行捕獲異常

　建議處理通過Intent.getXXXExtra()獲取的數(shù)據(jù)時進行以下判斷，以及用try  catch方式進行捕獲所有異常，以防止應用出現(xiàn)拒絕服務漏洞：

　1) 空指針異常;

　2) 類型轉(zhuǎn)換異常;

　3) 數(shù)組越界訪問異常;

　4) 類未定義異常;

　5) 其他異常;

2.10        數(shù)據(jù)備份allowBackup

2.10.1 漏洞描述

Android  API Level 8及其以上 Android 系統(tǒng)提供了為應用程序數(shù)據(jù)的備份和恢復功能，此功能的開關決定于該應用程序中 AndroidManifest.xml 文件中的 allowBackup  屬性值，其屬性值默認是 True。當 allowBackup  標志為 true 時，用戶即可通過 adb backup  和 adb restore 來進行對應用數(shù)據(jù)的備份和恢復，這可能會帶來一定的安全風險。

Android  屬性 allowBackup 安全風險源于 adb backup  容許任何一個能夠打開 USB 調(diào)試開關的人從Android  手機中復制應用數(shù)據(jù)到外設，一旦應用數(shù)據(jù)被備份之后，所有應用數(shù)據(jù)都可被用戶讀取；adb restore  容許用戶指定一個恢復的數(shù)據(jù)來源（即備份的應用數(shù)據(jù)）來恢復應用程序數(shù)據(jù)的創(chuàng)建。因此，當一個應用數(shù)據(jù)被備份之后，用戶即可在其他 Android  手機或模擬器上安裝同一個應用，以及通過恢復該備份的應用數(shù)據(jù)到該設備上，在該設備上打開該應用即可恢復到被備份的應用程序的狀態(tài)。

尤其是通訊錄應用，一旦應用程序支持備份和恢復功能，×××者即可通過 adb backup 和 adb restore  進行恢復新安裝的同一個應用來查看聊天記錄等信息；對于支付金融類應用，×××者可通過此來進行惡意支付、盜取存款等；因此為了安全起見，開發(fā)者務必將 allowBackup 標志值設置為 false  來關閉應用程序的備份和恢復功能，以免造成信息泄露和財產(chǎn)損失。

 

1、不在 AndroidManifest.xml 文件設置 allowBackup  屬性值，其默認值為 true，則應用可通過 adb  命令進行備份整個應用的數(shù)據(jù)

AndroidManifest.xml文件內(nèi)容：

 

<?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 命令進行備份和恢復整個應用的數(shù)據(jù)

AndroidManifest.xml文件內(nèi)容：

<?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，則默認為可以備份應用數(shù)據(jù)，存在安全風險；如果allowBackup屬性值為false，則不可以備份應用數(shù)據(jù)。

2.10.3 修復方法

把AndroidManifest.xml文件中allowBackup屬性值設置為false。

2.11        Debug調(diào)試

2.11.1 描述

在準備發(fā)布應用之前要確保關閉debug屬性，即設置AndroidMainifest.xml中android:debuggable="false"，false表示關閉debug調(diào)試功能，true表示開啟debug調(diào)試功能，但是有時候會忘記關掉這個屬性。Debug調(diào)試開啟會存在應用被調(diào)試的風險。

2.11.2 檢測方法

  在發(fā)布之前最好進行測試，使用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已經(jīng)關閉了debuggable！

2.11.3 修復建議

把debuggable關閉

android:debuggable=false

3        通信過程安全

3.1     通信保密性

3.1.1   采用HTTPS通信

3.1.1.1 描述

驗證客戶端和服務器之前的通信是否使用https加密信道，采用https協(xié)議通信可以防止信息在傳輸過程被竊聽的風險。。

3.1.1.2 檢測方法

通過抓包工具（例如burpsuite、fiddler）抓取通信信息，看是否進行加密通信。

3.1.1.3 修復建議

使用https進行加密通信。

3.1.2   SSL劫持×××——證書校驗

3.1.2.1 描述

目前雖然很多Android APP使用了https通信方式，但是只是簡單的調(diào)用而已，并未對SSL證書有效性做驗證，https通信只是對通信信道進行了加密，可以防止監(jiān)聽數(shù)據(jù)的風險，但是無法防止中間人×××方式，通過中間人攔截代理方式可以讓采用https通信的數(shù)據(jù)暴露無遺，這樣×××者就可以利用中間人攔截代理來做劫持×××，這種漏洞讓https形同虛設，可以輕易獲取手機用戶的明文通信信息。

證書校驗是為了防止中間人劫持×××，分為強校驗和弱校驗。強校驗就是在手段端先預埋好服務端的證書，當手機端與服務端通信時獲取證書，并且與手機本地預埋的服務端證書做對比，一旦不一致，則認為遭到了中間人劫持×××，自動斷開與服務端的通信。弱校驗則是在手機端校驗證書的域名和手機真實訪問的域名是否一致、證書頒發(fā)機構(gòu)等信息。

 

強校驗流程圖：

移動APP安全測試

弱校驗流程圖：

 移動APP安全測試

 

 

 

方案對比

方案

優(yōu)點

缺點

強校驗：服務器證書鎖定

安全性最高，實施×××必須拿到對應服務器私鑰證書。

更換證書時APP影響大

弱校驗：根證書鎖定+域名驗證

更換服務器證書不受影響

安全性和CA機構(gòu)以及域名驗證機制有關。

 

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 描述

測試客戶端是否限制登錄嘗試次數(shù)。防止×××使用窮舉法暴力破解用戶密碼

4.1.2.2 檢測方法

錯誤密碼登錄請求多次（10次以上還沒有就有問題了，一般都是3次）

4.1.2.3 修復建議

建議在服務端編寫賬戶鎖定策略的邏輯，當一天內(nèi)多次輸入密碼錯誤時進行賬號鎖定以防止×××者通過暴力猜解密碼。

4.1.3   單點登錄限制策略

4.1.3.1 描述

測試能否在兩個設備上同時登錄同一個帳號。 

4.1.3.2 檢測方法

測試能否在兩個設備上同時登錄同一個帳號。 

4.1.3.3 修復建議

建議在服務器進行賬號登陸限制相應邏輯代碼的編寫，通過Session或數(shù)據(jù)庫標志位的方式控制同一時間只有一個設備可以登陸某一賬號。

4.1.4   會話超時策略

4.1.4.1 描述

測試客戶端在一定時間內(nèi)無操作后，是否會使會話超時并要求重新登錄。超時時間設置是否合理。

4.1.4.2 檢測

客戶端在一定時間內(nèi)無操作（20分鐘足夠），是否會話超時登錄

4.1.4.3 建議

建議在客戶端編寫會話安全設置的邏輯，當10分鐘或20分鐘無操作時自動退出登錄狀態(tài)或是關閉客戶端。

4.1.5   界面切換保護

4.1.5.1 描述

檢查客戶端程序在切換到后臺或其他應用時，是否能恰當響應（如清除表單或退出會話），防止用戶敏感信息泄露

4.1.5.2 檢測方法

應用切換到后臺但程序沒有結(jié)束運行，再返回應用的時候是否有身份驗證  ，手勢密碼或者登陸密碼。

4.1.5.3 修復建議

建議客戶端添加響應的邏輯，在進行進程切換操作時提示用戶確認是否為本人操作。

4.1.6   UI敏感信息安全

4.1.6.1 描述

檢查客戶端的各種功能，看是否存在敏感信息泄露問題。

4.1.6.2 檢測方法

比如登錄時，密碼輸入錯誤，APP是否會提示密碼輸入錯誤

4.1.6.3 修復建議

建議用戶名或密碼輸入錯誤均提示“用戶名或密碼錯誤”，若客戶端同時還希望保證客戶使用的友好性，可以在登陸界面通過溫馨提示的方式提示輸入錯誤次數(shù)，密碼安全策略等信息，以防用戶多次輸入密碼錯誤導致賬號鎖定。

4.1.7   安全退出

4.1.7.1 描述

驗證客戶端在用戶退出登錄狀態(tài)時是否會和服務器進行通信以保證退出的及時性

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 修復建議

建議在修改密碼時，客戶端及服務器系統(tǒng)增添原密碼輸入驗證身份的邏輯，以防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種不同手勢，若手勢密碼不存在鎖定策略，×××可以輕易跑出手勢密碼結(jié)果。手勢密碼在輸入時通常以a[2][2]這種3*3的二維數(shù)組方式保存，在進行客戶端同服務器的數(shù)據(jù)交互時通常將此二維數(shù)組中數(shù)字轉(zhuǎn)化為類似手機數(shù)字鍵盤的b[8]這種一維形式，之后進行一系列的處理進行發(fā)送

4.1.9.3.2        檢測方法

嘗試多次輸入手勢密碼錯誤，例如連續(xù)輸入3次或者5次密碼錯誤，看是否會鎖定賬號。

4.1.9.3.3        修復方法

手勢密碼策略建議連續(xù)輸入3次或者5次進行鎖定。

4.2     任意賬號注冊

4.2.1   描述

使用任意賬號可以進行注冊，造成非實名制注冊風險，惡意注冊者可以注冊大量賬號。大量賬號可以用于薅羊毛等惡意操作。

4.2.2   檢測方法

使用手機號139****1234注冊某個APP，獲取驗證碼060503，在確認提交時，攔截請求，修改注冊的手機號碼，即可注冊任意賬號，這里修改為136****5678（任意手機號）；即可使用136****5678（任意手機號）登錄，均可以通過驗證登錄。

4.2.3   修復建議

注冊過程最后的確認提交時，服務器應驗證提交的賬號是否是下發(fā)驗證碼的手機號。

4.3     短信重放×××

4.3.1   描述

檢測應用中是否存在數(shù)據(jù)包重放×××的安全問題。是否會對客戶端用戶造成短信轟炸的困擾。 

4.3.2   檢測方法

利用burpsuite抓包，然后進行重放操作。

4.3.3   修復建議

token和手機號一起，重放無法造成短信轟炸，另外就是限制每個手機號每天只能發(fā)送短信次數(shù)，例如10次。每個ip每分鐘只能發(fā)送3次。

4.4     短信驗證碼

4.4.1   描述

短信驗證碼對于防止暴力破解是一種有效的手段，但是如果驗證碼沒有使用有效，則會導致其無法發(fā)揮防暴力破解的效果。

4.4.2   檢測方法

檢測短信驗證碼是否可以多次重復使用。一般驗證碼使用一次及失效。

檢測短信驗證碼的有效期，一般驗證碼5分鐘內(nèi)有效即可。

4.4.3   修復建議

設置短信驗證碼使用一次即失效，并且每個短信驗證碼在5分鐘內(nèi)有效。

4.5     業(yè)務邏輯漏洞

此處主要是一些越權漏洞。

4.6     服務端其他漏洞

此處和web端漏洞類似，例如SQL注入、XSS、任意文件上傳漏洞等等。

網(wǎng)站名稱：移動APP安全測試
本文鏈接：http://muchs.cn/article34/ghgjpe.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供微信小程序、電子商務、面包屑導航、網(wǎng)站排名、品牌網(wǎng)站建設、靜態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)

成都網(wǎng)站建設公司