本文聚焦支付与签名流程中的授权风险，指出密钥保护不足以确保业务授权有效。文章系统分析付款依据、交易构造、签名授权、执行结算四大环节的典型失效案例（如Bitget伪造请求、Bybit交易篡改、Resolv权限滥用、Drift durable nonce滥用），提出逐环节绑定业务授权、独立核验、权限分离等控制要求，并强调损失限制、独立监控与多维度验证（设计评估、代码审计、渗透测试、应急演练）的必要性。
核心要点
签名有效，不代表业务授权成立。真实事件揭示了支付与签名流程中的多类风险，从伪造请求到滥用已签授权。支付机构既需要验证各环节的检查能否阻止未经授权的操作，也需要验证检查失效后的损失控制是否有效。
币安对 2026 年 10 月 30 日事件的初步说明披露，攻击者利用窃取的部署令牌获得内部签名服务的访问权限，绕过正常提现流程发起交易 （来源：Binance. October 30, 2026 Security Incident: Preliminary Findings and Response Update, November 3, 2026. Chinese: https://x.com/binancezh/status/2117632624651125019; English: https://x.com/binance/status/2117626126214504729）。 按照这份说明所描述的攻击路径，攻击者无需先读取钱包私钥，就能请求系统签名。
这类攻击瞄准的是系统代为签名的能力。加密存储、硬件隔离等安全存储措施可以保护密钥，却无法判断一笔付款是否具有有效的业务授权。问题由此转向：未经授权的操作，是如何获得有效签名的？
要回答这个问题，需要看清业务请求如何一步步成为链上执行的交易。
一笔通过钱包完成的支付，通常要经过业务授权、交易构造、签名、执行与结算 [2, 3]。下图展示了两条攻击路径：一条利用这些环节中的问题，让原系统签署未经授权的操作；另一条利用密码学实现缺陷恢复密钥，由攻击者自行签名。
Beyond Secure Storage 系列从真实事件中总结安全设计与实现原则：
第一篇《支付与签名流程的安全设计》讨论攻击者如何在未取得密钥等秘密信息的情况下，滥用原系统的签名能力；
第二篇《钱包密码学的安全实现》讨论攻击者如何利用实现缺陷恢复密钥，进而独立签名。这两条路径都不需要直接窃取存储中受保护的秘密信息。
第 1 节从真实事件出发，分析支付流程中的风险和容易被忽视的问题，再总结设计与实现中应如何避免这些问题、如何核验相关控制。第 2 节则假定这些检查未能阻止未经授权的操作，讨论如何限制由此造成的损失。
第 3 节说明如何通过设计评估、审计、渗透测试和演练，验证预防与损失控制是否有效。
1. 预防未经授权的操作
同一套支付流程可以承接不同的业务。下图选取三类有代表性的托管业务：充值为客户记账，提现执行客户指令，机构调拨则落实机构自身的资金安排。
充值经过核验后记入客户账户，但这不意味着系统应当立即付款。提现还需要客户另行发起请求并通过审批；机构调拨则以机构的资金安排为依据。二者随后都要经过交易构造、签名、执行与结算。
在资金池式托管中，账本记录每位客户有权支配的资产，并不要求这些资产始终存放在各自的专属地址。
这三类业务转移资金的理由不同。其他业务也可能经过相同的处理环节，但付款所需的凭据和审批要求有所不同。无论业务类型如何变化，都需要逐环节核对：付款依据、交易内容、签名权限的使用和最终结算，是否与原本获准的操作一致。
攻击者可能从其中任何一个环节介入。伪造请求可以让一笔本不应发生的付款看起来有据可依；篡改交易可以把获批操作换成另一项操作；获取或修改权限可以绕过正常流程调用签名服务；执行和结算中的错误，则可能让本应失效的授权继续可用，或触发没有依据的付款。
下表列出各环节需要回答的安全问题，以及用于分析这些问题的案例。
1.1 付款依据与授权
付款进入交易构造和签名环节之前，机构需要确认三件事：请求真实，请求者有权支配相应资金，具体操作已经获得批准。客户账户有余额，或请求来自通过身份认证的内部服务，都不能单独证明这三个条件成立。
失效案例：付款依据被伪造
在 Bitget 2026 年 9 月 24 日的事件中，攻击者利用第三方安全产品的漏洞获取了高权限内部凭证。
据 Bitget 官方说明，攻击者使用这些凭证向钱包系统发送伪造的提现指令，绕过既有风控，发起异常转账 （来源：Bitget. Bitget Hack Explained: Timeline, Impact and Security Response, updated October 20, 2026.）。这些指令虽然通过内部权限进入付款流程，却没有相应的真实客户指令或机构资金安排作为依据。
BigONE 于 2025 年 7 月 16 日披露热钱包发生未经授权的转账，并表示私钥仍然安全。
BigONE Eurasia 将全球平台的事件归因于生产环境中的账户与风控逻辑遭到修改 [5, 6]。这说明，用于判断一笔付款是否合理的记录和规则，也可能被攻击者篡改。不过，公开说明没有提供详细的请求记录或签名 API 信息，不能据此认定其攻击机制与 Bitget 相同。
这些案例揭示了将内部访问权限或账户记录当作充分付款依据的风险：付款决策所依赖的凭证、记录和规则，本身也可能被攻击者改变。
控制要求与验证
因此，设计与实现审查需要核实：每个请求能否追溯到真实的业务依据，以及提交请求的一方能否同时伪造付款凭据或批准该请求。
核验请求来源、完整性与业务授权。 每笔付款都应能追溯到真实的客户指令、业务事件或机构决策，并有相应的资金支配权和批准依据。核验请求及相关记录的变更是否可追溯，确认伪造或篡改的凭据不会仅因来自内部服务、或与账户余额相符，就被当作有效授权。
将请求发起与核验、批准的权限分开。 提交请求的一方，不应同时能够伪造付款凭据或批准该请求。这种分离既要落实在日常操作权限中，也要落实在管理权限中。检查记录、审批规则和角色分配的变更，包括人工例外处理与恢复流程，是否会让同一方同时控制请求和本应拒绝它的检查。
付款依据核验通过后，还要确认构造出的交易与获批操作一致。
1.2 交易构造与核验
付款请求获批后，交易构造服务将其转换为待签交易数据。数据中的收款地址、金额、操作类型，以及任何钱包控制权变更，都必须符合获批请求。批准一笔转账，不等于批准附加操作。因此，核验对象必须是实际提交签名的完整交易，而不只是界面上的说明。
失效案例：待签交易偏离获批操作
Bybit 原本要将 ETH 从冷钱包转入温钱包。
其官方更新指出，攻击者通过被盗用的 Safe 开发者凭证进入服务商基础设施，并误导签名者 （来源：Bybit. Confirms Security Integrity Amid Safe{Wallet} Incident, February 26, 2025.）。Safe 会核验覆盖 to、value、data 和 operation 等交易字段的签名，这一检查由 execTransaction 执行 （来源：Safe. execTransaction.）。但被篡改的界面仍显示预期的转账内容，实际提交签名的字段却已被替换。签名因此能通过验证，只是它对应的已经是恶意交易 （来源：Bybit. Confirms Security Integrity Amid Safe{Wallet} Incident, February 26, 2025.）。
最终的交易通过 DELEGATECALL 修改了钱包实现，使攻击者无需再次获得原所有者批准就能转走资产 [7, 8]。签名者批准的本意是转账，实际签署的却是改变钱包控制权的操作。只核对界面上的收款地址或这笔交易直接转出的金额，无法发现这种偏差。
Kiln/SwissBorg 事件中，攻击者通过修改正在运行的交易构造服务植入恶意交易。据 Kiln 说明，攻击者利用被盗用的 GitHub token，经 CI 工作流取得生产环境凭证，再修改运行中的 Kubernetes pod。
已部署的镜像没有变化，服务返回的内容却变了：除正常的 Solana 质押停用交易外，还多出一笔修改提款权限的交易。
客户的托管签名方批准了这笔附加交易；Kiln 披露的签名时间为 2025 年 8 月 31 日，发现时间为 9 月 8 日 （来源：Kiln. Re-enablement of Kiln Services and Security Incident Information, October 7, 2025.）。SwissBorg 同样将交易篡改归因于服务商基础设施，但双方对当时解码工具是否易于使用、是否已完成集成的说法不同 （来源：SwissBorg. Security Information About the Sep. 8th 2025 Kiln Breach and Its Impact on SwissBorg.）。
控制要求与验证
Bybit 和 Kiln/SwissBorg 的案例都说明，实际交易可能偏离签名者原本打算批准的操作。因此，设计上需要将批准绑定到完整操作，核验时则应独立于构造或展示交易的服务，检查真正提交签名的数据。
将批准绑定到完整操作。 批准范围应覆盖交易的全部效果，包括资产控制权变更或执行权限委托 （来源：Ethereum. EIP-7702: Set Code for EOAs.）。超出范围的变更需要重新批准。核验被替换或附加的操作是否会沿用正常付款的批准，以及重试是否会让一次批准被用于额外付款。
独立核验实际交易及其效果。 将真正提交签名的数据与获批业务操作对照，检查批次中的每笔交易，以及它们对资产和权限的影响。核验应独立于构造或展示交易的服务。检查该服务能否修改核验逻辑或绕过检查，并验证界面误导、交易篡改等情况是否会被识别和拒绝。
上述检查针对交易是否符合获批请求。到了签名环节，还需要检查另一类风险：是否有人能够在缺少业务授权的情况下直接用钥，或通过修改权限取得用钥能力？
1.3 签名授权与密钥使用
经过核验的交易，应由获授权的调用方提交签名服务。密钥策略和管理角色决定了谁能使用密钥，以及谁能修改用钥权限。拥有调用签名服务的权限，不等于有权签署任意交易；管理权限也不应成为绕过业务检查的签名通道。
因此，这一环节既要约束密钥如何被使用，也要约束谁能改变这些限制。
失效案例：签名权限被滥用
Resolv 2026 年 3 月 22 日的事件展示了这种风险。其铸币流程本应先由用户存入抵押品，再由获授权的链下服务完成发行。官方复盘指出，攻击者从代码仓库和云环境的访问权限出发，取得了一个权限更高的角色。
此前的访问尝试被拒绝后，攻击者利用该角色修改签名密钥的访问策略，最终取得签名权限。该云密钥管理服务要求调用方同时满足身份权限和密钥访问策略的要求 （来源：Resolv. Resolv Postmortem: March 22, 2026 Incident, April 4, 2026.）。
取得签名权限后，攻击者无需让原签名服务同意，就能批准不符合抵押要求的发行。公开报告证明的是签名权限被接管，并未证明私钥本身被导出。
币安对 2026 年 10 月 30 日事件的初步说明披露了另一条路径：攻击者先通过被攻破的员工设备和内部 AI 工具进入钱包工程师的设备，再利用窃取的容器部署令牌部署容器、运行恶意脚本，获得内部钱包签名服务的访问权限，绕过正常提现流程发起交易 （来源：Binance. October 30, 2026 Security Incident: Preliminary Findings and Response Update, November 3, 2026. Chinese: https://x.com/binancezh/status/2117632624651125019; English: https://x.com/binance/status/2117626126214504729）。
这份说明解释了部署权限如何被用于接近签名服务，但没有公开具体绕过了哪些内部权限检查。与 Resolv 修改密钥策略的路径不同，这次披露的入口位于签名服务的运行环境。
控制要求与验证
这些案例揭示了在正常业务流程之外取得或使用签名权限的风险。因此，审查应核实每条签名路径是否都落实了业务授权检查，包括通过修改策略或部署代码另行建立的路径。
让每条签名路径都受到业务授权约束。 有权使用密钥，不等于有权执行某项具体操作 [17, 18, 19]。用钥范围应限于获批业务，并核验其他调用方或直接访问能否绕过限制。业务授权检查应独立于能够提交任意签名请求的调用方，不能由该调用方修改或绕过。某条路径若无法落实这一要求，应明确记录缺口，并按第 2 节评估其后果。
约束签名权限的变更。 一个身份即使不能直接签名，也可能通过管理或部署权限取得签名能力 [20, 21, 22]。应将用钥权限与修改签名策略、身份或部署代码的权限分开，并对这些变更进行独立审批。核验任何一方能否组合已有权限，给自己授予签名能力，或移除约束用钥行为的业务检查。
获得签名并不是授权检查的终点：交易仍需按获批条件执行，执行结果也需要被正确结算。
1.4 执行与结算
签名完成后，授权约束仍需延续到广播、链上执行和结算，包括业务记录的更新及预留资金的处理。签名有效不代表付款已经完成，交易执行仍须符合授权范围和有效条件。结算则要确认哪笔应付款项已经支付，是否还需要继续付款。
已有签名或观察到一笔转账，都不能单独构成再次付款的依据。
失效案例：已签交易与结算反馈被滥用
Drift 的案例说明，误导签名者取得的授权，可能被保留到日后使用。
在 2026 年 4 月 1 日的事件中，攻击者提前取得签名，利用 Solana durable nonce 交易保留其有效性，随后提交交易以接管管理权限 （来源：BlockSec. Drift Protocol Incident: Multisig Governance Compromise via Durable Nonce Exploitation, April 3, 2026.）。Durable nonce 控制的是交易有效性，与密码学签名算法中的秘密 nonce 不同。它支持离线签名或延迟提交，不受通常的 recent blockhash 到期限制，但账户或程序状态变化仍可能阻止交易执行。更新 nonce 的值，则可以使绑定旧值的交易失效 （来源：Solana. Durable & Offline Transaction Signing Using Nonces.）。
Drift 在 4 月 16 日的恢复计划中提出，使用专用签名设备、在主签名界面之外核验交易、为关键管理操作设置时间锁，并对签名者禁用 durable nonce （来源：Drift. Incident Recovery Update, April 16, 2026.）。这些措施分别约束签名者批准什么，以及已签操作何时可以执行。不过，公告说明的是恢复计划，不能据此认定措施已经部署。
Chainflip 区分客户换币、流动性提供者（LP）提款，以及归集充值资产的内部操作 fetch （来源：Chainflip. EVM (Ethereum) Vault Design.）。在 Tron 上，交易附带的 memo 可以承载换币指令。
Chainflip 在 9 月 15 日对 2026 年 9 月 12 日事件的说明中指出，攻击者提交验证者已签署的 fetch 操作时，附带了自己控制的异常 memo。链上事件观测层将相关调用信息误判为失败的换币，在正常 LP 提款之外又发放退款，导致六笔提款被支付了两次 [13, 14]。
这一错误将内部资产转移变成了另一笔客户业务的付款依据。此前，Chainflip 即使遇到嵌套在其他合约调用中的金库入账，也会将其 memo 解释为换币指令。
修复后，只有普通 TRX 转账或直接 TRC-20 转账的 memo 才会被这样处理，嵌套调用被排除 （来源：Chainflip. Getting Chainflip Back Up and Running, September 15, 2026.）。已获得有效签名的 fetch 原本有自己的用途，其执行并不能成为额外退款的依据。
控制要求与验证
已签交易可能在超出预期的时间内仍可执行，执行反馈也可能被误认为新增的付款义务。因此，审查需要核实交易的执行条件是否真正生效，以及每笔付款或退款是否都对应真实、尚未结清的业务款项。
确保获批的执行条件真正生效。 已签交易应始终受批准范围、有效期和取消条件约束。核验到期、取消或授权发生变化后，旧交易是否仍能执行。将相关条件与已签操作绑定，并确认链上规则或钱包执行逻辑确实执行这些条件；仅在业务系统中记录并不足够。
只结算真实、尚未结清的业务款项。 每笔付款或退款都必须对应真实且尚未结清的款项，并保留原始业务事件、付款尝试与确认结果之间的关联。核验重试、重复通知、结果不明或内部转账是否会触发无依据的付款，也要检查用于解读执行结果的规则能否被修改，从而绕过这些约束。
2. 限制损失并支持应急处置
第 1 节从案例揭示的流程风险出发，讨论了设计与实现中应采取的措施及检查方法。
本节则假定这些检查由于遗漏、实现错误或被绕过，未能阻止未经授权的操作，进一步讨论如何限制攻击者能够转走的资金、掌握仍处于风险中的资产，并及时发现异常、阻断后续出账。这些损失控制措施同样需要在事件发生前，与预防措施一起完成设计和验证。
下表概括限制损失与支持应急处置的三项设计目标。
2.1 独立执行的支出限制
即使一笔未经授权的付款通过了前面的检查，系统仍应限制它和后续付款能够转走的资金总额。这需要由攻击者在假定场景下无法控制的机制执行预算，同时约束单笔和累计支出。如果被攻破的审批服务或签名方能够关闭或绕过限额，配置中的数字就不能构成有效上限。
独立于付款审批执行限额即使付款通过了授权检查，也必须受到攻击者在假定场景下无法控制的限额机制约束。核验所有签名和执行路径是否都遵守限额，包括其他执行通道 [26, 27]，并检查攻击者能否修改或关闭限额机制。如果无法落实独立限制，就不能把配置中的预算当作损失上限。
限制累计支出，而不只限制单笔付款明确预算的适用范围、时间周期和计价依据，统一核算已完成付款及预留额度。核验重复请求、并发和重试是否会导致累计超限，或提前释放预留额度。限额依赖资产价格时，还需核验价格被操纵、过期或不可用是否会放大允许支出的金额。
2.2 资金存量、补款与待执行交易
接下来需要评估，攻击开始后、机构发现并阻断攻击之前，还有哪些资金可能被转走。钱包余额、补款安排和仍然有效的已签授权共同决定了风险范围，其中也包括事件发生后继续转入的资金。
应结合第 2.1 节仍能生效的限额一起评估，不能只看当前钱包余额就判断可能损失多少。
限制攻击者能够支配的资金范围 评估受影响的签名权限能够控制哪些资产，包括其他钱包、链和合约中的资产，同时计入已有余额与后续入金。补款需要独立授权和累计限额。核验反复出账是否会触发资金库持续补款，以及能否停止或调整后续资金流入，同时跟踪仍转入原地址的充值。
计入已签授权仍能支配的资金停止新签名，不一定使已经签出的交易或授权失效。需要识别它们仍能转走哪些资金，并避免重复计算同一资产。核验已确认付款是否计入支出、相应预留是否按结果结清；对于尚未执行的交易，应保留预留额度，直到可靠证据证明其无法再执行。不能仅因本地超时或提交了取消请求，就减少所记录的风险敞口。
2.3 独立监控与应急处置
限额和资金配置约束了潜在损失，监控与应急处置则决定攻击者还能持续操作多久。即使付款服务把相关操作判定为有效，独立证据也应能揭示其中的异常；正常运行环境不可用或被攻破时，响应通道仍应能够工作。
币安的初步说明展示了仅关闭应用的局限：已有的 EIP-7702 委托并未因此清除。
撤销委托需要链上交易，而在其 MPC 部署中，还需要另行设计撤销流程 （来源：Binance. October 30, 2026 Security Incident: Preliminary Findings and Response Update, November 3, 2026. Chinese: https://x.com/binancezh/status/2117632624651125019; English: https://x.com/binance/status/2117626126214504729）。这是该部署遇到的限制，不能据此认为 MPC 本身无法撤销授权。因此，发现异常和阻断攻击需要分别验证：发出告警之后，系统是否真的能采取措施，阻止后续资金损失？
依据独立保护的证据发现异常 将业务批准与签名活动、执行结果进行对照，同时监控权限和控制规则的变更。受影响服务不应能够改写监控所依赖的证据。核验已经被流程接受、却不符合业务授权的操作能否触发可供处置的告警，包括本地记录缺失或被篡改的情况。
确保应急措施可用且有效保留独立权限，用于停止新签名和资金补充，并在相关机制支持时使待执行交易失效或撤销持续有效的授权。核验正常操作权限不可用或被攻破时，是否仍能处置，以及处置动作是否真正阻止了后续出账。明确仍可能损失的资金和需要外部协调的事项；关闭应用不会自动撤销已签授权，也不能假设资产一定能追回。
3. 验证设计与实现
前两节分别讨论流程检查能否阻止未经授权的操作，以及检查未能奏效时能否限制损失。验证需要在实际部署的系统中检验这两个目标，并覆盖资金流程中各项控制的配合。以下方法可以从不同方面提供验证依据：
架构与安全设计评估检查资金流程、权限边界及控制之间的依赖关系，能否支持预防和损失控制目标，并明确权限独立性与损失上限成立所需的前提。
代码与配置审计核验实际部署的代码、配置和权限是否落实了设计要求，包括可能绕过检查的例外处理和其他执行路径。
渗透测试检验攻击者能否组合应用与基础设施中的弱点，绕过授权检查或损失控制。测试范围应沿完整资金路径展开，覆盖组件之间的连接。
攻防与应急演练检验监控能否及时触发处置，以及限额、暂停和授权撤销能否协同生效，并确认还有多少资金处于风险中、实际阻断攻击需要多长时间。
每个验证场景都应明确哪些操作应被拒绝，或哪些损失应被限制，以及假定攻击者具备哪些能力。记录实际结果、剩余风险和损失上限成立的条件，并在代码、配置或权限发生重大变更后重新核验。
第三方安全团队或专家可以通过评估、审计、测试和演练补充内部团队的工作。审查应覆盖支付逻辑、签名基础设施与运维权限之间的相互影响，为系统能否预防未经授权的操作、限制损失提供证据。
4. 结论
本文从真实攻击中分析了付款请求、交易构造、签名、执行与结算各环节的授权问题，也讨论了检查失效后系统需要哪些措施来限制损失。由此总结的设计原则包括预防、损失控制，以及验证两者是否有效的方法。
保护好私钥，并不足以保证签出的操作已经获得授权。实际执行的操作必须与真实业务决策一致；流程检查未能阻止未经授权的操作时，还需要独立控制限制其后果。
因此，安全审查应覆盖完整流程，既检查谁能修改业务检查规则，也检查发现异常、阻止后续损失所需的权限与工具。
本篇讨论的是攻击者滥用原系统签名能力的路径。第二篇《钱包密码学的安全实现》将分析另一条路径：攻击者不直接窃取受保护的秘密信息，而是利用实现缺陷预测或恢复私钥，进而在原流程之外自行签名。
扫一扫
209
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
