所謂移動設備應用的灰盒測試是指，將傳統(tǒng)的源代碼檢查(白盒測試)與前期測試(黑盒測試)結(jié)合起來的一種技術。測試人員必須檢查應用程序的代碼庫，審查關鍵功能代碼，審查常見的錯誤編碼或非法編碼方法。此外，測試人員還可以執(zhí)行黑盒測試來審查應用，并根據(jù)所確認的漏洞定位找到代碼庫中的目標代碼。

為什么要執(zhí)行移動應用的灰盒測試與評估呢?答案很簡單：找到高風險代碼;確認漏洞的根本原因。

灰盒測試應當遵循如下三大步驟：

一、威脅建模

威脅建模可以使測試團隊首先確認有可能對移動應用產(chǎn)生最大影響的威脅。測試人員在這個階段的主要目的是區(qū)分特定應用組件或代碼的優(yōu)先順序。測試團隊通過理解應用程序架構的文檔資料，應當逐漸熟知移動應用的基本架構和使用情況。

收集信息

通過與移動應用的開發(fā)團隊協(xié)作，測試團隊應當獲得有助于幫助其理解移動應用的設計和功能的文檔資料。這些文檔資料中所描述的細節(jié)，可以為威脅建模過程中的所有步驟提供基礎。

執(zhí)行偵察和應用映射

理解移動應用如何實現(xiàn)其功能對于創(chuàng)建移動應用模型至關重要。在此階段，測試團隊應當人工檢查移動應用的實例。然后，團隊應當檢查移動應用的匿名部分和認證部分，同時關注處理敏感數(shù)據(jù)和功能的部分。在此階段，要提供架構、配置、過程、用戶、技術等各方面的證明文件，以利于下一階段的使用。

需要重點關注并用于下一階段針對性測試的方面有：管理界面、敏感信息的傳輸、外部或第三方應用的接口、移動協(xié)議(如SMS、MMS、WAP等)的使用。

測試團隊應當記錄在此期間的每一種請求和響應，以便于使用本地代理工具和網(wǎng)絡嗅探工具進行日后分析。

定義系統(tǒng)和可信邊界

在檢查的下一階段，評估團隊應當構建一個移動應用及數(shù)據(jù)流程圖中的系列過程的可視化模型。數(shù)據(jù)流程圖要確認系統(tǒng)邊界和圍繞移動應用的每一個組件的可信邊界。確認系統(tǒng)邊界可以使測試團隊初步明確數(shù)據(jù)流入或流出系統(tǒng)或其組件(即數(shù)據(jù)入口和出口點)的所有位置。隨后，在代碼檢查階段，測試團隊應當檢驗在每一個系統(tǒng)邊界是否執(zhí)行了適當?shù)尿炞C和編碼技術。與此類似，確定可信邊界可以查明測試團隊能夠檢驗代碼中的認證和授權部分。

將威脅映射到功能

在定義了所有的流程圖要素后，測試團隊應當將所有要素映射到資產(chǎn)威脅，其目的在于定義移動應用中的“熱點”，進而可以構建一個測試計劃。在針對性的代碼檢查階段，測試團隊應當全面測試計劃中的每一個項目。#p#

二、漏洞確認

在應用程序的評估過程中，應當重點檢查前一階段所確認的熱點源碼。除了要檢查源代碼檢查不易發(fā)現(xiàn)的應用程序漏洞，企業(yè)還應當執(zhí)行黑盒類的評估，用以確認網(wǎng)絡或主機層的漏洞。為了補充應用程序組件的人工檢查，這個測試階段應當采用自動化的掃描。

代碼分析和掃描

自動化掃描工具可以分析全部源代碼，從而初步發(fā)現(xiàn)安全問題。在此階段，測試者應當利用商業(yè)類工具和私有工具來掃描有安全問題征兆的代碼和可導致漏洞的常見編程錯誤。源代碼分析階段應當設法確認可影響到主機、服務器和網(wǎng)絡的漏洞。

人工分析

在此階段，我們建議詳細檢查應用程序的代碼，其目的是為了發(fā)現(xiàn)應用程序架構所獨有的安全漏洞。在檢查代碼時，建議將以下幾種技術結(jié)合使用：

1、許可分析：許多平臺要求移動應用聲明在執(zhí)行期間試圖訪問哪些功能。然后，設備將對應用程序限制使用這些特定的功能。測試人員可以針對這些功能發(fā)動攻擊，并嘗試繞過這些限制，以檢驗其效果。

2、控制流分析：該技術用于分析代碼中的邏輯條件。這種方法可以使測試人員確認常見的邏輯漏洞，例如，程序無法處理例外、不適當?shù)氖跈嘞拗频取?/p>

3、數(shù)據(jù)流分析：該技術跟蹤從輸入點到輸出點的數(shù)據(jù)，尤其適用于確認常見的輸入驗證錯誤，如SQL注入和跨站腳本利用。

為應用這些技術，我們建議企業(yè)將移動應用分割成不同的功能組件。測試者應當檢查每一個組件，以查找常見的不安全的編程方法，這些方法包括：

