彌合應用安全差距：超越基本安全實踐

當我們與安全專家討論應用程式保護時，我們會得到各種各樣的回饋，包括：

“我們的系統架構採用了關注點分離原則，我們使用安全的編碼實踐，並且我們進行 SAST/DAST 測試，所以我們沒問題。”

至

“儘管我們採取了所有其他保護措施，但當我們意識到修改後的行動應用程式對我們的後端系統構成威脅時，我們實施了新的措施來減輕這種威脅並提高我們的整體安全態勢。”

如果您更傾向於第一種說法，我們想向您推薦… 這篇文章 本文闡述了應用程式——即使是經過安全開發和測試的應用程式——也可能被惡意利用，攻擊為您的客戶創造最大價值的後端系統。如果您認為應用程式需要採取超出必要良好實踐的保護措施，請繼續閱讀本文。

保護應用程式免受逆向工程和篡改的主要方法有幾種。本文將探討在應用程式建置完成並準備提交到相應應用程式商店之後所採取的保護措施。我們討論的方法包括封裝器、SDK 和程式碼注入。首先，我們將簡要介紹一個標準安全框架，以便評估這些技術。

OWASP MASVS 彈性概述

OWASP行動版 Application Security 驗證標準（MASVS）概述了四項內容 韌性類別 這些旨在加強行動應用程式抵禦各種安全威脅的措施。它們著重確保應用程式即使在遭受攻擊時也能保持安全。雖然這些措施專門針對行動設備，但它們也為所有在終端用戶設備上透過網路運行的應用程式提供了一個良好的框架。透過遵循這些彈性準則，開發人員可以創建更難被逆向工程攻擊且更能保護使用者資料的應用程式。

• MASVS-RESILIENCE-1：此應用程式驗證平台的完整性。
• MASVS-RESILIENCE-2：該應用程式實現了防篡改機制。
• MASVS-RESILIENCE-3：此應用實現了抗靜電分析機制。
• MASVS-RESILIENCE-4：該應用程式實現了反動態分析技術。

現在，讓我們深入了解防護技巧。

包裝

封裝器是一種應用程式保護機制，它為應用程式提供一道防線。使用封裝器時，需要對應用程式進行編碼，新增對應的解碼例程，然後在執行原始應用程式之前執行該解碼例程。由於程式碼被重寫，這種保護機制僅適用於允許程式碼自修改的平台。

這種保護方式的優點在於無法直接進行靜態分析。反彙編器、反編譯器和人類都無法理解包裝器下的程式碼，因為它已轉換成無意義的位元組序列。因此，包裝器符合 OWASP MASVS-RESILIENCE-3 控制要求。然而，包裝器觸發的解碼例程本身就是普通程式碼，可以被反組譯、反編譯並被理解，它們的存在本身就向攻擊者表明使用了包裝器。

即使無法對應用程式進行靜態分析，攻擊者也只需啟動（“運行”）該應用程序，等待原始程式碼恢復即可。之後，他們就可以複製並反彙編或反編譯原始程式碼。因此，即使是新手攻擊者也很容易繞過此類保護措施。

那麼，為什麼公司要銷售封裝器，應用程式開發者又為什麼要使用封裝器呢？封裝器易於實現，並且能夠有效抵禦靜態分析。這種易於實現的特性使得公司能夠快速且低成本地進入應用程式保護市場。這些公司隨後可以將目標客戶鎖定在那些只需要應用最基本安全保護的客戶群。

保護應用程式所需的時間極短，通常無需任何配置。然而，由於所有保護措施都使用相同的解碼例程，因此這類保護措施通常容易受到 BORE（一次破解，處處運行）攻擊。

有防護總比沒有防護好，但我們可以做得更好。

軟件開發工具包

隨著我們從安全性最低的解決方案逐步過渡到安全性更高的解決方案，應用程式安全發展的下一步是保護型SDK模型。在此背景下，SDK是一個獨立的程式碼模組，其中包含針對一種或多種威脅的保護和偵測功能。例如，保護型SDK可以包含用於確保平台完整性的邏輯，例如檢測已root或越獄的設備，以及透過檢測偵錯器或Frida等分析工具來阻止動態分析。

