什麼是區塊鏈滲透測試？定義與範疇

上一篇文章《從事件到監管：為什麼加密機構需要區塊鏈滲透測試》闡述了為何區塊鏈滲透測試有其必要性。本文則轉向探討「它究竟是什麼」，更詳細地檢視區塊鏈滲透測試的定義與邊界。

目前並不存在一個被廣泛接受的區塊鏈滲透測試正式定義，而許多提出的定義往往將其與其他緩解措施混為一談，因此像審計、掃描、漏洞賞金等標籤有時會被納入滲透測試的一部分，儘管它們各自服務於不同的目標。這使得人們更難判斷某次測試工作究竟驗證了什麼。我們的出發點取自學術界與業界的實務經驗，刻意保持簡單：正如其名，區塊鏈滲透測試就是滲透測試——一門已存在數十年的學科——應用於 web3 生態系統，以對抗性的方式，針對正在運行中的 web3 環境進行整體系統評估。從這個熟悉的學科出發，再進一步探討 web3 為威脅模型以及測試人員所需的判斷力帶來了哪些新增內容。

**區塊鏈滲透測試是對正在運行系統的一種對抗性、實作性評估，在約定的環境與交戰規則下進行，以驗證可被利用的路徑與控制鏈。**它是對程式碼層級安全審計的補充，也可以獨立委託進行 [1]。

它尋求的是路徑而非孤立的弱點，並在明確的授權、範圍、存取假設與安全限制下運作。本文將回答三個問題：什麼是區塊鏈滲透測試、它能驗證什麼——尤其是超越審計通常能提供的證據之外的內容——以及機構可以如何從高層次開始著手。

web3 帶來的新增內容：資金處理威脅模型

web3 保留了傳統滲透測試的作業面：雲端基礎設施、網站、API、身分、特權存取、供應商與營運工具。它並非以純區塊鏈的威脅模型取代該威脅模型，而是將其延伸至那些相同立足點可能直接導向授權、記錄或轉移資金的行動的系統中。

三項特性塑造了這種延伸。

• 首先，數位資產可直接轉移。攻擊者一旦到達正確的交易或提款路徑，便可能繞過傳統支付中所使用的相同撤銷與對帳機制而轉移資金。

• 其次，簽署往往就是一項資金轉移行動。一個密碼學上有效的簽章證明了某把金鑰已授權某個資料負載；但它本身並不能證明操作者看到的是正確的目的地、理解了這筆交易，或遵循了預定的核准政策。

• 第三，當機構部署自己的合約時——隨著產品增加更豐富的鏈上功能，這種情況日益普遍——這些合約是可公開呼叫且可組合的。外部使用者與其他合約可以以機構無法控制的順序呼叫它們。因此，安全性不僅取決於每個組件本身，也取決於身分、應用程式、政策、簽署系統、記帳邏輯與合約之間如何互動。

我們將由此產生的暴露面建模為一條資金處理鏈——即從鏈下的簽署意圖、核准與資金邏輯控制，一路導向鏈上交易（且愈來愈多情況涉及機構自身部署的合約）——並連同支援這些步驟的雲端、網頁、API 與身分層 [1]。攻擊者可能從一個普通的立足點開始，逐步跨越多個控制環節：操縱呈現給簽署的內容、抵達某個特權工作流程、利用授權漏洞，或使資金邏輯接受非預期的狀態轉換。

決定性的組合缺口在於鏈下與鏈上之間的交接：身分、介面、核准、簽署與資金邏輯控制是否能在動作轉變為鏈上交易時，仍然保留原本意圖的動作。並非每次攻擊都會貫穿整條鏈。重點在於保證目標是跨層級的：各自看似穩健的控制措施，仍可能組合成一條可利用的路徑，貫穿正在運行的資金處理系統。

區塊鏈滲透測試做什麼

區塊鏈滲透測試將這種組合缺口轉化為證據。在授權範圍與約定規則內，測試人員將跨層級假設轉譯為攻擊情境，針對正在運行的環境執行這些情境，並判斷它們是否會產生可重現的路徑與具體影響。其產出將路徑與支持性證據、嚴重程度、修復建議以及對約定修復措施的重新測試連結起來——而非僅止於一份互不相關的弱點清單。

