国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

APP漏洞自動化掃描專業(yè)評測報(bào)告(下篇)

young.li / 3272人閱讀

摘要:上篇中篇回顧通過收費(fèi)情況樣本測試后的掃描時(shí)間漏洞項(xiàng)對比以及掃描能力這幾個(gè)方面對阿里聚安全漏洞掃描騰訊金剛審計(jì)系統(tǒng)百度移動云測試中心以及進(jìn)行了對比分析。我推測百度對于此類漏洞的檢測規(guī)則是判斷是否有這個(gè)函數(shù)。

上篇、中篇回顧:通過收費(fèi)情況、樣本測試后的掃描時(shí)間、漏洞項(xiàng)對比以及掃描能力這幾個(gè)方面對阿里聚安全[1]、360App漏洞掃描[2]、騰訊金剛審計(jì)系統(tǒng)[3]、百度移動云測試中心[4]以及AppRisk Scanner[5]進(jìn)行了對比分析。作為本系列的最后一篇,我將會以4個(gè)隨機(jī)選取的APP的測試結(jié)果來進(jìn)行對比。

四、掃描結(jié)果對比

選取的APP:說明一下這次選擇的四個(gè)app是根據(jù)下載和安裝量來選擇,分別在網(wǎng)絡(luò)工具類、天氣、社交資訊類和搜索工具類選擇了下載量和安裝量最大的。出于對應(yīng)用的隱私保護(hù)這里把最后選定的應(yīng)用名隱去暫時(shí)叫做A應(yīng)用

評測方法:將以上4個(gè)APP分別上傳到五家掃描平臺,都分別得到5家平臺的掃描速度和結(jié)果。除了在上篇中對比掃描時(shí)間外,這里還要對5家的掃描結(jié)果進(jìn)行對比。但是實(shí)際操作下來4個(gè)APP的對比工作量實(shí)在太大,所以我最后從工作量小易于分析的原則出發(fā),選擇了A應(yīng)用來最為結(jié)果對比。

下面我將以A應(yīng)用的掃描結(jié)果為例,詳細(xì)分析一下各個(gè)平臺的掃描結(jié)果的漏報(bào)和誤報(bào),從而評估其掃描結(jié)果的可信度。

A應(yīng)用的掃描結(jié)果如表4-1所示。

表4-1掃描結(jié)果總覽

? 阿里 360 金剛 百度 AppRisk
WebView繞過證書校驗(yàn)漏洞 2 ? 2 1 ?
WebView組件遠(yuǎn)程代碼執(zhí)行漏洞 2 ? 2 3 2
中間人攻擊(Allow All host name) 1 ? ? 1 ?
備份功能開啟風(fēng)險(xiǎn) 1 1 1 1 1
主機(jī)名弱校驗(yàn) 1 1 1 1 ?
證書弱校驗(yàn) 4 ? 2 4 1
拒絕服務(wù) 3 ? 1 ? ?
Intent協(xié)議解析越權(quán)漏洞 1 ? ? ? ?
AES/DES弱加密 1 ? ? 15 ?
初始化IVParameterSpec函數(shù)出錯(cuò) 9 ? ? ? ?
PendigIntent誤用風(fēng)險(xiǎn) 2 ? ? 5 2
WebView明文存儲密碼風(fēng)險(xiǎn) 6 ? ? 25 30
WebView組件系統(tǒng)隱藏接口漏洞 5 ? 12 1 32
日志泄露風(fēng)險(xiǎn) 5 1 ? 241 286
強(qiáng)制類型轉(zhuǎn)換本地拒絕服務(wù)漏洞 ? ? 6 ? ?
App存在隱式意圖調(diào)用 ? 2 3 ? ?
組件導(dǎo)出風(fēng)險(xiǎn) ? 22 24 23 17
Intent泄露用戶敏感信息 ? 1 ? 1 ?
廣播信息泄露風(fēng)險(xiǎn) ? 2 ? ? ?
Dex文件動態(tài)加載 0 ? ? 1 9
加密哈希函數(shù)漏洞MD5 ? ? ? ? 12
加密哈希函數(shù)漏洞SHA-1 ? ? ? ? 1
Native動態(tài)調(diào)試 1 ? ? ? ?
密鑰硬編碼 10 ? ? ? ?
安全加固風(fēng)險(xiǎn) 1 ? ? ? ?
WebView File域同源策略繞過 2 ? ? ? ?

