避免手機App安全陷阱 (下)

保護開發生命週期

手機App安全測試是安全生命週期的主要組成部分。在進行測試之前，為App創建一個範圍文檔，列出使用的權限、數據的敏感級別和使用案例是很有用的。例如，該App是在消費者可以下載的商業App商店中發布，還是在受管理的移動設備上運行，應使用此訊息來確定團隊將花費多少時間來確保App的安全以及可以使用哪種額外的保護。此外，必須執行威脅演練。

執行App安全測試

為了確保遵循安全編碼最佳實踐並識別App中引入的任何漏洞，企業應該對App進行安全測試。請記住，手機App由兩部分組成：駐留在移動設備上的App和後端。手機App安全測試有兩個級別，第一個靜態分析手機App的資源（設備上的部分）、字節或二進制碼，此測試將允許出現不安全儲存等問題，在OWASP Mobile Top 10可以作為這個階段最低限度識別列表，SRM 領導者應確保測試整個App，包括它可能使用的任何資料庫。 

手機App開發的一個特點是，即使是最成熟的組織也會以 DevOps 方式進行開發，App通常會在一個業務範圍內編寫，並且每週都會更新，這需要一個易於運行且快速提供結果的手機App安全測試解決方案。移動 AST 的第二層不僅包括駐留在移動設備上的程式碼，還包括它與（一個或多個）後端的交互組成，一些供應商將提供第一級作為免費服務，第二級作為付費服務。

對於關鍵App，組織應定期執行滲透測試，此練習可以識別自動化解決方案可能無法識別的風險。例如，App或其後端可能容易受到特定技術（例如 API 抓取或密碼散播）的攻擊，而自動掃描程序可能無法運行這些技術，這項工作應注重於App的業務邏輯。

外部化安全控制

除非有重要的內部安全知識，否則組織應避免創建和實施自己的安全控制。手機App中發現的大多數安全問題都與加密、身份驗證和其他安全功能的錯誤實施有關。SRM 領導者應該識別和標準化關鍵安全組件，觀察現有的多體驗開發平台和訪問管理解決方案的功能，例如完整性檢查、jailbreak/root檢測、認證授權、符號化和加密。MX 平台和 Git 環境還可以幫助設定和管理App開發和部署過程。 

一些擁有足夠內部專業知識和資源的組織已設法在內部正確構建其安全控制。在走這條路之前，請仔細考慮您可以長期投入的努力，隨著時間的推移，新的攻擊和威脅以及相應的新防禦措施的出現，控制將變得過時且效率低下，需要持續的維護，這可能會變得不堪重負。事實上，我們觀察到組織已經建立了自己的控制，只是不得不拆除它們並尋找外部功能。對於部分App，某些安全功

能可以通過 UEM 工具提供和標準化。

在必要時，超越基礎安全控制

當必要時，SRM 領導者可能需要超越目前的安全控制。要確定這些措施的候選App，需要尋找以下三項：

該App含高度敏感的數據或可用於交易。

該App是公開的。

該App有很大一部分的軟體邏輯駐留在設備上。

針對逆向工程強化App

在商業App商店上發布的App，經常是逆向工程的受害者。攻擊者對App進行逆向工程，以了解App的工作原理和攻擊方式，竊取App內的數據，並複製App。在最後一種情況下，也稱為“重新打包”，攻擊者添加惡意行為，然後重新發布App。不知情的使用者可能認為他們正在下載和使用合法的App，例如不小心交出了他們的銀行憑證。App強化可以使攻擊者更難對App進行逆向工程。

程式碼混淆

為了防止重新打包，SRM 領導者可以使用程式碼混淆。混淆會打亂（而不是加密）程式碼，從而更難審查和重新利用程式碼。

混淆是一種勸阻措施。在大多數情況下，堅定而熟練的攻擊者將能夠重構App，但投入的精力和時間可能不值得。

白箱加密法

該術語是指用於隱藏和保護敏感App數據（例如儲存在設備上的App中的密鑰和憑證）的一組技術。當有人不想依賴本機資源（例如「避免手機App安全陷阱-上」提到的 iOS 鑰匙串）時，可以將其用作替代方案。為提高採用率，組織希望允許其App在越獄設備上運行，而越獄設備無法從 iOS 鑰匙串保護中受益時，就會出現這種情況。在其他情況下，白箱攻擊的基本原理是攻擊者將設備上憑證的預設位置視為嘗試攻擊的第一個位置。因此，儘管憑證儲存在設備上具有所有防禦措施，但將憑證移動到其他地方可以避免這些攻擊。

手機App監控

為完整起見，針對逆向工程強化App的替代或補充方法是尋找App的修改和複製版本。

通過防篡改控制驗證環境是否可信

公開的App需要能夠驗證它們運行的設備是否可以信任，以及可以信任到什麼程度。為此，SRM 領導者可以向App添加防篡改控制。除了檢查jailbreak或root之外，典型的功能是檢查debugger（進行逆向工程時使用的工具之一）或模擬器的存在。