真实的国产乱ⅩXXX66竹夫人,五月香六月婷婷激情综合,亚洲日本VA一区二区三区,亚洲精品一区二区三区麻豆

成都創(chuàng)新互聯(lián)網(wǎng)站制作重慶分公司

移動APP安全測試-創(chuàng)新互聯(lián)

1       移動APP安全風(fēng)險分析

1.1    安全威脅分析

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

我們一直強調(diào)網(wǎng)站建設(shè)、網(wǎng)站制作對于企業(yè)的重要性,如果您也覺得重要,那么就需要我們慎重對待,選擇一個安全靠譜的網(wǎng)站建設(shè)公司,企業(yè)網(wǎng)站我們建議是要么不做,要么就做好,讓網(wǎng)站能真正成為企業(yè)發(fā)展過程中的有力推手。專業(yè)網(wǎng)站制作公司不一定是大公司,成都創(chuàng)新互聯(lián)作為專業(yè)的網(wǎng)絡(luò)公司選擇我們就是放心。

移動APP安全測試

1.2    面臨的主要風(fēng)險

移動APP安全測試

1.3    Android測試思維導(dǎo)圖

移動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的邏輯設(shè)計,

?  反編譯方法

我們一般想要反編譯一個apk,無非就是想獲得三樣?xùn)|西:圖片資源、XML資源、代碼資源

一. 圖片資源獲取

首先準(zhǔn)備一個apk,這里是一個.apk后綴的文件,我們先把后綴改成,zip,打開zip文件在res目錄下,我們就可以獲取到我們需要的圖片了。

二. XML資源獲取

我們可以在剛剛打開的zip文件目錄下看到很多.xml的文件,這個xml文件是無法直接打開的,當(dāng)你嘗試著打開的時候都是亂碼或者是空白,那么我們要如何獲取到這個xml資源呢,這時候就需要借助一個jar包,就是它,axmlprinter2.jar,這個東西你只要百度下,就能搜到。然后 你把他放跟你解壓出來的xml放在同級目錄下,用cmd命令找到這個目錄,

我這邊的示例是將xml放在了E盤,大家根據(jù)情況,cd到自己解壓出來的目錄下,然后執(zhí)行

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

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

三. 代碼資源獲取

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

首先要準(zhǔn)備兩樣?xùn)|西: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  修復(fù)方法

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

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

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  防二次打包修復(fù)方法

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

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

2.3    組件導(dǎo)出安全

2.3.1  四大組件描述

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

?  Activity組件

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

(2)Activity之間通過Intent進行通信。

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

?  Service組件

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

(2)開發(fā)人員需要在應(yīng)用程序AndroidManifest.xml配置文件中聲明全部的service,使用標(biāo)簽。

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

?  Content  Provider組件

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

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

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

?  broadcast  receiver

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

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

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

?  四大組件總結(jié)

(1)4大組件的注冊

4大基本組件都需要注冊才能使用,每個Activity、service、Content Provider都需要在AndroidManifest文件中進行配置。AndroidManifest文件中未進行聲明的activity、服務(wù)以及內(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)容提供者的激活:當(dāng)接收到ContentResolver發(fā)出的請求后,內(nèi)容提供者被激活。而其它三種組件activity、服務(wù)和廣播接收器被一種叫做intent的異步消息所激活。

2.3.2  組件安全檢查方法

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

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

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

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

備注:采用drozer工具可以進行檢測組件是否存在導(dǎo)出風(fēng)險

2.3.3  修復(fù)建議

(1)如果應(yīng)用的Service組件不必要導(dǎo)出,或者組件配置了intent  filter標(biāo)簽,建議顯示設(shè)置組件的“android:exported”屬性為false

(2)如果組件必須要提供給外部應(yīng)用使用,建議對組件進行權(quán)限控制

2.4    Webview漏洞

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

2.4.1.1 描述

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

WebView  中 addJavascriptInterface() 接口

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

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

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

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

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

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

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

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

問題類似以上

2.4.1.2 檢測方法

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

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

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

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

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

問題類似以上

2.4.1.3 修復(fù)建議

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

B1.  Android 4.2版本之后

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

B2.  Android 4.2版本之前

在Android 4.2版本之前采用攔截prompt()進行漏洞修復(fù)。

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

刪除searchBoxJavaBridge_接口

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

removeJavascriptInterface();

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

刪除accessibility和 accessibilityTraversal接口

2.4.2  密碼明文存儲漏洞

