对白帽攻击一个协议意味着利用智能合约中的漏洞来挽救资金，而不是盗取资金。
对白帽攻击一个协议意味着利用智能合约中的漏洞来挽救资金，而不是盗取资金。工程师这样做是为了尽早发现漏洞，并阻止坏人攻击特定的协议。
以下是一些最佳实践，来帮助你如何执行这一行为。
不要做什么
如果你在活动代码中发现漏洞，你不应该利用它。
即使你的意图再好，我们也看到过即使最聪明的人也会在攻击中搞砸，导致损失比黑帽攻击的损失还要严重。即使你完美地利用了合约，仍然可能会面临法律后果。
通常，人们试图通过进行攻击并承诺在交换奖励的情况下将资金返还来进行“灰帽攻击”。这被称为“勒索”或“扣押资金赎金”，而不是白帽行为。仅仅通过扣押资金并开始否认赎金（即使你称之为“奖励”），你现在就是黑帽。
有两个例外情况：
我们将在文章最后讨论这些内容。
总结一下，如果你在生产环境中发现了一个诱人的漏洞，并且感到强烈的紧迫感，克制自己不要进行攻击。
为什么？
- 我们看到许多白帽攻击尝试失败，因为：
- 被抢先交易
- 使交易失败，从而暴露漏洞给黑帽
- 可能会有法律后果。
— OWASP组有一个 漏洞披露备忘单，所有安全研究人员也应该熟悉。
如果你发现活动漏洞该怎么办
- 联系协议、漏洞悬赏平台，或负责代码库的相关负责人。
- 确保你在一个安全的通讯渠道上沟通。
- 证明漏洞的存在。
- 想出一个修复方案。
- 撰写一份事后报告。
根据情况，这些步骤可能相当主观和棘手，因为每个漏洞往往都有自己独特的问题。
为了帮助解决这个问题，我们与来自 Openzeppelin 的 Michael Lewellen 进行了交流，他经历了多个活动漏洞缓解危机，包括：
依靠他的经验，这为我们提供了一份需要采取行动和考虑事项的列表，具体取决于情况。
步骤
你在活动智能合约中发现了一个漏洞。时间开始流逝。
这些是需要采取的步骤和考虑事项。
步骤 1：找到代码库的负责人
你通常可以在以下地方找到负责任的人员：
- 项目文档
- 漏洞悬赏平台
- 他们代码库上的
security 选项卡（如 GitHub 或 GitLab）
- 在智能合约本身
在智能合约中添加一个 SOS 邮件地址是一个简单但常被忽视的步骤。一旦你找到正确的人，便可以继续进行步骤 2。
你还可以选择性地联系“智能合约消防员”，如 SEAL 911，他们通常拥有上下文和联系人，可以将你与正确的人连接。
步骤 2：确保你在一个安全的通讯渠道上
你即将分享一个可能会被利用来获得数百万美元的问题。你需要确保你在一个安全的通讯渠道上。
一些好的选项包括：
一旦你进入这个频道，确保只有需要在场的人在场。了解漏洞的人越多，漏洞泄露的可能性就越大。
步骤 3：验证漏洞
一旦你确认你在安全可信的渠道上沟通，就是时候告诉他们关于这个漏洞了。
披露漏洞的过程将与执行审计报告相同，需额外确保有有效的代码证明。
如果协议无法验证漏洞的存在，什么也无法完成。报道者确保利用有效很重要，以免浪费每个人的时间。使用分叉测试（如 foundry、hardhat、titanoboa 等）将是验证漏洞存在的最佳方法之一。
你可以在著名的 Euler 攻击中看到 Ciara 的代码库 中的一个优秀分叉测试示例。关键在于，从测试中，她选取了一个活动 RPC URL 连接，并使用这行代码来分叉链：
vm.createSelectFork("eth", 16817995);
如果你使用 Foundry，你也可以选择仅运行 forge test --fork-url RPC_URL_HERE。
这里的关键部分是，确保利用和代码证明/利用证明可以正常工作，以便每个人都对问题有共同的理解。
确保每个人都很好地理解问题将有助于进入下一个也是最重要的阶段：修复。
步骤 4：想出修复方案
这是整个过程中最困难的部分。好消息是，你正在与协议沟通，以共同制定解决方案。
需要考虑许多事项：
- 有没有治理窗口进行升级？
- 我们是否应重新部署？
- 什么时候告知人们事件的发生？
在这里需要你的创造力。你如何修补协议，以使尽可能少的用户受到影响？时间在流逝，压力在增加，但你必须保持冷静和沉稳。一个 草率的修复 可能会造成更大的损害。
在实施修复时，有几个需要考虑的事项：
- 使用一个 抗 MEV 的 RPC_URL
- 将所有交易打包在一起，使用类似 白帽工具包 的东西，以便其他人不会提前看到漏洞
- 制定一个计划，以防事情进展不顺利
步骤 5：撰写事后报告
事后报告是你在公开信中叙述事件，以便整个社区能从发生的事件中学习。
不进行事后报告会对你产生负面影响，并使 web3 无法改进。
行业需要了解：
- 问题是什么
- 如何引入
- 如何修复
通常，协议会在其事后报告中试图推卸责任。不要那样做。只阐述事实，以便我们都能学习。
希望，当所有这一切完成时，协议会奖励你帮助他们发现漏洞。通常，奖励是 10% 的 TVL，最高 $5M 是“经验规则”，但没有硬性规定。
但是…如果呢？
以上步骤是处理活动漏洞的理想流程，但考虑因素往往使得遵循这条路径变得困难。
他们没有安全联系人或漏洞悬赏
如果确实没有人负责代码（毕竟这是 web3），你可能需要公告，并给出一个比较长的窗口期，让人们在宣布问题之前离开协议。这应该是最后的最后手段。
协议无视漏洞
给他们一个修复或确认的窗口，否则告诉他们你需要公开信息。在公开披露问题之前，给人们离开协议的机会。将此作为最后的手段！
他们不为你的工作付费？
这很棘手。你可以在 Twitter 上抨击他们，但可能会适得其反。理想情况下，每个人都应该齐心协力。一个不支付其白帽攻击者的协议将意味着更少的白帽人员参与他们的协议。
这可能会是一个危险的先例。
交易已经在交易池中
这是做攻击的少数几次情况下 可能 是可以接受的。如果你看到一个恶意交易在交易池中，你知道攻击即将发生。在这种情况下，可能 可以抢先进行攻击并优先利用协议。不过，这仍然可能有法律后果，除非该协议有一个 安全港协议。
安全港是一个框架，允许协议为在主动攻击期间为白帽攻击者提供法律保护，以帮助资产的恢复。安全联盟（SEAL）为希望确保白帽可以在没有法律后果的情况下抢先进行恶意交易的协议提供了一个最小示例。
这些通常包括一个地址/位置，以便白帽在攻击发生后立即将资金发送到此。
不过，关于该协议的重要考虑是，它们仅适用于 活跃 攻击。例如，一个恶意交易仅存在于交易池中。如果一个安全研究人员出去并试图发起攻击，安全港协议将失效。
总结
如果你从这篇文章中吸取了任何内容，请记住以下几点：
- 利用一个协议，无论意图如何，都是错误的第一步
- 如果你发现一个活跃的漏洞，请联系协议
- 规则 #1 的唯一例外 可能是如果：
- 在交易池中已经存在一个恶意交易
- 已有安全港协议存在
祝你快乐，进行道德黑客活动！
否则，如果你准备开始进行白帽攻击，请查看 CodeHawks，顶级竞争审计平台，在公开比赛中发现漏洞时给予审计员奖励。
