Web3攻擊面:滲透測試概覽

本系列的前三篇文章闡述了為何加密機構需要區塊鏈滲透測試（第一部分）、這門學科所驗證的內容（第二部分），以及機構層面的測試工作應如何安全地準備與執行（第三部分）。

本文概述了與 web3 機構滲透測試相關的攻擊面，並特別關注所需的覆蓋範圍如何超越傳統滲透測試攻擊面 [1]。具體而言，本文首先為 web3 機構定義了一個四元件模型，並說明每個元件的職責、代表性系統及主要攻擊面。在此模型的基礎上，本文接著探討五個攻擊面領域，這些領域將繼承而來的應用程式與基礎設施暴露面，與簽名意圖、審批與簽名工作流程、資金邏輯及鏈上運行時行為等 web3 特有的驗證要點連結起來。

web3 機構的組成元件

web3 機構，包括中心化交易所、支付服務提供商及 DeFi 專案，將傳統應用程式與基礎設施環境，與從鏈下到鏈上的資金處理鏈連接起來 [2]。它們保留了傳統滲透測試攻擊面，同時在交易意圖、簽名權限、資金會計及鏈上執行等方面引入了額外的驗證要點。要辨識這些攻擊面之間如何相互作用，以及哪些條件可能構成通往價值的路徑，需要具備專門的 web3 安全判斷力。

為了系統性地檢視這一擴大的攻擊面，本節定義了一個四元件模型：應用程式（Application）、授權與簽名（Authorization and Signing）、區塊鏈交互（Blockchain Interaction）及基礎設施（Infrastructure）。針對每個元件，本節說明其職責、列出代表性實作，並總結其主要攻擊面。請注意，不同的 web3 機構可能以不同方式組合或外包這些元件。

元件一：應用程式

應用程式元件依據既定的業務與授權邏輯，處理來自使用者或內部操作人員的請求，將經授權的意圖轉化為預期的業務行動，例如資產轉移或資產救援操作。web3 機構中常見的代表性系統包括網頁及行動應用程式、瀏覽器擴充功能與後端 API。

常見測試類型。

網頁應用程式滲透測試
行動應用程式滲透測試
瀏覽器擴充功能滲透測試
API 滲透測試

應用程式元件繼承了傳統攻擊面，如身分與工作階段管理、授權與隔離，以及業務工作流程與狀態轉換完整性。在 web3 機構中，此階段所準備的業務行動或交易意圖，隨後可能經由授權與簽名元件授權，並透過區塊鏈交互元件執行。因此，這些控制措施的失效可能中斷服務，或蔓延為直接的資產損失。

元件二：授權與簽名

授權與簽名元件接收由應用程式元件準備的交易請求，並產生鏈上提交所需的加密簽名。部分實作可能在簽名系統內部另外執行政策或審批檢查，才產生簽名。web3 機構中常見的代表性系統包括錢包及簽名系統或服務。

常見測試類型。

身分與特權存取測試
簽名與審批工作流程測試

授權與簽名元件所繼承的傳統攻擊面包括特權身分與存取管理、API 授權與職責分離，以及審批、救援與管理工作流程完整性。在 web3 機構中，此元件的失效可能造成特別嚴重的後果，因為一個有效的簽名可能直接授權不可逆轉的狀態變更或資產轉移。作為鏈上提交前的最後一道加密授權關卡，凡是使用授權與簽名元件之處，都應將其視為關鍵的保障重點。

元件三：區塊鏈交互

區塊鏈交互元件負責提交經使用者或內部操作人員授權的交易，確認其執行狀態，並追蹤所產生的鏈上狀態。web3 機構中常見的代表性系統包括節點或 RPC 閘道、索引器及中繼器。

常見測試類型。

API 與 RPC 滲透測試
交易提交與中繼器濫用測試

儘管區塊鏈交互執行著 web3 運作特有的角色，但針對此元件的滲透測試，重點在於其繼承而來的攻擊面是否可被對手利用：服務憑證與端點安全、RPC 與 API 授權，以及訊息與事件處理完整性——例如，RPC 或中繼器行為是否可被濫用、交易提交是否可被操縱，或鏈上事件是否可能被錯誤解讀。對於營運客製化或自架區塊鏈節點的機構而言，節點與叢集正確性，以及大規模 RPC 韌性——包括同步、交易傳播、容錯移轉與可用性——屬於補充性議題，應由區塊鏈安全測試而非滲透測試來處理 [2]。

