Web 與 dApp 前端、授權與簽名意圖
我們測試 Web 與 dApp 前端如何構造與展示交易、連線錢包、發起簽名請求、呈現預覽與模擬，以及這些流程背後的認證與 API 校驗。我們檢驗未經授權的使用者能否發起或篡改一個請求，以及使用者看到的、簽署的與最終執行的是否始終一致。
傳統滲透測試通常評估雲、Web、API、身份與運維。區塊鏈滲透測試把這套方法擴展到簽名意圖、審批與提現控制、資金邏輯以及鏈上執行 —— 檢驗這些環節上的弱點能否串成一條可復現的資金攻擊路徑。
前端與簽名意圖
審批與提現控制
資金邏輯
鏈上執行
01/ 04
支撐性基礎設施與運維側的 AI 智能體，只要構成議定的資金攻擊路徑的一環，就可以納入範圍。合約程式碼的安全驗證由對應的 Code Audit 負責；MPC、TSS 與 TEE 金鑰託管的正確性屬於 Wallet Security Audit；深層節點、叢集與 RPC 的韌性屬於 Blockchain Security Testing；支付側的智能體系統屬於 Agentic Payment Security Audit。
每個專案都走四個受控的步驟：從界定範圍與預設訪問條件，到執行議定的攻擊場景、交付有證據支撐的發現，再到對修復進行複測。書面的測試規則（Rules of Engagement）在測試開始之前就把保障措施定下來。
我們對齊目標、架構、資金流轉、目標環境與授權邊界。測試規則（Rules of Engagement）界定允許的手法、禁止的活動、生產環境的保障措施、溝通與中止標準，以及社會工程、物理訪問、持久化或橫向移動是否在範圍內。
範圍、週期、交付物與定製報價在技術溝通之後確認。
我們梳理暴露的資產、身份、信任關係、簽名與審批工作流，以及鏈上依賴。隨後約定測試方的起始位置 —— 外部、已認證、特權、供應商被攻陷或假定已被入侵 —— 並挑選那些可能觸及資金轉移動作的場景。
在約定的保障措施之內，我們在所選攻擊面上執行獲授權的攻擊場景，在合適的地方把弱點串聯起來，並判斷它們是否會產生可復現的影響。發現會經過定性，把可利用路徑與預期行為區分開；嚴重問題通過約定的升級通道通報。
我們交付的報告把每一條已確認的路徑與可復現證據、失效的管控措施、業務影響、嚴重級別以及可執行的修復建議對應起來。修復實施之後，我們對約定的發現進行複測，並記錄已演示的攻擊路徑在複測條件下是否已不可復現。
測試僅反映約定時間點和範圍內的情況。它不保證必然攻破，也不保證發現全部問題；已確認的可利用路徑會連同可復現證據一併記錄。
From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing
損失究竟從哪裡產生，以及哪些監管機構已經要求做測試。
What Is Blockchain Penetration Testing? Definitions and Boundaries
定義、資金處理威脅模型，以及五項相互連線的能力。
Rules of Engagement and Production Safety for Institutional Blockchain Penetration Testing
授權、操作邊界、敏感流程控制、停止條件與複測。
Web3 Attack Surfaces: A Penetration Testing Overview
機構的四元件模型，以及它暴露出的五個攻擊面。
區塊鏈滲透測試，也被稱為 web3 滲透測試，是針對執行中系統的對抗式實戰評估，在約定的環境與測試規則下進行，用來驗證可利用路徑與控制鏈。
它追蹤的是完整路徑，而不是孤立的弱點。它與程式碼層面的安全審計互補，也可以單獨委託。
因為損失最慘重的那些事件，越來越多起源於智能合約之外，在簽名、託管、金鑰、人員與供應鏈上。
在我們自己 2026 年的追蹤中（損失超過 10 萬美元的事件），合約層之外的失效大約佔八分之一的事件，卻佔了四分之三以上的損失。
程式碼層面的審計檢查程式碼；交易層面的監控檢查交易抵達鏈上時的狀態。兩者都沒有把它們之間的那條路徑拼起來。
2025 年的 Bybit 事件就是一個例子：一個被操縱的簽名介面，讓運營人員自己的審批變成了一筆他們從未打算發出的轉帳，而這筆轉帳在合約、對合約的審計以及監控看來，都可以是合法的。
更多 BlockSec 事件分析：官方更新通道中被竊取的 API key、Profanity 地址生成器的缺陷、硬體錢包的熵失效。
區別在於安全驗證目標。
程式碼審計驗證程式碼的安全性，涵蓋設計、架構與協議假設。滲透測試確認的是執行中的機構環境裡的真實條件能否被串成可復現的實際影響。
僅有審計無法產出機構範圍內的執行時可利用性證據，而滲透測試也不能替代程式碼層面的安全驗證。兩者方法上有重疊，團隊也可以協同工作。
傳統滲透測試在雲、Web、API、身份與特權訪問等攻擊面上依然有價值。它通常缺少的是數字貨幣業務的業務語義：一個簽名可以授權不可逆的價值轉移，而提現審批是一項資金控制決策，不是一次表單提交。
測試者可能找到一個認證繞過，卻仍然看不到它如何與簽名展示不一致、或一條薄弱的審批策略，組合成一條資金攻擊路徑。
常規測試證明的是 IT 控制層面的影響；而這一項把價值的轉移作為終止條件。差異來自專業的 web3 安全判斷，而不是新工具。
對特定一批持牌實體而言，是的。這項義務是有條件的，而非普遍強制，而且範圍、頻次與獨立性要求在各個市場並不相同。
監管要求的是滲透測試，並沒有點名某個品牌化的服務品類。讓一次測試成為「專業版」的，是範圍內的那些系統：當它們授權、簽名、託管或核算數字資產價值時，要把它們測到位，就需要對簽名與資金流足夠熟稔。
以上示例僅供說明，不構成法律意見。機構應與律師確認自身的身份認定、豁免情形與義務範圍。
專案範圍按專案逐一議定。雲、Web、API、身份與生產運維這些面，只要它們連著一條資金攻擊路徑，就可以納入範圍。我們另外還會測試 web3 資金處理鏈上相互連線的四個部分：
合約程式碼的安全驗證，仍然由對應的 Code Audit 負責。
只在書面授權與約定的安全保障措施之下進行，並在測試開始之前記錄到一份測試規則（Rules of Engagement）文件裡。
RoE 把什麼在範圍內與允許做什麼活動區分開：一個生產提現服務可以為了驗證授權路徑而在範圍內，同時禁止真實客戶提現、私鑰匯出、持久化以及產生負載的攻擊。
對簽名與提現工作流，受控場景會明確規定指定錢包、白名單目標地址、最大測試金額、參與審批的人員，以及鏈上活動、帳務記錄與餘額之間的對帳。
可度量的停止條件、一條受保護的安全溝通通道，以及一位有權暫停或恢復測試的指定負責人，都會與服務負責人一併約定。機構始終保有對生產決策、客戶溝通與修復工作的決定權。
你會拿到每一條已確認的路徑，以及與之對應的可復現證據、嚴重級別、修復建議，還有對約定修復項的複測。
最終記錄會把每一項發現與它的證據、影響、責任人、修復方案與複測條件關聯起來。專案結束時，我們會回收臨時的測試身份與權限，證據僅在約定期限內保留。
交付物與複測安排按專案約定確認。
不能。這項評估採用系統方法、以證據為依據，且僅反映測試時的情況：它的結論適用於所測試的那些系統、版本、配置與預設訪問條件。
在約定範圍內系統性地開展工作，並不能保證每一個弱點或攻擊路徑都會被發現，也不能保證測試者一定能攻破。我們檢查潛在路徑，並把已確認的可利用路徑連同可復現的證據一併記錄。
滲透測試無法保證防住入侵，也無法證明它本可以阻止過去某一次具體的事件。
先從三個問題開始：哪些系統在轉移資金？已有何種安全驗證證據？哪一條控制鏈還沒有被對抗式地驗證過？這些答案能識別出安全驗證缺口，而不必過早地按名字挑一項服務。
隨後的範圍溝通會把目標、預設訪問條件、生產環境保障措施與預期交付物對齊。
BlockSec 不公開固定價格；範圍、週期、交付物與定製報價在技術溝通之後按需提供。