其差異化之處在於專業的 web3 安全判斷力，而非某種獨特的工具箱。測試人員必須解讀託管、交易意圖、核准政策、提款流程、資金記帳與鏈上交易行為（包括已部署的合約），同時連結來自傳統雲端、網頁、API、身分與特權存取作業面的證據。工具可以輔助發現或驗證，但最終要靠專家判斷來確認觀察到的情況是否構成一條可信的資金轉移路徑。

該評估是有條理、以證據為導向且針對某一時間點進行的。其結論適用於所測試的系統、版本、組態、存取假設與條件。潛在路徑會被檢視；已確認的可利用路徑則會以可重現的證據記錄下來。

請注意，在約定範圍內進行系統性工作，並不能保證會發現每一個弱點或攻擊路徑，而負責任的測試工作也不保證測試人員一定能達成入侵。

在機構的 web3 環境中，這個從情境到證據的過程會橫跨五項相互連結的能力——即同一條資金處理鏈上可測試的作業面。它們涵蓋支撐該鏈的基礎設施、其三項鏈下控制措施，以及其交接至的鏈上交易；之所以相互連結，是因為單一路徑可能橫跨其中數項：

• **生產環境與自動化運營：**測試人員驗證存取、部署、機密資訊或運營控制是否能被串連成一項資金處理行動，並產生將運營立足點與其可觸及影響連結起來的證據。

• **網頁與 dApp 前端、授權與簽署意圖：**測試人員驗證呈現給使用者或操作者的交易是否可能偏離最終被授權的動作，並記錄被操縱的流程及其導致的簽署或提交行為。

• **簽署、核准與提款授權鏈：**測試人員驗證身分、角色、政策檢查或核准步驟是否可被繞過或組合利用，並記錄該序列以及其所促成的未授權動作。

• **資金業務邏輯：**測試人員驗證餘額、限額、對帳、提款規則或狀態轉換是否會接受非預期的條件，捕捉的是一條可重現的業務影響路徑，而不僅僅是一個技術性缺陷。

• **鏈上交易與已部署合約：**測試人員驗證機構的鏈上互動在對抗性運行條件下的行為表現；若機構已部署自己的合約，測試人員將測試這些合約的運行時行為，並保留所觀察結果的交易層級證據。程式碼層級的保證仍屬於相對應的 Code Audit 的職責範圍。

第四篇：Web3 攻擊面：滲透測試概覽對這些作業面及其相互連結進行了梳理，但核心目標並未改變：確認約定的運行環境中的各項條件是否會串連成可重現的影響。

它與其他保證措施的關係

最清晰的比較方式是依保證目標來區分：即該項工作旨在支援的決策，以及預期產出的證據。如下圖所示，各種方法可以互有重疊，各學科之間可以協作，並沒有一個有意義的界線是建立在「某個團隊完全屬於靜態、另一個團隊完全屬於動態」這種假設之上。同一個目標——一份已部署的合約、一個雲端或 RPC 作業面、一套簽署系統——都可能屬於一種以上的學科；不同之處在於各自側重的保證目標，而非對該系統的專屬主張。

滲透測試與程式碼層級審計

Code Audit——即程式碼層級審計的正式名稱——主要在程式碼層面（也包括設計、架構與協議假設）建立保證。它結合專家審查與檢測工具，可能包含動態技術，並針對約定的審計範圍出具一份簽署的報告。對於合約、鏈、橋接、rollup、錢包或其他實作，審計所要回答的問題是：設計與程式碼是否滿足其預期的安全屬性。

滲透測試則主要確認在一個約定的、正在運行的機構環境中，真實條件是否能被串連成可重現的影響。它追蹤已部署的應用程式、身分、組態、工作流程、業務邏輯、簽署系統與合約呼叫之間的互動，然後記錄重現與修復該路徑所需的證據。

這是目標與證據上的差異，而非能力上的禁止。審計人員可能會執行測試、對元件進行模糊測試並調查運行時行為；滲透測試人員也可能審查組態、應用程式邏輯與實作細節以理解某條路徑。方法可以重疊，團隊也可以協同合作。這些服務是互補的，而非互相替代：單靠審計通常無法提供這種機構層級的運行時可利用性證據，而滲透測試也不能取代審計所涵蓋的實作與協議屬性層面的程式碼層級保證。

