Frankcastleauditor/Solana-Audit-Arena

# ⚔️ Solana 审计竞技场 **每周一次的 Solana 智能合约安全竞赛 — 由 [Frank Castle](https://x.com/0xcastle_chain) 主办** ## 这是什么？ Solana 审计竞技场是一个免费、开放的周赛，安全研究人员在这里审计 AI 生成的 Solana 程序，以尽可能多地发现漏洞。 每周一，这里会发布一个新的 Anchor 程序。所有程序均使用 [Safe Solana Builder](https://github.com/Frankcastleauditor/safe-solana-builder) 构建 —— 这是一个专注于安全的 Solana 程序生成器，强制执行安全模式和源自审计的规则。你有**一周的时间**来查找 bug、编写 PoC，并将你的发现作为 GitHub Issue 提交。社区会公开审查和讨论每一份提交。Frank Castle —— 一位拥有 100 多次协议审计经验的资深 Solana 安全研究员 —— 将对有效性和严重性做出最终裁决。 **之所以存在这个项目，是因为初级安全研究人员值得拥有一个试炼场。** 对于新手来说，目前没有清晰的路径让他们在真实的 Solana 代码库中磨练技能、凭实力竞争并获得关注。这个竞技场就是那条路径。 ## 为什么要参加？ - **建立你的审计履历**，在公开排行榜上展示经过验证的发现 - **从真实的漏洞模式中学习**，涵盖 DeFi、Staking、治理、稳定币等领域 - **获得社区反馈** —— 每一份提交都会被公开审查和讨论 - **获得关注** —— 顶级表现者将在 Frank Castle 的 X（拥有 4k+ 关注安全的粉丝）上获得推介 - **最高奖项**：领先的研究人员将**受邀加入与 Frank Castle 的私有审计项目** —— 真实的有偿工作、真实的经验、真实的资历。 ## 运作机制 ### 每周周期 | 时间 | 内容 | |-----|-------------| | **周一** | 发布新程序 → 在 X 上发布公告帖并附上此仓库链接 | | **周一至周日** | 开放提交窗口 → 将发现作为 GitHub Issues 提交 | | **下周一** | Frank 验证、评分并在 X 上发布结果 → 公布新程序 | ### 时间线 - **提交窗口**：周一 00:00 UTC → 周日 23:59 UTC（完整的 7 天） - **社区审查**：持续进行 —— 任何人都可以在窗口期间及之后对任何提交发表评论 - **最终结果**：在下一个周一与新程序公告一同发布 - **逾期提交**：不予接受。截止期限是硬性的。 ## 提交格式 将每个发现作为本仓库中的一个**独立 GitHub Issue** 提交。 ### Issue 标题格式 ``` [Week X] [Severity] Short descriptive title ``` 示例：`[Week 3] [Critical] Unauthorized withdrawal via missing signer check in unstake()` ### Issue 正文模板 请严格使用此模板 —— 未遵循格式的 Issues 将被标记为 `invalid-format`，并在更正前不予评分（这将消耗你的提交窗口时间）。 ``` ## 发现 **Week**: [NUMBER] **Researcher**: [Your GitHub handle + X handle] **Severity**: [Critical / High / Medium / Low / Informational] **Category**: [e.g., Missing signer check, Arithmetic overflow, PDA seed collision, CPI validation, etc.] **Affected function**: [instruction name or function] ## 描述 [Clear explanation of the vulnerability — what's wrong and why it matters] ## 影响 [What can an attacker do? Quantify if possible — e.g., "drain all vault funds", "bypass admin check"] ## Proof of Concept - REQUIRED [Provide a concrete PoC that demonstrates the exploit. This can be:] - A TypeScript/Rust test that triggers the vulnerability - A step-by-step transaction sequence with account setups - A code diff showing the exact exploit path with expected vs actual behavior [The PoC must be detailed enough that someone can independently verify the vulnerability without guesswork.] ## 建议修复 [How to patch it — include code if possible] ``` ### Issue 标签 Frank Castle 将在评审期间对 Issues 进行标记： | 标签 | 含义 | |-------|---------| | `valid` | 确认的漏洞，已评分 | | `invalid` | 非真实漏洞 | | `duplicate` | 相同发现已由其他研究人员更早提交 | | `invalid-format` | 未遵循提交模板 | | `critical` / `high` / `medium` / `low` | 评委判定的最终严重性 | | `best-find` | 本周最佳发现 | | `week-N` | 发现所属的周次 | ## 社区审查 **每一份提交都是公开的。** 这是有意为之。 - **任何人**都可以对任何 GitHub Issue 发表评论 —— 质疑严重性、询问 PoC、建议更好的修复方案或确认该发现 - 鼓励社区讨论，这有助于每个人学习 - 评论**不**影响评分 —— 只有 Frank Castle 的最终判决决定积分 - 保持建设性。毫无解释地贬低他人的提交是没有帮助的 - 如果你发现某人的 PoC 实际上不起作用，请解释原因 —— 那是有价值的反馈 ### 为什么要公开提交？ 1. **透明度** —— 每个人都能看到发现是如何被评判的 2. **学习** —— 阅读其他研究人员的提交能教你新的模式 3. **问责制** —— PoC 由社区验证，而不仅仅是一个人 4. **归档** —— Issues 标签页变成了一个可搜索的 Solana 漏洞模式数据库 ## 评分 | 严重性 | 积分 | |----------|--------| | Critical | 10 | | High | 7 | | Medium | 3 | | Low | 1 | | Informational | 0（确认但无积分） | ### 严重性定义 - **Critical**：直接的资金损失、协议完全被接管或所有资产被永久冻结。除了正常交易外无其他前置条件。 - **High**：在特定但现实的条件下造成的重大资金损失、权限提升或核心访问控制被绕过。 - **Medium**：有限的资金损失、拒绝服务或需要特定条件或影响有限的状态损坏。 - **Low**：不会导致资金损失的轻微问题、最佳实践违规或 Gas 优化。 - **Informational**：代码质量建议、文档缺失或没有实际攻击路径的理论问题。 ### 评分规则 - **首位发现者获全额积分。** 如果多名研究人员报告了相同的漏洞，只有第一个有效提交（以 GitHub Issue 时间戳为准）获得积分。重复提交被标记为 `duplicate` 并得 0 分。 - **PoC 是强制性的。** 没有有效概念验证（Proof of Concept）的提交将被标记为 `invalid-format` 且不予评分。无例外 —— 如果你无法证明它，它就算不上一个发现。 - **严重性是最终的。** Frank Castle 在考虑社区讨论后分配最终严重性。该分类用于评分目的。 - **无效发现**：提交明显不是漏洞的发现（没有分析的误报）可能会导致每个无效发现被扣 1 分，以 discourage 垃圾信息。请运用判断力 —— 如有疑问，解释你的推理，这不会被计入扣分。 ## 提交规则 1. **每个发现一个 Issue。** 不要将多个漏洞打包到一个 Issue 中。每个漏洞都需要有自己独立的 Issue 和 PoC。 2. **仅限个人。** 不允许团队提交。你可以公开讨论一般的 Solana 安全概念，但协调提交将被取消资格。 3. **仅限原创工作。** 不接受通过自动扫描器运行程序并粘贴原始输出。你必须在描述中展示你的理解并提供真实的 PoC。 4. **需要 PoC。** 每一份提交必须包含一个能独立验证漏洞的概念验证（Proof of Concept）。“这看起来不对”不是一个发现。“这是确切利用方法”才是。 5. **提交后不可编辑。** 一旦你提交了 Issue，请不要编辑正文。如果你需要补充背景信息，请添加评论。提交后编辑原始 Issue 正文可能会导致该发现被取消资格。 ## 排行榜 **总排行榜** 维护在本仓库的 [`LEADERBOARD.md`](./LEADERBOARD.md) 中，并会在每周一随当周结果更新。 ### 亮点 每周，X 上的结果帖子将展示： - 本周 **前 3 名研究人员** - 本周 **最佳发现**（最具创意或影响力） - **新星研究人员** —— 进步最大的新参与者 ## 评审 所有提交的**最终判决**均由 **Frank Castle** ([@0xcastle_chain](https://x.com/0xcastle_chain)) 做出，并参考社区讨论。 Frank 已审计 100 多个协议和 50 多个 Solana 程序，识别出 300 多个高危和严重漏洞。过往合作方包括 Cantina、Spearbit（资深研究员）和 Pashov Audit Group。 ## 常见问题 **Q: 我是一个完全的新手。我可以参加吗？** A: 当然可以。这就是为你准备的。你在一周内尝试破解真实程序中学到的东西，比几个月的教程还要多。即使你第一周发现了 0 个 bug，你也会通过阅读其他人的提交学到东西。 **Q: 我需要是 Rust 专家吗？** A: 你需要能够阅读 Rust 并理解 Solana 的账户模型。如果你能理解 Anchor 程序的逻辑，你就准备好了。 **Q: 参加有费用吗？** A: 没有。免费。永远免费。 **Q: 我可以使用 AI 工具辅助审计吗？** A: 可以 —— 但你必须理解并验证你提交的每一个发现。没有分析的原始扫描器输出将被拒绝。如果你将 AI 作为起点，然后自己验证并解释该发现，那是允许的。你的 PoC 仍然需要有效。 **Q: 程序会随时间推移变难吗？** A: 会。早期的程序会有比较明显的 bug。随着社区水平的提升，复杂度也会提升。 **Q: 我如何获得“加入私有审计”的奖品？** A: 在评估点（会提前公布）成为总排行榜上的领先研究员。这不仅仅关乎积分 —— 一致性、发现质量和展示出的成长都会被纳入考量。 **Q: 公开提交不会让人互相抄袭吗？** A: 时间戳很重要。第一个有效提交获得积分。如果有人在你之后提交了相同的发现，他们会被标记为 `duplicate`。这实际上是奖励速度和信心 —— 确定后就提交，不要等待。 **Q: 我可以评论其他人的提交吗？** A: 可以 —— 这正是重点所在。社区审查能让每个人变得更强。挑战 PoC、建议更好的修复、确认发现。只要保持建设性。 ## 链接 - **X**: [@0xcastle_chain](https://x.com/0xcastle_chain) - **GitHub**: [Frankcastleauditor](https://github.com/Frankcastleauditor) - **Safe Solana Builder**: [github.com/Frankcastleauditor/safe-solana-builder](https://github.com/Frankcastleauditor/safe-solana-builder) *由 Frank Castle 构建。逐个研究员地守护 Solana 安全。*

标签：AI生成代码, Anchor框架, ASN解析, DeFi, Proof of Concept, Rust, Solana, Web3安全, 加密货币, 区块链安全, 去中心化应用, 可视化界面, 安全众测, 开发者社区, 智能合约审计, 编程竞赛, 网络安全竞赛, 网络流量审计, 通知系统, 配置错误, 链上安全