A應(yīng)用只有一個(gè)dex文件,這排除了隱藏dex對結(jié)果的影響,接下來的章節(jié)中對掃描結(jié)果進(jìn)行詳細(xì)的對比分析。

4.1 WebView繞過證書校驗(yàn)漏洞

表4-3 WebView繞過證書校驗(yàn)漏洞分析結(jié)果

? 誤報(bào) 漏報(bào)
360 0 2
金剛 0 未知
阿里 0 未知
百度 0 1
AppRisk 0 2

WebView 繞過證書校驗(yàn)漏洞是指 onReceivedSslError 函數(shù)中調(diào)用 proceed 方法,會導(dǎo) WebView 忽略校驗(yàn)證書的步驟。對于 WebView 繞過證書校驗(yàn)漏洞,經(jīng)過比對,阿里金剛定位的漏洞位置一致。因此我認(rèn)為360AppRisk漏報(bào)了2個(gè),百度漏報(bào)了1個(gè)。我推測百度對于此類漏洞的檢測規(guī)則是判斷是否有onReceivedSslError 這個(gè)函數(shù)。

SslErrorHandler 這個(gè)類會代表一個(gè)請求去處理ssl error。 SslErrorHandler 會被 WebView 創(chuàng)立然后傳給 onReceivedSslError 函數(shù)進(jìn)行處理。其實(shí)真正做證書處理的函數(shù)是 SslErrorHandler 類的 proceed 函數(shù)。這個(gè)函數(shù)一般會是在 SslErrorHandler 函數(shù)里面進(jìn)行調(diào)用,但是它還是可能在其他函數(shù)中被調(diào)用。因此檢查proceed這個(gè)函數(shù)會更加全面。阿里金剛應(yīng)該是檢查 Landroid/webkit/SslErrorHandler;->proceed()V。百度漏報(bào)的一個(gè)正好符合我的推論。

4.2 證書弱校驗(yàn)

表4-4 證書弱校驗(yàn)分析結(jié)果

? 誤報(bào) 漏報(bào)
360 0 4
金剛 0 2
阿里 0 未知
百度 0 未知
AppRisk 0 3

證書弱校驗(yàn)漏洞是在實(shí)現(xiàn)的 X509TrustManager 子類中 checkServerTrusted 函數(shù)沒有校驗(yàn)服務(wù)器端證書的合法性導(dǎo)致的。360漏報(bào)4個(gè),金剛漏報(bào)2個(gè),AppRisk漏報(bào)3個(gè)。經(jīng)過我的分析,一共有6處調(diào)用了checkServerTrusted,其中2處對證書進(jìn)行了驗(yàn)證;而4處沒有驗(yàn)證,直接返回,有兩種形式,如下圖所示:

我推測,漏報(bào)的原因是多了兩行param導(dǎo)致掃描器認(rèn)為對證書有校驗(yàn)。

4.3 WebView明文存儲密碼風(fēng)險(xiǎn)

表4-5 WebView明文存儲密碼風(fēng)險(xiǎn)分析結(jié)果

? 誤報(bào) 漏報(bào)
360 無檢測 無檢測
金剛 無檢測 無檢測
阿里 0 4
百度 15 未知
AppRisk 23 3

經(jīng)過分析,我猜測AppRisk是通過 loadUrl 函數(shù)判斷是否使用了 WebView,然后在使用 loadUrl 的類中搜索該 WebView 是否調(diào)用 setSavePassword(false) 方法。而我在反編譯的代碼中進(jìn)行全局搜索,一共有34處調(diào)用 loadUrl;其中4處所處的類中顯式調(diào)用了 setSavePassword(false) 方法,符合我的猜測,由于其他3處沒有調(diào)用 loadUrl ,所以AppRisk漏報(bào)了3處。