在建置/保護階段，保護 SDK 會綁定到被保護的應用程式。與封裝方案類似，SDK 會插入到應用程式的入口點，以便啟動一個或多個執行緒在背景執行偵測。之後，原始程式碼無需與 S​​DK 互動即可運行。

通常情況下，運行時不會對原始程式碼進行任何修改——因此，這種解決方案的各種變體可以應用於任何平台。但由於原始程式碼未被修改，即使它可能能夠抵抗動態分析，也容易受到反彙編器和反編譯器的靜態分析。這種方案的弱點在於，如果保護 SDK 可以被移除，那麼應用程式的其餘部分就可以在沒有任何保護機制的情況下運作。

由於涉及的邏輯更多，企業通常需要更多的時間和成本來開發基於SDK的安全防護產品——但遠不及程式碼注入防護產品所需的時間和成本。在這種情況下，防護步驟也很簡單，通常無需任何配置。

因此，SDK 滿足 MASVS-RESILIENCE-1、2 和 4 的要求。然而，與封裝器類似，保護型 SDK 也常常容易受到 BORE 攻擊。雖然可以透過額外的機制將 SDK 與應用程式綁定，但這通常需要進行一些應用程式分析，這會增加產品開發的難度，並可能導致綁定錯誤。

代碼注入

程式碼注入安全產品是這三種技術中的佼佼者。需要注意的是，在前兩種情況下，保護程式碼都在應用程式執行之初運行，這使得它們最容易被發現、分析和破解。

程式碼注入場景的核心思想並非僅僅是封裝或添加一個SDK，而是要分析應用程序，充分理解其控制流，然後在整個應用程式中添加保護機制，使其在受保護的應用程式運行時於後台運行。 保護機制 可以包括平台完整性檢查，以防止程式碼在越獄或已root的裝置上運行；反靜態分析機制（如混淆）；反動態分析機制，以檢測偵錯器和動態插樁工具包；以及防篡改機制，以確保運行的應用程式與發布的應用程式相同。

由於這些技術分散在程式碼中，因此很難找到，這確保了威脅行為者必須花費更多的時間和精力（通常是徒勞無功的）來嘗試擊敗它們。

這項技術的另一個優點是，一旦將保護機制注入程式碼，它們就可以根據需要重複進行深度保護。透過建立足夠龐大的保護機製網絡，應用所有者可以顯著增強應用的安全性，打造一個具有自我感知能力的“謎題”，透過可見和不可見的行動來阻止潛在的攻擊者破解謎題。

此外，由於保護程式碼分散在整個應用程式中，因此實際上是隱藏的，這意味著某些檢測可以採取隱藏的、自訂的操作（如果安全產品允許的話），從而對應用程式的行為進行細微的更改，威脅行為者可能會完全忽略這些更改，從而增加他們的挫敗感，並阻止他們達到目標。

讓攻擊者感到沮喪，可以迫使他們放棄攻擊防護嚴密的應用程序，轉而尋找防護薄弱或未受保護的應用程式。你無需徹底擊敗對手，只需讓他們放棄並轉向其他目標。

為了完成比較分析，程式碼注入保護工具提供了最全面的保護，可以抵抗靜態和動態分析，從而滿足 MASVS 彈性的所有 4 項要求。

这 Digital.ai 差異

比較這些保護技術可以清楚地表明一點：沒有任何單一方法能夠提供全面保護。建立真正的應用程式彈性需要在整個軟體生命週期中採用協調一致的防禦措施和自動化流程。 Digital.ai Application Security 提供該解決方案。

• 一個可自動化發布流程並整合複雜工具鏈的平台。統一應用交付，整合現有工具，並可在任何環境中擴展。
• 可擴展的自動化行動應用測試和安全解決方案。透過更完善的自動化測試和應用保護技術，提供安全、高品質的應用。
• 在所有軟體交付工作流程中內建人工智慧、智慧、合規性和治理功能。集中數據、優化流程並獲得增強的洞察力，從而加快交付速度。 safer 軟體交付