作者 | 陳峻

審校 | 重樓

眾所周知，智能手機、平板電腦和智能手表等開放性移動智能設備，以其帶有豐富的擴展性功能（如：麥克風、攝像頭、地理位置等）和可訪問到廣泛的數據源（如：電子郵件、協作文檔、社交媒體等），正在我們生活的方方面面被頻繁使用。然而安裝在移動設備上的、那些長久沒能更新的移動應用（Mobile APP）往往潛藏著移動代碼缺陷、API保護不到位、以及配置錯誤等安全薄弱環節，也可能導致APP的用戶前端、甚至其對應的服務后端，受到針對財務數據的攻擊和用戶隱私的侵犯。

近年來的一項大規模的調查發現，全球有四分之三的移動應用至少包含了一個中等級別的安全漏洞。因此，我們需要警鐘長鳴，通過開展持續的靜、動態分析和滲透測試等方式，對已經在用和即將上線的移動應用開展全面的安全測評（MAST），以免遭不必要的攻擊。下面，我們將從移動應用的攻擊類型，安全構建和上線測評三個方面，和你進行深入討論。

一、移動應用攻擊

針對移動應用的典型攻擊類型有如下三種：

• 基于瀏覽器的攻擊，即攻擊者使用過時的瀏覽器、或不安全的瀏覽活動，將惡意軟件注入到移動設備上。
• 基于短信（SMS）的攻擊，即攻擊者通過傳送與APP相關的、包含惡意鏈接的短信，誘騙用戶點擊，進而在后臺將惡意代碼下載到移動設備上。
• 基于應用邏輯的攻擊，即攻擊者直接利用APP的代碼漏洞或邏輯錯誤，繞過身份驗證機制，滲透到移動系統上，未經授權地訪問甚至竊取數據。

二、移動應用安全構建

為了讓移動應用免受上述各類攻擊，我們需要事先設計APP的業務邏輯，了解漏洞可能出現的位置，以及設計優化數據的調用關系。如下移動應用安全構建要點，可以幫助你構建更安全的移動應用。

1.應用設計

移動應用里往往需要包含API、加密密鑰、OAuth令牌、信任密碼、以及緩存個人身份信息。而攻擊者會想盡辦法進行破解、克隆、甚至篡改。為此，在移動應用設計時，我們應創建源代碼策略，包括：通過身份驗證和授權來控制訪問，加密和監控靜態敏感數據，使用私密網絡或SSH安全傳輸數據，以及采用日志、水印等數據泄漏防護（DLP）措施。

2.安全編程

3.身份驗證

在身份驗證的方法上，我們除了采用包括OAuth2.0、OpenID Connect和安全斷言標記語言（SAML）等開放標準，也可以運用不同方式的多因素身份驗證（MFA）解決方案。其中包括：

• 基于移網推送的一次性密碼（OTP）驗證：一旦使用此機制，攻擊者就算獲取到了也無法重復使用它。不過，我們難以認證從移動網絡運營商處發來的短信的可靠性。
• 離線基于時間的一次性密碼（TOTP）驗證：該機制綜合了時間和密碼兩個維度。雖然它不需要新增硬件，但如果攻擊者克隆了該機制，便可以生成新的TOTP代碼，進而侵占授權用戶。
• 硬件令牌：該機制將基于硬件的身份驗證與公鑰加密相結合，使其難以泄露。當然，我們需要避免用戶使用相同的令牌訪問多個賬戶的違規行為。
• 軟件令牌：作為一種數字身份驗證密鑰，該機制需要安裝在單獨的軟件或集成到應用中。不過，由于它需要依賴互聯網連接和軟件才能工作，因此仍然存在被遠程攻擊的可能。此外，我們需要在登錄嘗試失敗一定次數后，實施賬戶鎖定策略，以提高注冊與登錄過程的安全性。這些都是細化保護規則與流程的安全實踐。

4.加密通信

通過基于會話的密鑰交換或4096位SSL密鑰的形式，對移動通信通道實施強加密，以抵御黑客滲透到公共網絡或WiFi網絡的通信中。

SSL證書的優勢在于，它可以在應用中對證書的公鑰進行硬編碼，并在不依賴第三方證書頒發機構的情況下，啟用服務器身份驗證，抵御中間人攻擊（即攻擊者通過提供虛假證書來攔截數據）。

5.API安全

移動應用的安全性離不開內部創建與集成API。其中涉及到API文檔、編錄、發現、密鑰、驗證授權、日志記錄、調用監控、限流、以及運行時的保護。此外，我們還應采用REST等安全的API框架，并實施最小權限原則（PoLP）。

6.RASP