元件四：基礎設施

基礎設施元件涵蓋支援或影響其他三個元件的機構特定基礎設施與營運系統。web3 機構中常見的代表性系統包括雲端平台、網路基礎設施、身分與存取管理（IAM）及機密管理系統、原始碼控管與 CI/CD 系統，以及監控平台。

常見測試類型。

外部與內部網路滲透測試
雲端基礎設施滲透測試
CI/CD 與軟體供應鏈測試

基礎設施主要繼承了傳統攻擊面，包括網路與服務暴露面、身分、權限與機密管理，以及軟體交付與供應鏈完整性。儘管基礎設施通常不直接執行資金處理行動，但其失效或被入侵仍可能導致重大資產損失。第一部分中討論的 Bybit 與 TrustWallet 事件，正說明了軟體交付與分發渠道的入侵事件如何蔓延至資金處理鏈 [1]。

web3 攻擊面

四元件模型顯示，web3 機構的滲透測試在很大程度上保留了傳統應用程式與基礎設施攻擊面。其區別之處在於資金處理的情境：弱點可能跨元件蔓延，並影響交易意圖、簽名、資金狀態或鏈上執行。因此，辨識這些路徑並選定適當的驗證要點，需要具備專門的 web3 安全判斷力。

為了將此覆蓋範圍系統化，本節依據第二部分所介紹的資金處理鏈與測試範疇 [2]，將 web3 攻擊面分為五個主要攻擊面領域：

生產環境與自動化運維
網頁與 dApp 前端、授權與簽名意圖
簽名、審批與提款授權鏈
資金業務邏輯
鏈上交易與已部署合約

生產環境與自動化運維

生產環境支撐著資金處理鏈的每一個階段。傳統的基礎設施、身分或軟體交付立足點，或許無法直接移動資金，但它可能改變應用程式行為、觸及授權與簽名，或影響區塊鏈交互。因此，區塊鏈滲透測試評估的是該立足點對資金處理鏈可觸及的影響，而非將此基礎設施發現視為孤立的端點 [2]。

**測試重點。**測試人員驗證存取權限、部署、機密或營運控制措施是否可被串連，進而導向資金處理行動。測試情境可能始於一項暴露的服務、遭入侵的身分、工作負載憑證、建置權杖、相依套件或供應商整合，接著評估 IAM、網段隔離、機密處理、變更控管及服務授權是否能防止進一步觸及。所得的證據應將此運維立足點，與其可能影響的元件及涉及價值移動的行動連結起來。

詳細分析 [3] 檢視了生產環境的入侵如何透過部署與運維控制蔓延至資金處理元件。

網頁與 dApp 前端、授權與簽名意圖

網頁與 dApp 前端是主要的交互層，使用者與操作人員在此發起並檢視資金處理行動，並透過授權與簽名流程參與這些行動的批准過程。這樣的地位使其成為釣魚攻擊與前端劫持的誘人目標，因為掌控介面便可在交易請求送達錢包或簽名系統之前，操縱其情境或內容 [1]。

**測試重點。**測試人員驗證呈現給使用者或操作人員的交易，是否可能與最終被授權的行動出現偏差。此評估追蹤請求從應用程式身分驗證與授權，經過交易建構、錢包呈現、簽名到提交的整個過程，並考量工作階段狀態、錢包權限、模擬結果、鏈上情境、合約情境或顯示邏輯是否可能改變其含義。證據應保留所呈現的行動、實際的酬載內容、產生的簽名及提交後的行為。

詳細分析 [4] 追蹤交易意圖從應用程式呈現、經錢包授權，到最終簽名或提交結果的整個過程，並著重於行動含義可能出現偏差之處。

簽名、審批與提款授權鏈

簽名往往是一項移動資金的行動，但單憑加密有效性並不能確立正確的業務權限。安全結果同時取決於是誰發起了請求、套用了何種政策、審批人員審核了什麼內容，以及酬載內容是否保持不變。此控制鏈中的一項弱點，可能導致合法的簽名者授權了非預期的行動 [2]。

**測試重點。**測試人員驗證身分、角色、政策檢查或審批步驟是否可被繞過或組合利用。測試情境可能評估：單一身分是否能同時發起並批准某項行動、目的地或限額變更是否在未經獨立審核的情況下即生效、政策是簽名端強制執行還是僅存在於介面層面，以及酬載內容是否可能在審批之後被更改。證據應記錄所測試的順序、被突破的控制措施，以及因此得以進行的未授權行動。