百度的檢測邏輯就比較難猜測,它不僅通過 loadUrl,還通過其他方法判斷是否使用了 WebView,所以它可能沒有漏報(bào),但是誤報(bào)率比較高。阿里沒有檢測出那些通過 findViewById 方法獲得的 WebView 引起的明文密碼存儲風(fēng)險(xiǎn),漏報(bào)了4處。

4.4 日志泄露風(fēng)險(xiǎn)

表4-6 日志泄露風(fēng)險(xiǎn)分析結(jié)果

? 誤報(bào) 漏報(bào)
360 未知 未知
金剛 無檢測 無檢測
阿里 未知 未知
百度 未知 未知
AppRisk 未知 未知

各個(gè)掃描平臺對日志泄露風(fēng)險(xiǎn)的處理方式完全不同,在此一起討論。

從掃描結(jié)果來看,阿里好像只檢測 System.out.print 函數(shù)打印的內(nèi)容。并沒有過濾Log函數(shù)。實(shí)際上,Log函數(shù)也會泄露敏感的日志信息。

360認(rèn)為只要存在Log日志,不管是 System.out.print 還是Log函數(shù),都認(rèn)為存在日志泄露風(fēng)險(xiǎn)。但無論日志泄露有多少,都只會給出一個(gè)存在Log日志泄露的風(fēng)險(xiǎn),而且沒有具體的漏洞位置。

百度AppRisk對待日志泄露的態(tài)度相似,檢測Log函數(shù)。

所以從我這看,阿里360以及百度AppRisk的出發(fā)點(diǎn)是不同的。結(jié)果也沒有很好的可比性。能可比的,就是對待這個(gè)日志泄露風(fēng)險(xiǎn)的一個(gè)規(guī)則。

4.5 PendingIntent誤用風(fēng)險(xiǎn)

表4-7 PendingIntent誤用風(fēng)險(xiǎn)分析結(jié)果

? 誤報(bào) 漏報(bào)
360 無檢測 無檢測
金剛 無檢測 無檢測
阿里 0 3
百度 0 未知
AppRisk 0 3

百度的 PendingIntent 誤用風(fēng)險(xiǎn),不僅包括 Intent 為空的情況,還包含了隱式Intent的情況。A應(yīng)用中,有2個(gè)是空Intent,有3個(gè)是隱式Intent。而阿里AppRisk的 PendingIntent 誤用風(fēng)險(xiǎn)監(jiān)測可能只包括Intent為空的情況,所以只檢測出2處漏洞,漏報(bào)了3個(gè)隱式的Intent。如果從兩者的檢測內(nèi)容上看,阿里、百度AppRisk都沒有誤報(bào)的情況。

4.6 WebView遠(yuǎn)程代碼執(zhí)行漏洞

五個(gè)掃描都具有掃描WebView遠(yuǎn)程代碼執(zhí)行漏洞,但是給出的結(jié)果卻不一樣。掃描結(jié)果如下表所示:

表 4-8 WebView遠(yuǎn)程代碼執(zhí)行漏洞分析結(jié)果

? 誤報(bào) 漏報(bào)
360 0 3
金剛 0 1
阿里 0 1
百度 0 未知
AppRisk 0 1

在WebView遠(yuǎn)程代碼執(zhí)行漏洞檢測中,經(jīng)過人工分析,確認(rèn)阿里、金剛以及AppRisk各漏報(bào)1個(gè),360漏報(bào)3個(gè)。阿里沒有識別 findViewById 方法實(shí)例化的 WebView,因而漏報(bào)了1個(gè)。

4.7 Dex文件動態(tài)加載

只有阿里、百度AppRisk這三個(gè)掃描器包含該掃描項(xiàng)。

阿里的檢測規(guī)則(猜測):

1) 檢測特征函數(shù) DexClassLoader 以及 PathClassLoader 的構(gòu)造函數(shù)。

2) 檢測該特征函數(shù)的傳入?yún)?shù)(加載路徑)是否包含“sdcard”字符串