2.4.2.1 描述

WebView默認(rèn)開啟密碼保存功能:

mWebView.setSavePassword(true)

開啟后,在用戶輸入密碼時,會彈出提示框:詢問用戶是否保存密碼;

如果選擇”是”,密碼會被明文保到 /data/data/com.package.name/databases/webview.db  中,這樣就有被盜取密碼的危險

2.4.2.2 檢測方法

方法1、用戶輸入密碼時看是否有彈出提示框,詢問用戶是否保存密碼,如果有詢問則表示存在漏洞,否則不存在。

方法2、檢查代碼中setSavePassword的值是否為false。

2.4.2.3 修復(fù)建議

關(guān)閉密碼保存提醒

WebSettings.setSavePassword(false)

2.5    數(shù)據(jù)安全-本地敏感信息安全

2.5.1  APP所在目錄的文件權(quán)限

2.5.1.1 問題描述

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

2.5.1.2 檢測方法

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

2.5.1.3 修復(fù)建議

檢查App所在的目錄,其權(quán)限必須為不允許其他組成員讀寫

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

2.5.2.1 描述

SQLite,是一款輕型的數(shù)據(jù)庫,是遵守ACID的關(guān)系型數(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ù)還好,但是當(dāng)涉及到一些賬號密碼,或者聊天內(nèi)容的時候,我們的程序就會面臨嚴(yán)重的安全漏洞隱患。

2.5.2.2 檢測方法

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

2.5.2.3 修復(fù)建議

重要信息進行加密存儲

2.5.3  Logcat日志

2.5.3.1 描述

檢測客戶端對應(yīng)的Logcat日志是否會打印一些用戶或服務(wù)器的敏感信息。

2.5.3.2 檢測方法

通過usb連接手機,然后使用adb logcat -v time > d:\xx的方式獲取logcat信息

  或者使用DDMS工具查看logcat信息。

2.5.3.3 修復(fù)建議

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

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

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

2.5.4.1 描述

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

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

上面描述的訪問權(quán)限限制的不足,導(dǎo)致寫入到外部存儲的文件可能存在被同一設(shè)備上不同的app修改和讀取的風(fēng)險(Android4.4之前版本)。

2.5.4.2 檢測方法

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

2.5.4.3 修復(fù)建議

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

2.6    鍵盤安全風(fēng)險

2.6.1  鍵盤劫持測試

2.6.1.1 描述

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

2.6.1.2 檢測方法

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

2.6.1.3 修復(fù)建議

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

2.6.2  軟鍵盤安全性測試

2.6.2.1 描述

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

2.6.2.2 檢測方法

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

2.6.2.3 修復(fù)建議

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

2.7    屏幕錄像測試

2.7.1  描述

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

2.7.2  檢測方法

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

2.7.3  修復(fù)建議

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

2.8    界面劫持保護

2.8.1  界面劫描述

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

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

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

2.8.2  界面劫持防護方法

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

2.8.3  界面劫持案例

應(yīng)用存在釣魚劫持風(fēng)險。應(yīng)用程序沒有做防釣魚劫持措施,通過劫持應(yīng)用程序的登錄界面,可以獲取用戶的賬號和密碼,可能導(dǎo)致用戶賬號信息的泄露。

移動APP安全測試

2.8.4  整改建議

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

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

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

2.9    本地拒絕服務(wù)

2.9.1  漏洞描述

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

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

2.9.2  漏洞檢測方法

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

2.9.3  修復(fù)建議

本地拒絕服務(wù)漏洞修復(fù)建議:

1) 將不必要的導(dǎo)出的組件設(shè)置為不導(dǎo)出

出于安全考慮,應(yīng)將不必要的組件導(dǎo)出,防止引起拒絕服務(wù),尤其是殺毒、安全防護、鎖屏防盜等安全應(yīng)用; 在AndroidMenifest.xml文件中,將相應(yīng)組件的“android:exported”屬性設(shè)置為“false”,如下示例:

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

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

1) 空指針異常;

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

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

4) 類未定義異常;

5) 其他異常;

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

2.10.1 漏洞描述

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

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

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

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

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

          package="com.alibaba.jaq.allowbackuppoc"

          android:versionCode="1"

          android:versionName="1.0">

    

    

    

               android:label="@string/app_name">

        

                  android:label="@string/app_name">

            

               

               

            

        

        

    