通過在應用程序的運行過程中采用“插樁”技術，實時應用的自我防護（RASP）可以將安全技術鏈接到應用環境中，通過自動監控應用在使用時的行為，借助其上下文情景分析能力，實現針對：帳戶接管、設備越獄、逆向工程、以及注入鉤子等攻擊的無人工干預式防御。

事實證明，RASP的這種跨設備與平臺的應用兼容性，可以讓移動應用具備實時監測，阻斷攻擊和自我保護的能力。

7.數據存儲

移動應用可遵循的應用數據安全存儲與使用方式包括：

• 關閉提示在設備上存儲密碼的選項，以便除設備所有者外，他人無法訪問到移動應用中的數據。
• 密碼不可以純文本的形式存儲，須始終采取哈希和加鹽（即：在哈希之前，將一個稱為“鹽”的隨機字符串附加到密碼中，確保生成的每個哈希值都是唯一）處理。
• 使用開發語言內置的加密庫，來用于對密碼進行哈希和加鹽處理的函數。

8.代碼混淆

代碼混淆技術可以將移動應用變更為功能相同、但無法辨識和解讀的格式，使其不易被攻擊者破解分析和逆向利用，進而有效地防范了核心代碼的泄露、以及數據被篡改。

9.日志監控

嚴格的審計跟蹤和行為監控，可以密切關注移動應用的用戶訪問和數據修改，進而為日志分析和事件取證提供有利的證據。

三、移動應用安全測評

雖然已有前期的移動應用安全構建，我們仍無法保證移動應用被安裝和運行在Android、iOS、Windows Mobile等移動操作系統上，不存在漏洞和風險。對此，我們可以參照OWASP移動應用安全測試指南等權威指導，開展深入的安全測評。

1.測評工具

目前，最常推薦的移動應用安全測評工具包括如下類型：

• 靜態應用安全測試（SAST）工具：掃描應用的源代碼，以識別漏洞。此類工具可以在CI/CD管道的早期運行，甚至可以在編程時作為IDE插件運行。SAST屬于白盒測試，因此也會檢驗應用內部設計。
• 動態應用安全測試（DAST）工具：通過測試正在運行的應用，是否存在常見的受攻擊類型，來檢查其運行時的安全性。由于此類工具需要應用正常運行的狀態，因此只能在開發過程的后期使用。DAST屬于黑盒測試，因此只會基于外部認知，而不考慮應用的內部知識。
• 交互式應用安全測試（IAST）工具：通過從外部掃描應用和對內部應用流進行分析，以便在其運行時檢查應用的安全性。IAST 是白盒和黑盒測試的混合體，能夠像SAST工具那樣開展，并將類似DAST的結果（如，回歸識別）對應到源代碼上。
• 軟件組件分析（SCA）工具：根據第三方代碼的依賴關系，開發人員可以使用此類工具，來發現與應用相關各種組件、開源支持庫、及其直接和間接的依賴項，進而挖掘出可能存在的被利用的漏洞。
• 模糊測試工具：會自動將各種無效或意外的輸入注入到應用中，以發現錯誤。作為一種黑盒測試技術，模糊測試旨在讓應用到達可承受的極限，從而導致其行為異常、崩潰、或出現資源泄漏。

2.測評方法

目前業界比較流行的針對移動應用安全測評方法有：

• 自動測評：由自動化工具掃描應用代碼，以查找潛在的漏洞，使開發團隊能盡早識別到安全風險。此類測評的優勢在于速度、準確性、可擴展性、以及成本效益。
• 手動測評：由人工測評人員手動與應用交互，以識別漏洞。此類測評最適合用于檢測那些更高級別、更抽象的應用問題，例如，應用設計的缺陷和業務邏輯的錯誤等。
• 漏洞賞金計劃：通過向能夠識別和披露移動應用漏洞的安全研究人員和道德黑客提供金錢獎勵，來及時發現潛在的安全漏洞，并激勵改進措施的提供。
• 眾包漏洞披露：與漏洞賞金類似，不同之處在于安全漏洞是被公開發布的，而不是私下提交的。此類披露有時包括提供給開發人員如何修復漏洞的建議。在移動應用的實際安全測評中，企業經常會綜合利用上述方法。例如，許多組織會先使用自動化工具進行大部分的測評，然后讓安全人員進行人工審查，以剔除誤報，并了解背后的具體邏輯。與此同時，他們也會持續提供漏洞賞金計劃，并加入眾包漏洞披露，以增強漏洞的發現與處置能力。此外，作為全面的安全技術棧，移動應用安全測評的補充策略還包括：威脅建模、合規性測試、以及紅隊模擬攻擊等。

3.測評挑戰