百度的檢測規(guī)則(猜測):

1) 檢測特征函數(shù) DexClassLoader 以及 PathClassLoader 的構(gòu)造函數(shù)

AppRisk的檢測規(guī)則(猜測):

2) 檢測 DexClassLoader 中 loadClass 調(diào)用

我在反編譯的代碼中進(jìn)行全局搜索 “DexClassLoader;->loadClass”,一共有9處,故猜測AppRisk的檢測規(guī)則為檢測 loadClass 函數(shù)的調(diào)用。

由于檢測點(diǎn)不一樣無法判斷具體的漏報(bào)和誤報(bào)。

4.8 AES/DES弱加密

表4-9 AES/DES弱加密分析結(jié)果

? 誤報(bào) 漏報(bào)
360 0 1
金剛 無檢測 無檢測
阿里 0 未知
百度 14 未知
AppRisk 0 1

該項(xiàng)金剛不會檢測,而360AppRisk都沒有檢測出 AES/DES 弱加密風(fēng)險(xiǎn),都漏報(bào)了1個(gè)。而百度卻檢測出15個(gè)弱加密風(fēng)險(xiǎn)。經(jīng)過分析,我猜測百度只是檢測是否包含AES或者DES,并沒有判斷加密模式是否為ECB,使用其他加密模式是不存在安全隱患的。而阿里正確檢測出1個(gè),因此我的結(jié)論是百度誤報(bào)14個(gè)漏洞,360AppRisk漏報(bào)1個(gè)。

4.9 WebView組件系統(tǒng)隱藏接口漏洞

表4-10 WebView組件系統(tǒng)隱藏接口漏洞分析結(jié)果

? 誤報(bào) 漏報(bào)
360 0 未知
金剛 9 2
阿里 0 未知
百度 0 4
AppRisk 27 3

360沒有掃描出WebView隱藏接口漏洞,原因未知。

金剛誤報(bào)了9個(gè),而且還有2個(gè)漏洞漏報(bào);百度漏報(bào)了4個(gè)漏洞,只正確找出1個(gè)。通過之前的掃描能力分析我可知,金剛可能僅僅是尋找是否有使用了 WebView,而沒對WebView是否啟用了 JavaScript 進(jìn)行檢查,所以誤報(bào)率很高。百度沒有誤報(bào),但漏報(bào)很多,可能是百度沒有判斷 WebView 是否啟用了 JavaScript,所以本著減少誤報(bào)的原則,只報(bào)告百分之百確定的漏洞。

AppRisk的檢測規(guī)則可能非常簡單粗暴,僅僅檢查 loadUrl 來確定是否使用了 WebView,因而誤報(bào)率很高。

阿里可能首先判斷 WebView 是否允許 JavaScript 運(yùn)行。只有在 JavaScript 允許運(yùn)行時(shí)移除隱藏接口才有意義;然后如果 JavaScript 開啟,那么就判斷 WebView 是否移除了 “searchBoxJavaBridge_”、“accessibilityTraversal”以及“accessibility” 這3個(gè)接口。如果都移除了才安全。所以阿里漏報(bào)和誤報(bào)都很低。

五、總結(jié)和展望

通過此次評測,我基本了解了目前國內(nèi)移動安全掃描平臺的發(fā)展?fàn)顩r,了解了主流掃描平臺的檢測能力,包括掃描項(xiàng)、漏洞的檢測規(guī)則等。我發(fā)現(xiàn)沒有一家掃描平臺可以覆蓋所有的安全漏洞和風(fēng)險(xiǎn)。

相對來說, AppRisk掃描速度最快,掃描結(jié)果展示更加專業(yè);360金剛作為老牌的掃描器,盡管掃描速度慢了一點(diǎn),但掃描能力和結(jié)果展示也比較不錯(cuò);阿里聚安全的掃描項(xiàng)覆蓋廣一些,漏報(bào)和誤報(bào)率較低,檢測結(jié)果更加可信一點(diǎn)。百度作為其中唯一一家收費(fèi)的掃描平臺,在某些掃描項(xiàng)的掃描能力上處于領(lǐng)先位置,掃描速度也比較快。總之,五家掃描平臺在競爭中互相學(xué)習(xí),取長補(bǔ)短。