1、認證：弱口令要求、用戶名窮舉、賬戶停用、cookie重放攻擊、后門等。

2、授權：特權提升、不適當?shù)臋嗔Ψ峙?、機密數(shù)據(jù)的暴露、數(shù)據(jù)受損等。

3、會話管理：會話陷阱、會話超時、會話劫持、不適當?shù)臅捊K止、會話重放、中間人攻擊等。

4、配置管理：對管理界面的非授權訪問、對配置文件的非授權訪問、配置數(shù)據(jù)的檢索、分配給過程和服務賬戶的過多特權。

5、輸入驗證：參數(shù)損害、緩沖區(qū)域溢出、跨站腳本攻擊、SQL注入、XPATH劫持、命令劫持等。

6、數(shù)據(jù)保護：對移動應用或用戶的私密進行硬編碼、網(wǎng)絡通信嗅探、錯誤的密鑰生成或密鑰管理，弱加密等。

7、例外處理：信息泄露、拒絕服務等。

8、審計和日志：日志偽造、操縱日志文件、日志文件破壞等。

9、緩存：在移動應用的生命周期內(nèi)，擊鍵、快照、剪貼板內(nèi)容和文件有可能被緩存到設備的不同存儲位置。

10、發(fā)布通知：將數(shù)據(jù)從服務器傳輸?shù)綉谩?/p>

11、基于位置的服務：試圖泄露或欺騙位置數(shù)據(jù)。

此外，還有以明文形式將口令存放到數(shù)據(jù)庫中等。

檢查代碼中的架構安全問題

如果應用程序使用了特定的安全機制，或者具備可以減輕某些“臭名昭著”的安全威脅的功能，這一步就相當重要了。最后的代碼檢查用于驗證應用程序架構的特定安全功能：

加密：由于定制的加密方案一般都沒有強健的加密機制，所以企業(yè)應當檢查方案，以驗證其是否可以對敏感數(shù)據(jù)提供充分的保護。

協(xié)議：測試人員應當檢查應用通信的私有協(xié)議，用以決定其應對破壞和偵聽的能力。

會話管理：測試者應檢查如下兩方面，一是創(chuàng)建特定會話標識符的企圖，二是會話管理進程。這樣做的目的是為了衡量其會話發(fā)生管理錯誤時的保護能力。

訪問限制：測試者要檢查特定HTTP頭的使用或者其它的特定協(xié)議要素，用以控制訪問，防止未授權的訪問。

安全代碼：有些代碼是為解決以前所發(fā)現(xiàn)的安全問題而編寫的，對此測試者要專門檢查，以檢驗其功效。

服務器架構：測試者要檢查用來支持移動應用的外部Web服務和服務器。#p#

三、漏洞利用

在這個階段，測試者必須制定測試計劃，其目的是為了對源代碼進行深入分析，查找是否存在常見的不安全編碼方法。然后，重點檢查移動應用的特定安全機制。測試者還要查找、檢查代碼中的架構安全問題。

驗證所確認的問題

測試團隊要分析來自漏洞掃描的結(jié)果，去掉那些似是而非的信息，并著手構建可利用漏洞的案例。

利用移動應用的獨有功能

灰盒測試方法的主要好處是能夠最大限度地利用漏洞。在此階段中，測試者要嘗試利用在移動應用的實例中表現(xiàn)不明顯的認證漏洞和授權漏洞。這些漏洞可能會導致對功能或數(shù)據(jù)的非法訪問，并給企業(yè)帶來巨大風險。測試者還要利用業(yè)務邏輯(用于控制用戶如何在移動應用中執(zhí)行操作)中的缺陷。這些缺陷一般被用于欺詐移動應用的用戶或公司。

將漏洞利用與源代碼聯(lián)系起來

在測試者證明了可利用的漏洞后，就要將可利用的漏洞與相關的特定代碼部分聯(lián)系起來。這可以使開發(fā)人員快速地理解問題，并可以評估進行漏洞修復需要花費的工作量。

分析風險

測試者要評估可利用的漏洞，并根據(jù)每個漏洞給公司帶來的風險，對漏洞進行評級。對于漏洞，測試者還要評估在漏洞被利用后，它可能對公司造成的影響。如果測試者能夠利用多個漏洞并帶來更大的影響，那么這種分析就具有多重意義。

提供具體的技術建議

在評估了每個可利用漏洞的風險后，測試者要給出移動應用架構和代碼編寫的具體建議，如果可能最好包括源代碼。然后，開發(fā)者就可以利用這些建議來減輕或修復漏洞，從而減少應用風險。測試者的建議還可以提供安全的編碼指南，用以解決或修復移動應用的漏洞。

在這里提出幾條移動安全的建議，供開發(fā)者和測試者參考：把移動安全理念納入到開發(fā)項目中;構建并實施一種可以監(jiān)管移動應用的開發(fā)并確?？衫斫庑缘牟呗?培訓移動應用的開發(fā)人員，幫助其實施安全的編碼;測試是否可以限制傳輸?shù)揭苿釉O備的敏感數(shù)據(jù);評估針對Web應用和基礎架構的威脅。