上篇、中篇回顧：通過收費情況、樣本測試後的掃描時間、漏洞項對比以及掃描能力這幾個方面對阿里聚安全[1]、360App漏洞掃描[2]、騰訊金剛審計系統[3]、百度移動雲測試中心[4]以及AppRisk Scanner[5]進行了對比分析。作爲本系列的最後一篇，我將會以4個隨機選取的APP的測試結果來進行對比。
四、掃描結果對比
選取的APP：說明一下這次選擇的四個app是根據下載和安裝量來選擇，分別在網絡工具類、天氣、社交資訊類和搜索工具類選擇了下載量和安裝量最大的。出於對應用的隱私保護這裏把最後選定的應用名隱去暫時叫做A應用。
評測方法：將以上4個APP分別上傳到五家掃描平臺，都分別得到5家平臺的掃描速度和結果。除了在上篇中對比掃描時間外，這裏還要對5家的掃描結果進行對比。但是實際操作下來4個APP的對比工作量實在太大，所以我最後從工作量小易於分析的原則出發，選擇了A應用來最爲結果對比。
下面我將以A應用的掃描結果爲例，詳細分析一下各個平臺的掃描結果的漏報和誤報，從而評估其掃描結果的可信度。
A應用的掃描結果如表4-1所示。
表4-1 掃描結果總覽
阿里 | 360 | 金剛 | 百度 | AppRisk | |
WebView繞過證書校驗漏洞 | 2 | 2 | 1 | ||
WebView組件遠程代碼執行漏洞 | 2 | 2 | 3 | 2 | |
中間人***（Allow All host name） | 1 | 1 | |||
備份功能開啓風險 | 1 | 1 | 1 | 1 | 1 |
主機名弱校驗 | 1 | 1 | 1 | 1 | |
證書弱校驗 | 4 | 2 | 4 | 1 | |
拒絕服務 | 3 | 1 | |||
Intent協議解析越權漏洞 | 1 | ||||
AES/DES弱加密 | 1 | 15 | |||
初始化IVParameterSpec函數出錯 | 9 | ||||
PendigIntent誤用風險 | 2 | 5 | 2 | ||
WebView明文存儲密碼風險 | 6 | 25 | 30 | ||
WebView組件系統隱藏接口漏洞 | 5 | 12 | 1 | 32 | |
日誌泄露風險 | 5 | 1 | 241 | 286 | |
強制類型轉換本地拒絕服務漏洞 | 6 | ||||
App存在隱式意圖調用 | 2 | 3 | |||
組件導出風險 | 22 | 24 | 23 | 17 | |
Intent泄露用戶敏感信息 | 1 | 1 | |||
廣播信息泄露風險 | 2 | ||||
Dex文件動態加載 | 0 | 1 | 9 | ||
加密哈希函數漏洞MD5 | 12 | ||||
加密哈希函數漏洞SHA-1 | 1 | ||||
Native動態調試 | 1 | ||||
密鑰硬編碼 | 10 | ||||
安全加固風險 | 1 | ||||
WebView File域同源策略繞過 | 2 |
A應用只有一個dex文件，這排除了隱藏dex對結果的影響，接下來的章節中對掃描結果進行詳細的對比分析。
4.1 WebView繞過證書校驗漏洞
表4-3 WebView繞過證書校驗漏洞分析結果
誤報 | 漏報 | |
360 | 0 | 2 |
金剛 | 0 | 未知 |
阿里 | 0 | 未知 |
百度 | 0 | 1 |
AppRisk | 0 | 2 |
WebView繞過證書校驗漏洞是指onReceivedSslError函數中調用proceed方法，會導致WebView忽略校驗證書的步驟。對於WebView繞過證書校驗漏洞，經過比對，阿里和金剛定位的漏洞位置一致。因此我認爲360和AppRisk漏報了2個，百度漏報了1個。我推測百度對於此類漏洞的檢測規則是判斷是否有onReceivedSslError這個函數。SslErrorHandler這個類會代表一個請求去處理sslerror。
SslErrorHandler會被WebView創立然後傳給onReceivedSslError函數進行處理。其實真正做證書處理的函數是SslErrorHandler類的proceed函數。這個函數一般會是在SslErrorHandler函數裏面進行調用，但是它還是可能在其他函數中被調用。因此檢查proceed這個函數會更加全面。阿里與金剛應該是檢查Landroid/webkit/SslErrorHandler;->proceed()V。百度漏報的一個正好符合我的推論。
4.2 證書弱校驗
表4-4 證書弱校驗分析結果
誤報 | 漏報 | |
360 | 0 | 4 |
金剛 | 0 | 2 |
阿里 | 0 | 未知 |
百度 | 0 | 未知 |
AppRisk | 0 | 3 |
證書弱校驗漏洞是在實現的X509TrustManager子類中checkServerTrusted函數沒有校驗服務器端證書的合法性導致的。360漏報4個，金剛漏報2個，AppRisk漏報3個。經過我的分析，一共有6處調用了checkServerTrusted，其中2處對證書進行了驗證；而4處沒有驗證，直接返回，有兩種形式，如下圖所示：
我推測，漏報的原因是多了兩行param導致掃描器認爲對證書有校驗。
4.3 WebView明文存儲密碼風險
表4-5 WebView明文存儲密碼風險分析結果
誤報 | 漏報 | |
360 | 無檢測 | 無檢測 |
金剛 | 無檢測 | 無檢測 |
阿里 | 0 | 4 |
百度 | 15 | 未知 |
AppRisk | 23 | 3 |
經過分析，我猜測AppRisk是通過loadUrl函數判斷是否使用了WebView，然後在使用loadUrl的類中搜索該WebView是否調用setSavePassword(false)方法。而我在反編譯的代碼中進行全局搜索，一共有34處調用loadUrl；其中4處所處的類中顯式調用了setSavePassword(false)方法，符合我的猜測，由於其他3處沒有調用loadUrl，所以AppRisk漏報了3處。
百度的檢測邏輯就比較難猜測，它不僅通過loadUrl，還通過其他方法判斷是否使用了WebView，所以它可能沒有漏報，但是誤報率比較高。阿里沒有檢測出那些通過findViewById方法獲得的WebView引起的明文密碼存儲風險，漏報了4處。
4.4 日誌泄露風險
表4-6 日誌泄露風險分析結果
誤報 | 漏報 | |
360 | 未知 | 未知 |
金剛 | 無檢測 | 無檢測 |
阿里 | 未知 | 未知 |
百度 | 未知 | 未知 |
AppRisk | 未知 | 未知 |
各個掃描平臺對日誌泄露風險的處理方式完全不同，在此一起討論。
從掃描結果來看，阿里好像只檢測System.out.print函數打印的內容。並沒有過濾Log函數。實際上，Log函數也會泄露敏感的日誌信息。
360認爲只要存在Log日誌，不管是System.out.print還是Log函數，都認爲存在日誌泄露風險。但無論日誌泄露有多少，都只會給出一個存在Log日誌泄露的風險，而且沒有具體的漏洞位置。
百度和AppRisk對待日誌泄露的態度相似，檢測Log函數。
所以從我這看，阿里、360以及百度和AppRisk的出發點是不同的。結果也沒有很好的可比性。能可比的，就是對待這個日誌泄露風險的一個規則。
4.5 PendingIntent誤用風險
表4-7 PendingIntent誤用風險分析結果
誤報 | 漏報 | |
360 | 無檢測 | 無檢測 |
金剛 | 無檢測 | 無檢測 |
阿里 | 0 | 3 |
百度 | 0 | 未知 |
AppRisk | 0 | 3 |
百度的PendingIntent誤用風險，不僅包括Intent爲空的情況，還包含了隱式Intent的情況。A應用中，有2個是空Intent，有3個是隱式Intent。而阿里和AppRisk的PendingIntent誤用風險監測可能只包括Intent爲空的情況，所以只檢測出2處漏洞，漏報了3個隱式的Intent。如果從兩者的檢測內容上看，阿里、百度和AppRisk都沒有誤報的情況。
4.6 WebView遠程代碼執行漏洞
五個掃描都具有掃描WebView遠程代碼執行漏洞，但是給出的結果卻不一樣。掃描結果如下表所示：
表4-8 WebView遠程代碼執行漏洞分析結果
誤報 | 漏報 | |
360 | 0 | 3 |
金剛 | 0 | 1 |
阿里 | 0 | 1 |
百度 | 0 | 未知 |
AppRisk | 0 | 1 |
在WebView遠程代碼執行漏洞檢測中，經過人工分析，確認阿里、金剛以及AppRisk各漏報1個，360漏報3個。阿里沒有識別findViewById方法實例化的WebView，因而漏報了1個。
4.7 Dex文件動態加載
只有阿里、百度和AppRisk這三個掃描器包含該掃描項。
阿里的檢測規則（猜測）：
1）檢測特徵函數DexClassLoader以及PathClassLoader的構造函數。
2）檢測該特徵函數的傳入參數（加載路徑）是否包含“sdcard”字符串
百度的檢測規則（猜測）：
檢測特徵函數DexClassLoader以及PathClassLoader的構造函數
AppRisk的檢測規則（猜測）：
檢測DexClassLoader中loadClass調用
我在反編譯的代碼中進行全局搜索“DexClassLoader;->loadClass”，一共有9處，故猜測AppRisk的檢測規則爲檢測loadClass函數的調用。
由於檢測點不一樣無法判斷具體的漏報和誤報。
4.8 AES/DES弱加密
表4-9 AES/DES弱加密分析結果
誤報 | 漏報 | |
360 | 0 | 1 |
金剛 | 無檢測 | 無檢測 |
阿里 | 0 | 未知 |
百度 | 14 | 未知 |
AppRisk | 0 | 1 |
該項金剛不會檢測，而360和AppRisk都沒有檢測出AES/DES弱加密風險，都漏報了1個。而百度卻檢測出15個弱加密風險。經過分析，我猜測百度只是檢測是否包含AES或者DES，並沒有判斷加密模式是否爲ECB，使用其他加密模式是不存在安全隱患的。而阿里正確檢測出1個，因此我的結論是百度誤報14個漏洞，360和AppRisk漏報1個。
4.9 WebView組件系統隱藏接口漏洞
表4-10 WebView組件系統隱藏接口漏洞分析結果
誤報 | 漏報 | |
360 | 0 | 未知 |
金剛 | 9 | 2 |
阿里 | 0 | 未知 |
百度 | 0 | 4 |
AppRisk | 27 | 3 |
360沒有掃描出WebView隱藏接口漏洞，原因未知。
金剛誤報了9個，而且還有2個漏洞漏報；百度漏報了4個漏洞，只正確找出1個。通過之前的掃描能力分析我可知，金剛可能僅僅是尋找是否有使用了WebView，而沒對WebView是否啓用了JavaScript進行檢查，所以誤報率很高。百度沒有誤報，但漏報很多，可能是百度沒有判斷WebView是否啓用了JavaScript，所以本着減少誤報的原則，只報告百分之百確定的漏洞。
AppRisk的檢測規則可能非常簡單粗暴，僅僅檢查loadUrl來確定是否使用了WebView，因而誤報率很高。
阿里可能首先判斷WebView是否允許JavaScript運行。只有在JavaScript允許運行時移除隱藏接口才有意義；然後如果JavaScript開啓，那麼就判斷WebView是否移除了“searchBoxJavaBridge_”、“accessibilityTraversal”以及“accessibility”這3個接口。如果都移除了才安全。所以阿里漏報和誤報都很低。
五、總結和展望
通過此次評測，我基本瞭解了目前國內移動安全掃描平臺的發展狀況，瞭解了主流掃描平臺的檢測能力，包括掃描項、漏洞的檢測規則等。我發現沒有一家掃描平臺可以覆蓋所有的安全漏洞和風險。
相對來說， AppRisk掃描速度最快，掃描結果展示更加專業；360和金剛作爲老牌的掃描器，儘管掃描速度慢了一點，但掃描能力和結果展示也比較不錯；阿里聚安全的掃描項覆蓋廣一些，漏報和誤報率較低，檢測結果更加可信一點。百度作爲其中唯一一家收費的掃描平臺，在某些掃描項的掃描能力上處於領先位置，掃描速度也比較快。總之，五家掃描平臺在競爭中互相學習，取長補短。
Reference：
［1］ 阿里聚安全 http://jaq.alibaba.com/
［2］ 360APP漏洞掃描 http://dev.360.cn/mod/vulscan/
［3］ 騰訊金剛審計系統 http://service.security.tencent.com/kingkong
［4］ 百度移動雲測試中心 http://mtc.baidu.com/startTest/safe
［5］ AppRisk Scanner https://apprisk.newskysecurity.com
Sunnieli