因此，某份合約在實際機構路徑中的對抗性行為可歸屬於滲透測試的範疇，而關於該合約程式碼本身的保證則歸屬於相對應的 Code Audit。

掃描、漏洞賞金與專項測試

漏洞掃描針對已知特徵、暴露的服務、缺失的修補程式與常見組態問題，提供自動化的廣泛覆蓋。它有助於實現可重複的可視性，也能對偵察工作有所貢獻，而滲透測試則增添了專家主導的深度，並判斷各項條件是否能被串連成具有實質意義的路徑。

漏洞賞金邀請獨立研究人員依公開規則回報符合資格的發現。其持續性、群眾外包的模式能夠發掘長尾問題，而滲透測試工作則指派一個團隊有條理地檢視約定的環境，並提供整合後的證據、嚴重程度、修復建議與重新測試。這兩種模式互為補充，且都無法保證能發現全部問題。

例如，BlockSec 的 Blockchain Security Testing 是滲透測試的姊妹計畫，而非其上級或子集。它運用專門的引擎——包括差異測試、模糊測試、私有部署、大規模 RPC 拒絕服務測試，以及節點或叢集基礎設施測試——來驗證客製化基礎設施的實作正確性與韌性 [2]。區塊鏈滲透測試則聚焦於機構層級、跨層級的路徑，貫穿正在運行的資金處理系統。應用程式的託管與應用程式 CI/CD 歸屬於滲透測試的作業面；節點與叢集基礎設施以及大規模 RPC 韌性則歸屬於 Blockchain Security Testing。某個架構可能兩者皆需。

相近的保證目標同樣需要精確的分流。合約程式碼層級的保證歸屬於相對應的 Code Audit。密鑰託管實作（包括 MPC、TSS 與 TEE 設計）的密碼學正確性歸屬於 Wallet Security Audit。支付端的代理型系統歸屬於 Agentic Payment Security [1]。若簽署工作流程周邊、運營代理程式或應用程式路徑構成約定機構範圍的一部分，滲透測試仍可能對其進行檢視。

這是一份分流指南，而非一套執行順序。單一系統可能會產生多個保證目標，因此可能需要一套協調一致的評估組合；上述標籤彼此並不互斥。

依管轄區與機構類型不同，測試可能是一項監管要求或監理期待，某些制度更要求由獨立第三方進行；第一篇已說明這些差異 [3]。相關監管適用性應向法律顧問確認。

如何開始著手

在做出決策之前，我們可以先從以下三個問題入手：**哪些系統在轉移資金？目前已有哪些保證證據？哪條控制鏈尚未經過對抗性驗證？**這些答案能幫助識別保證缺口，而無需過早以名稱來選定某項服務。

接下來的範圍界定討論，可以確定測試目標、存取假設、防護措施與預期交付成果。第三篇：機構級區塊鏈滲透測試的交戰規則與生產環境安全介紹了將此項測試工作付諸實行所需的授權、安全與協調事宜 [4]。

若您已準備好採取行動，請與 BlockSec 一同界定您的保證缺口，在測試開始前確定目標、證據與防護措施。

繼續閱讀攻擊面指南系列：

• 第四篇：Web3 攻擊面：滲透測試概覽

本系列即將發布：

• 第五篇：授權與簽署安全：Web、dApp 與
• 第六篇：雲端與 CI/CD 安全：自動化運營攻擊面
• 第七篇：資金控制平面安全：簽署與提款核准
• 第八篇：交易所帳本安全：竊取路徑與資料平面邏輯

Blockchain Penetration Testing 主題頁提供了測試工作層級的完整視角。

參考文獻

依首次出現順序編號。

1. BlockSec，Blockchain Penetration Testing。
2. BlockSec，Blockchain Security Testing。
3. BlockSec，從事件到監管：為什麼加密機構需要區塊鏈滲透測試。
4. BlockSec，機構級區塊鏈滲透測試的交戰規則與生產環境安全。