#竞态条件

1个月前

「如何对 X402 Server进行双花攻击？」在 X402 设计里: Server 在第4️⃣步收到 Client 带 EIP3009 签名的请求之后，会执行第5️⃣ 6️⃣ 7️⃣步给 Facilitator 进行 Verify , 如果 Verify 通过 ,Server 在第 8️⃣步执行自己的业务逻辑(会生成对应的 Resources) 接着在第 10 ～ 15 步之后再进行 Settle, 如果 Settle 失败则会把资源丢弃，如果 Settle 成功则把 Resources 返回给用户(第16步) 攻击思路：关键洞察：验证阶段的盲点: verify() 只做离线验证（签名、余额、时间），不查询区块链状态 ✅ 检查签名是否有效 ✅ 检查余额是否充足 ❌ 不检查 nonce 是否已被使用执行顺序的缺陷: 业务逻辑在 settle() 之前执行此时 nonce 尚未被链上标记为已使用多个并发请求都能通过 verify 阶段所有请求都会执行业务逻辑竞态条件窗口: Settlement 是同步的，但有先后顺序第一个到达区块链的 settle 会成功后续的 settle 会因为 nonce 冲突而失败但业务逻辑已经执行，无法撤销

#X402 Server #双花攻击 #EIP3009签名 #nonce重用 #竞态条件

1个月前

AWS 这次事故的原因报告出来了：简单看了一下，让 AI 总结一下： 1 DNS 记录由 DNS Planner 定期生成一份完整的区域计划，列出应该指向哪些load balancer。 2 DNS Enactor 负责把计划写进 Route 53（Amazon 的 DNS 系统），每个可用区运行一个独立实例。所以有多个。 3 Enactor 开工前只核对一次：确保手里的计划是最新版本。 4 其中一个 Enactor 在更新 DNS 记录时，速度卡了，每改一个endpoint 都要试好几次才成功。 5 在它卡顿的过程中，Planner 生成了多个更新的计划，其他 Enactor 已经快速把最新计划写进了 Route 53。 6 慢的 Enactor 最初检查时认为自己的计划是最新，但由于延迟太久，实际上已经过时。它没有再次检查，直接用的旧计划。 7 快的 Enactor 写完后会清理旧计划，把所有比自己刚应用的版本更旧的计划全部删除。 8 结果：慢 Enactor 正在应用的旧计划被快的 Enactor 删除，导致区域端点的 DNS 记录被清空。 9 区域端点无法解析，连接全部失败，引发区域级服务中断。感觉设计真的挺复杂的，但是几十万条 DNS 记录只能自动化实现，并发 + 延迟就造成了竞态条件的问题。

#aws事故 #DNS故障 #区域服务中断 #竞态条件 #自动化运维