詳細分析 [5] 檢視機構的審批與簽名工作流程，是否能在交易發起、簽名及提款執行的整個過程中維持業務權限的完整性。

資金業務邏輯

託管機構依賴鏈下狀態來確定餘額、負債，以及價值是否可以釋放。因此，即使沒有簽名金鑰或智能合約遭到入侵，一次非預期的入帳或狀態轉換也可能直接造成財務損失。測試必須考量經濟不變量與對帳路徑，而不僅僅是單一 API 是否按照實作方式運作 [2]。

**測試重點。**測試人員驗證餘額、限額、對帳、提款規則或狀態轉換是否會接受非預期的條件。測試情境可能檢視：一筆存款是否在未達預期價值的情況下被入帳、單一事件是否產生多筆入帳、精度或並行處理是否改變了餘額，或無效狀態是否變得可提款。證據應記錄所產生的狀態轉換，以及可重現的業務影響路徑，而不僅僅是技術性缺陷。

詳細分析 [6] 檢視非預期的鏈下資金狀態，如何在機構工作流程中被建立、蔓延，並轉化為可提取的價值。

鏈上交易與已部署合約

鏈上交接是鏈下意圖轉化為公開運行時行為之處。交易可能是不可逆的，而已部署合約則是公開可呼叫的，且可與機構直接控制範圍之外的系統組合互動。因此，評估工作必須保留預期行動、已提交交易、實際觀察到的執行結果，以及機構所解讀之狀態之間的關聯性 [2]。

**測試重點。**測試人員驗證機構的鏈上交互在對抗性運行時條件下的行為表現。測試情境可能檢視：交易欄位是否可能在建構、簽名及提交等各階段之間發生變化。也可能評估：RPC 或中繼器行為是否影響該行動、鏈上事件是否被正確解讀，以及已部署的權限、升級或協議組合是否會改變預期結果。證據應保留已提交的交易、相關的鏈上情境，以及觀察到的運行時結果。

在此領域，滲透測試仍聚焦於對抗性的運行時交互與交易層級證據。程式碼層級的合約保障仍屬於程式碼審計（Code Audit）範疇，而節點或叢集正確性以及大規模 RPC 韌性，則仍屬於區塊鏈安全測試範疇 [2]。

結論

區塊鏈滲透測試保留了傳統評估中所檢視的應用程式與基礎設施攻擊面。其與眾不同之處，在於需要追蹤弱點如何超越這些入口點，蔓延至機構的資金處理鏈——在此鏈中，請求處理、授權、軟體交付或基礎設施方面的失效，都可能影響加密簽名、資金狀態或鏈上執行。

為了明確闡述這些關聯性，本文採用了一個四元件模型：應用程式準備業務行動、授權與簽名產生簽名、區塊鏈交互提交交易並解讀結果，而基礎設施則支援或影響其他各元件。此外，五個攻擊面領域指出了專門的 web3 安全判斷力最為重要之處，特別是在交易意圖、簽名權限、資金邏輯與鏈上運行時行為之間的邊界地帶。

四篇後續指南將延伸此概述，深入探討應用程式授權與簽名意圖、雲端與 CI/CD 安全、資金庫控管，以及交易所帳本邏輯等主題的專門分析。鏈上交易與已部署合約則仍涵蓋於本篇概述中。

BlockSec 協助機構將四元件模型與五個攻擊面領域，轉化為可測試的範疇——透過對元件、負責人、資金流向及信任邊界進行梳理，選定攻擊者視角，界定安全的證據蒐集方式，並驗證真正重要的潛在路徑。若欲為您下一次的測試工作界定攻擊面範疇，歡迎申請範疇界定諮詢。如需更多資訊，歡迎另行洽詢。

本系列同時收錄以下文章，即將發布：

第五部分：授權與簽名安全：網頁、dApp 與
第六部分：雲端與 CI/CD 安全：自動化運維攻擊面
第七部分：資金庫控制平面安全：簽名與提款審批
第八部分：交易所帳本安全：竊取路徑與資料平面邏輯

區塊鏈滲透測試專頁提供了測試工作層級的整體視角。

參考資料

依首次出現順序編號。

BlockSec，《從事件到監管：為何加密機構需要區塊鏈滲透測試》。
BlockSec，《什麼是區塊鏈滲透測試？定義與界限》。
BlockSec，即將發布。
BlockSec，即將發布。
BlockSec，即將發布。
BlockSec，即將發布。