2、在 AndroidManifest.xml 文件顯示設(shè)置 allowBackup  屬性值為 false,即android:allowBackup="false",則 Android  應(yīng)用不可通過 adb 命令進行備份和恢復(fù)整個應(yīng)用的數(shù)據(jù)

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

          package="com.alibaba.jaq.allowbackuppoc"

          android:versionCode="1"

          android:versionName="1.0">

    

    

    

            android:allowBackup="false"

            android:label="@string/app_name">

        

                  android:label="@string/app_name">

            

               

               

            

        

        

    

2.10.2 檢測方法

查看AndroidManifest.xml文件中是否有allowBackup,如果沒有則allowBackup屬性值,默認(rèn)allowBackup值為True,則默認(rèn)為可以備份應(yīng)用數(shù)據(jù),存在安全風(fēng)險;如果allowBackup屬性值為false,則不可以備份應(yīng)用數(shù)據(jù)。

2.10.3 修復(fù)方法

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

2.11       Debug調(diào)試

2.11.1 描述

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

2.11.2 檢測方法

 在發(fā)布之前最好進行測試,使用aapt工具:

  aapt  list -v -a myfile.apk

 這個命令將會打印和apk相關(guān)的所有詳細(xì)信息,找到“android:debuggable",它的值分為:

 0x0: debuggable false

 0xffffffff: debugabble true

 例如,在我的測試中,這一行的信息是:

 A: android ebuggable(0x0101000f)=(type  0x12)0x0

 這說明我的Release Build已經(jīng)關(guān)閉了debuggable!

2.11.3 修復(fù)建議

把debuggable關(guān)閉

android:debuggable=false

3       通信過程安全

3.1    通信保密性

3.1.1  采用HTTPS通信

3.1.1.1 描述

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

3.1.1.2 檢測方法

通過抓包工具(例如burpsuite、fiddler)抓取通信信息,看是否進行加密通信。

3.1.1.3 修復(fù)建議

使用https進行加密通信。

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

3.1.2.1 描述

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

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

強校驗流程圖:

移動APP安全測試

弱校驗流程圖:

 移動APP安全測試

方案對比

方案

優(yōu)點

缺點

強校驗:服務(wù)器證書鎖定

安全性最高,實施×××必須拿到對應(yīng)服務(wù)器私鑰證書。

更換證書時APP影響大

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

更換服務(wù)器證書不受影響

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

3.1.2.2 檢測方法

通過抓包看手機端程序是否運行正常,如果通過代理方式抓包,手機APP自動強制退出,說明手機APP有做證書校驗。

3.1.2.3 整改方法

采用強校驗或者弱校驗方法。

3.2    訪問控制

3.2.1  描述

測試客戶端訪問的URL是否僅能由手機客戶端訪問。是否可以繞過登錄限制直接訪問登錄后才能訪問的頁面,對需要二次驗證的頁面(如私密問題驗證),能否繞過驗證。

3.2.2  檢測方法

利用截包工具獲取url,能用瀏覽器打開該url。

3.2.3  修復(fù)建議

建議服務(wù)器進行相應(yīng)的訪問控制,控制對應(yīng)頁面僅能通過手機客戶端訪問。同時進行頁面訪問控制,防止繞過登陸直接訪問頁面的非法訪問。

4       服務(wù)端安全

4.1    安全策略設(shè)置

4.1.1  密碼復(fù)雜度策略

4.1.1.1 描述

測試客戶端程序是否檢查用戶輸入的密碼,禁止用戶設(shè)置弱口令

4.1.1.2 檢測方法

修改設(shè)置用戶名密碼時,可以設(shè)置111111類似弱口令

4.1.1.3 修復(fù)建議

建議在服務(wù)器編寫檢測密碼復(fù)雜度的安全策略,并將其運用到賬號注冊,密碼修改等需要進行密碼變更的場景,以防止×××者通過弱密鑰遍歷賬戶的方式進行暴力猜解。

4.1.2  認(rèn)證失敗鎖定策略

4.1.2.1 描述

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

4.1.2.2 檢測方法

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

4.1.2.3 修復(fù)建議

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

4.1.3  單點登錄限制策略

4.1.3.1 描述

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

4.1.3.2 檢測方法

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

4.1.3.3 修復(fù)建議

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

4.1.4  會話超時策略

4.1.4.1 描述

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

4.1.4.2 檢測

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

4.1.4.3 建議

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

4.1.5  界面切換保護

4.1.5.1 描述

檢查客戶端程序在切換到后臺或其他應(yīng)用時,是否能恰當(dāng)響應(yīng)(如清除表單或退出會話),防止用戶敏感信息泄露

