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 不公开固定价格；范围、周期、交付物与定制报价在技术沟通之后按需提供。