Reference:

[1]阿里聚安全 http://jaq.alibaba.com/

[2]360APP漏洞掃描 http://dev.360.cn/mod/vulscan/

[3]騰訊金剛審計(jì)系統(tǒng) http://service.security.tence...

[4]百度移動云測試中心 http://mtc.baidu.com/startTes...

[5]AppRisk Scanner https://apprisk.newskysecurit...

文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/8743.html

相關(guān)文章

  • APP漏洞動化掃描專業(yè)評測報(bào)告下篇

    摘要:上篇中篇回顧通過收費(fèi)情況樣本測試后的掃描時(shí)間漏洞項(xiàng)對比以及掃描能力這幾個(gè)方面對阿里聚安全漏洞掃描騰訊金剛審計(jì)系統(tǒng)百度移動云測試中心以及進(jìn)行了對比分析。我推測百度對于此類漏洞的檢測規(guī)則是判斷是否有這個(gè)函數(shù)。 上篇、中篇回顧:通過收費(fèi)情況、樣本測試后的掃描時(shí)間、漏洞項(xiàng)對比以及掃描能力這幾個(gè)方面對阿里聚安全[1]、360App漏洞掃描[2]、騰訊金剛審計(jì)系統(tǒng)[3]、百度移動云測試中心[4]以...

    zone 評論0 收藏0
  • APP 漏洞動化掃描專業(yè)評測報(bào)告(中篇)

    摘要:前言上一篇中通過對阿里聚安全漏洞掃描騰訊金剛審計(jì)系統(tǒng)百度移動云測試中心以及在收費(fèi)情況樣本測試后的掃描時(shí)間對比和漏洞項(xiàng)專業(yè)對比后,本篇將以各個(gè)廠商的掃描能力作為分析維度展開。表示掃描結(jié)果正確,表示掃描結(jié)果錯(cuò)誤。 前言 上一篇中通過對阿里聚安全[1]、360App 漏洞掃描[2]、騰訊金剛審計(jì)系統(tǒng)[3]、百度移動云測試中心[4]以及AppRisk Scanner[5] 在收費(fèi)情況、樣本測試...

    justjavac 評論0 收藏0
  • APP 漏洞動化掃描專業(yè)評測報(bào)告(中篇)

    摘要:前言上一篇中通過對阿里聚安全漏洞掃描騰訊金剛審計(jì)系統(tǒng)百度移動云測試中心以及在收費(fèi)情況樣本測試后的掃描時(shí)間對比和漏洞項(xiàng)專業(yè)對比后,本篇將以各個(gè)廠商的掃描能力作為分析維度展開。表示掃描結(jié)果正確,表示掃描結(jié)果錯(cuò)誤。 前言 上一篇中通過對阿里聚安全[1]、360App 漏洞掃描[2]、騰訊金剛審計(jì)系統(tǒng)[3]、百度移動云測試中心[4]以及AppRisk Scanner[5] 在收費(fèi)情況、樣本測試...

    jackzou 評論0 收藏0
  • Kali Linux 秘籍 第五章 漏洞評估

    摘要:第五章漏洞評估作者譯者飛龍協(xié)議簡介掃描和識別目標(biāo)的漏洞通常被滲透測試者看做無聊的任務(wù)之一。家庭版的有效許可證。在標(biāo)簽頁中,選擇并選擇下列特定的漏洞。。漏洞會詳細(xì)列出。發(fā)現(xiàn)特定的漏洞在這個(gè)秘籍中,我們會使用探索如何發(fā)現(xiàn)特定漏洞。 第五章 漏洞評估 作者:Willie L. Pritchett, David De Smet 譯者:飛龍 協(xié)議:CC BY-NC-SA 4.0 簡介 掃描和...

    csRyan 評論0 收藏0

發(fā)表評論

0條評論

最新活動
閱讀需要支付1元查看
<