4.1.5.2 檢測方法

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

4.1.5.3 修復(fù)建議

建議客戶端添加響應(yīng)的邏輯,在進行進程切換操作時提示用戶確認(rèn)是否為本人操作。

4.1.6  UI敏感信息安全

4.1.6.1 描述

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

4.1.6.2 檢測方法

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

4.1.6.3 修復(fù)建議

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

4.1.7  安全退出

4.1.7.1 描述

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

4.1.7.2 檢測方法

客戶端在用戶退出登錄時,查看session是否可用

4.1.7.3 修復(fù)建議

保證客戶端和服務(wù)器同步退出,APP退出時服務(wù)器端的清除會話

4.1.8  密碼修改驗證

4.1.8.1 描述

驗證客戶端在進行密碼修改時的安全性

4.1.8.2 檢測方法

是否存在原密碼驗證

4.1.8.3 修復(fù)建議

建議在修改密碼時,客戶端及服務(wù)器系統(tǒng)增添原密碼輸入驗證身份的邏輯,以防Cookie登陸修改密碼的×××。

4.1.9  手勢密碼

4.1.9.1 手勢密碼修改和取消
4.1.9.1.1        描述

檢測客戶端在取消手勢密碼時是否會驗證之前設(shè)置的手勢密碼,檢測是否存在其他導(dǎo)致手勢密碼取消的邏輯問題

4.1.9.1.2        檢測方法

檢測客戶端在取消手勢密碼時是否會驗證之前設(shè)置的手勢密碼,檢測是否存在其他導(dǎo)致手勢密碼取消的邏輯問題

4.1.9.1.3        修復(fù)建議

不應(yīng)該存在其他導(dǎo)致手勢密碼取消的邏輯,客戶端在取消手勢密碼時應(yīng)驗證之前設(shè)置的手勢密碼

4.1.9.2 手勢密碼本地信息保存
4.1.9.2.1        描述

檢測在輸入手勢密碼以后客戶端是否會在本地記錄一些相關(guān)信息,例如明文或加密過的手勢密碼。

4.1.9.2.2        檢測方法

找到存儲文件,看其是否加密

4.1.9.2.3        修復(fù)建議

應(yīng)該進行加密

4.1.9.3 手勢密碼鎖定策略
4.1.9.3.1        描述

測試客戶端是否存在手勢密碼多次輸入錯誤被鎖定的安全策略。防止×××使用窮舉法暴力破解用戶密碼。因為手勢密碼的存儲容量非常小,一共只有9!=362880種不同手勢,若手勢密碼不存在鎖定策略,×××可以輕易跑出手勢密碼結(jié)果。手勢密碼在輸入時通常以a[2][2]這種3*3的二維數(shù)組方式保存,在進行客戶端同服務(wù)器的數(shù)據(jù)交互時通常將此二維數(shù)組中數(shù)字轉(zhuǎn)化為類似手機數(shù)字鍵盤的b[8]這種一維形式,之后進行一系列的處理進行發(fā)送

4.1.9.3.2        檢測方法

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

4.1.9.3.3        修復(fù)方法

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

4.2    任意賬號注冊

4.2.1  描述

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

4.2.2  檢測方法

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

4.2.3  修復(fù)建議

注冊過程最后的確認(rèn)提交時,服務(wù)器應(yīng)驗證提交的賬號是否是下發(fā)驗證碼的手機號。

4.3    短信重放×××

4.3.1  描述

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

4.3.2  檢測方法

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

4.3.3  修復(fù)建議

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

4.4    短信驗證碼

4.4.1  描述

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

4.4.2  檢測方法

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

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

4.4.3  修復(fù)建議

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

4.5    業(yè)務(wù)邏輯漏洞

此處主要是一些越權(quán)漏洞。

4.6    服務(wù)端其他漏洞

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

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn,海內(nèi)外云服務(wù)器15元起步,三天無理由+7*72小時售后在線,公司持有idc許可證,提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案,具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢,專為企業(yè)上云打造定制,能夠滿足用戶豐富、多元化的應(yīng)用場景需求。


本文名稱:移動APP安全測試-創(chuàng)新互聯(lián)
當(dāng)前網(wǎng)址:http://weahome.cn/article/iiscd.html

其他資訊

在線咨詢

微信咨詢

電話咨詢

028-86922220(工作日)

18980820575(7×24)

提交需求

返回頂部