雖然我們可以靈活選用上述提到的不同安全測評方法與工具，但是在實際操作中可能會遇到如下挑戰：

• 當移動應用在各種不同的操作系統和設備上運行時，會出現平臺“碎片化”的現象。也就是說，為了滿足測評的覆蓋面，我們不僅需要在不同的平臺上開展，甚至需要在同一操作系統的不同版本上也要進行測評。這對于針對Android平臺開發的移動應用來說十分常見，畢竟不同的第三方制造商往往擁有自己獨特的操作系統版本。
• 當被選用的測評工具集無法支持諸如：Java、Kotlin、Objective C以及Swift等獨立于平臺的語言時，開發語言的覆蓋率便成了挑戰。顯然，對于混合移動應用而言，原生開發與由Web應用開發帶來的安全風險是不盡相同的。
• 由于許多DAST測試框架并非面向移動應用的安全性而設計，因此盡管各種框架仍在改進中，但是目前尚難以獲得全面的針對移動應用的測評數據。

4.測評流程

一套完整的移動應用安全測評流程，通常由如下關鍵步驟組成：

• 定義目標：明確定義待測評移動應用的安全目標，需重點關注特定于移動設備的數據保護、安全數據傳輸和用戶隱私等安全需求。
• 信息收集和規劃：從測評方的角度收集有關信息、按需檢查應用的運行環境、設計、功能和源代碼，并據此來規劃后續的安全測評工作。
• 選擇工具：根據數據加密、身份驗證與授權機制、以及特定于移動設備的API等因素，選擇針對待測應用的適當測評工具。
• 確定方法：通過討論，確定是從內部人員角度（白盒）、還是從外部人角度（黑盒）評估移動應用。應重點關注特定于移動設備的漏洞和用戶數據保護。
• 自動工具掃描：對自動化工具進行基本配置，全面掃描并發現待測應用的漏洞。
• 手動測試與核實：測評人員根據定義的范圍和選擇的方法，對待測應用執行深入的手動測試，進一步發掘并核實漏洞。
• 滲透測試：模擬現實世界的攻擊，重點關注與移動應用交互的后端服務和API的安全性，例如：不安全的數據存儲、不適當的身份驗證、API或云服務的錯誤配置、以及特定移動設備的風險等。其間，測評人員應遵守基本的道德準則。
• 分析結果：根據測評過程所發現的漏洞，針對用戶數據安全和隱私的影響，分析并確定漏洞的優先級。
• 形成報告：測評人員根據上述結果，創建一份詳細的、對開發人員友好的報告。該報告將包括發現的所有漏洞、嚴重性、以及如何整改的參考。
• 實施整改：開發人員通過實施必要代碼修復與邏輯整改，解決特定于移動應用的安全漏洞，增強其安全態勢，并保護用戶數據。
• 重新測試：測評人員開展對整改后移動應用的重新測評，以避免應用“帶傷”上線。
• 記錄所有內容：全面記錄整改內容、復測結果、補救措施，以滿足合規性要求，并為下一輪測評提供參考。
• 定期測評：測評人員應定期對移動應用開展安全測評，特別是在移動應用發生重大更新或變更后，以維護用戶數據和應用程序本身的安全。

5.優秀實踐

雖然我們執行移動應用的具體方法與流程，會根據本系統和應用的獨特性不盡相同，但是如下根據行業經驗總結出的優秀實踐，仍值得你參考，并有助你避開坑點：

• 將移動應用的安全測評整合到現有的移動CI/CD管道中，以體現諸如盡早改善安全態勢和集成，以及降本增效的安全左移優勢。
• 參照OWASP 移動應用安全測試指南，建立符合實際的安全測試框架，以及時發現和解決各種常見的典型安全問題。
• 針對不同類型的移動應用和不同的使用場景，綜合采用上述提到的SAST、DAST和SCA等多種測試方法。
• 鑒于安全態勢只是一時，而非一段時間，因此需要團隊中形成定期測試的機制，即：對于一段時間未發生重大變更的移動應用，可引入每半年或每季度開展測評的“底線”，以識別該周期內新披露的漏洞。
• 選擇具有互補功能的自動掃描工具，以確保其適合你的CI/CD管道，涵蓋必要的移動應用編程語言，并降低誤報率。
• 請不要忽視移動應用的后端安全性。即使已測試了前端應用的安全性，也需要測試其連接的后端的代碼、配置、所處的環境、數據交換的鏈路等安全性。
• 鑒于移動終端的多樣性，應盡可能多地在不同設備上測試移動應用的安裝與運行，可考慮使用自動化來提高此過程的效率。

譯者介紹

陳峻（Julian Chen），51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗。