solana-security

Solana 安全审计

用于 Solana 程序的系统化安全审查框架，支持 Anchor 和原生 Rust 实现。

审查流程

遵循以下系统化的 5 步流程，开展全面的安全审计：

步骤 1：初步评估

了解程序的上下文和结构：

• 框架：Anchor 还是原生 Rust（检查是否存在 use anchor_lang::prelude::*）
• Anchor 版本：检查 Cargo.toml 中的兼容性和已知问题
• 依赖项：预言机（Pyth、Switchboard）、外部程序、代币程序
• 程序结构：统计指令数量、识别账户类型、分析状态管理
• 复杂度：代码行数、指令数量、PDA 模式
• 用途：DeFi、NFT、治理、游戏等

步骤 2：系统化安全审查

对每条指令按以下顺序执行安全检查：

1. 账户验证 — 验证签名者、所有者、可写状态和初始化检查
2. 算术安全 — 检查所有数学运算是否使用 checked_* 方法
3. PDA 安全 — 验证规范 bump 和种子的唯一性
4. CPI 安全 — 确保跨程序调用会验证目标程序
5. 预言机／外部数据 — 验证价格是否过期，以及是否检查预言机状态

→ 详细检查清单请参阅 references/security-checklists.md

步骤 3：检测漏洞模式

扫描常见漏洞模式：

• 类型伪装攻击
• 账户重新加载问题
• 账户关闭不当
• 缺少 lamports 检查
• PDA 替换攻击
• 任意 CPI 漏洞
• 缺少所有权验证
• 整数溢出／下溢

→ 代码示例和攻击场景请参阅 references/vulnerability-patterns.md

步骤 4：架构和测试审查

评估整体设计质量：

• PDA 设计模式和冲突防护
• 账户空间分配和租金豁免
• 错误处理方式和覆盖范围
• 关键状态变更时的事件发出
• 计算预算优化
• 测试覆盖率（单元、集成、模糊测试）
• 升级策略和权限管理

步骤 5：生成安全报告

按照以下结构提供审查结果：

严重程度：

• 🔴 严重：资金可能被盗或丢失，协议完全失效
• 🟠 高：协议可能遭到破坏，可能导致部分资金损失
• 🟡 中：行为不理想、边缘情况、骚扰攻击
• 🔵 低：代码质量、Gas 优化、最佳实践
• 💡 信息性：建议、改进、文档

问题格式：

## 🔴 [CRITICAL] Title

**Location:** `programs/vault/src/lib.rs:45-52`

**Issue:**
Brief description of the vulnerability

**Vulnerable Code:**
```rust
// Show the problematic code

攻击场景： 分步骤说明该问题可能如何被利用

建议：

// Show the secure alternative

参考资料：

• [相关文档或类似攻击的链接]

**Report Summary:**
- Total findings by severity
- Critical issues first (prioritize by risk)
- Quick wins (easy fixes with high impact)
- Recommendations for testing improvements

## Quick Reference

### Essential Checks (Every Instruction)

**Anchor:**
```rust
// ✅ Account validation with constraints
#[derive(Accounts)]
pub struct SecureInstruction<'info> {
    #[account(
        mut,
        has_one = authority,  // Relationship check
        seeds = [b"vault", user.key().as_ref()],
        bump,  // Canonical bump
    )]
    pub vault: Account<'info, Vault>,

    pub authority: Signer<'info>,  // Signer required

    pub token_program: Program<'info, Token>,  // Program validation
}

// ✅ Checked arithmetic
let total = balance.checked_add(amount)
    .ok_or(ErrorCode::Overflow)?;

原生 Rust：

// ✅ Manual account validation
if !authority.is_signer {
    return Err(ProgramError::MissingRequiredSignature);
}

if vault.owner != program_id {
    return Err(ProgramError::IllegalOwner);
}

// ✅ Checked arithmetic
let total = balance.checked_add(amount)
    .ok_or(ProgramError::ArithmeticOverflow)?;

关键反模式

❌ 切勿：

• 使用 saturating_* 算术方法（会掩盖错误）
• 在生产代码中使用 unwrap() 或 expect()
• 使用 init_if_needed 却不进行额外检查
• 跳过签名者验证（“他们不会调用这个……”）
• 使用未经检查的算术运算
• 允许任意 CPI 目标
• 忘记在变更后重新加载账户

✅ 务必：

• 使用 checked_* 算术方法（checked_add、checked_sub 等）
• 使用 ok_or(error)? 处理 Option 解包
• 使用显式的 init 并进行适当验证
• 要求使用 Signer<'info> 或进行 is_signer 检查
• 使用 Program<'info, T> 验证 CPI 程序
• 在会修改状态的外部调用后重新加载账户
• 验证账户所有权、鉴别器和关联关系

框架特定模式

Anchor 安全模式

→ 以下内容请参阅 references/anchor-security.md：

• 账户约束最佳实践
• 常见的 Anchor 特定漏洞
• 使用 CpiContext 的安全 CPI 模式
• 事件发出和监控
• 自定义错误处理

原生 Rust 安全模式

→ 请参阅 references/native-security.md，了解：

• 手动账户验证模式
• 安全的 PDA 派生与签名
• 底层 CPI 安全
• 账户判别符模式
• 租金豁免验证

现代实践（2025）

• 使用 Anchor 0.30+，以获得最新的安全功能
• 实现 Token-2022，并正确处理扩展
• 使用 InitSpace derive 自动计算空间
• 为所有关键状态变更发出事件
• 使用 Trident 框架编写模糊测试
• 在代码注释中记录不变量
• 遵循渐进式路线图：开发 → 审计 → 测试网 → 审计 → 主网

安全基础

→ 请参阅 references/security-fundamentals.md，了解：

• 安全意识与威胁建模
• 核心验证模式（签名者、所有者、可变性）
• 输入验证最佳实践
• 状态管理安全
• 算术安全
• 重入注意事项

常见漏洞

→ 请参阅 references/vulnerability-patterns.md，了解：

• 缺少签名者验证
• 整数溢出／下溢
• PDA 替换攻击
• 账户混淆
• 任意 CPI
• 类型伪装
• 不当关闭账户
• 计算中的精度损失

每种漏洞都包含：

• ❌ 易受攻击的代码示例
• 💥 利用场景
• ✅ 安全替代方案
• 📚 参考资料

安全检查清单

→ 请参阅 references/security-checklists.md，了解：

• 账户验证检查清单
• 算术安全检查清单
• PDA 与账户安全检查清单
• CPI 安全检查清单
• 预言机与外部数据检查清单
• 代币集成检查清单

已知问题与注意事项

→ 请参阅 references/caveats.md，了解：

• Solana 特有的行为与注意事项
• Anchor 框架限制
• 测试盲区
• 常见误解
• 特定版本的问题

安全资源

→ 请参阅 references/resources.md，了解：

• 官方安全文档
• 安全课程与教程
• 漏洞数据库
• 审计报告示例
• 安全工具（Trident、模糊测试器）
• 安全公司与审计人员

每次审计都要提出的关键问题

始终验证以下关键安全属性：

1. 攻击者能否替换账户？

   • PDA 验证、程序 ID 检查、has_one 约束

2. 算术运算能否溢出或下溢？

   • 所有数学运算均使用检查型操作，并防止除以零

3. 所有账户是否都经过适当验证？

   • 是否包含所有者、签名者、可写性和初始化检查

4. 程序是否可能被掏空？

   • 授权检查、重入保护、防止账户混淆

5. 边界情况下会发生什么？

   • 零金额、最大值、已关闭账户、过期数据

6. 外部依赖是否安全？

   • 预言机验证（陈旧性、状态）、已验证 CPI 目标、代币程序检查

审计工作流

开始之前

1. 了解协议的目的和机制
2. 查看文档和规范
3. 设置本地开发环境
4. 运行现有测试并检查覆盖率

审计期间

1. 系统地遵循 5 步审查流程
2. 记录发现的问题、严重程度和修复方案
3. 针对关键问题创建概念验证漏洞利用
4. 测试修复并验证其有效性

审计之后

1. 按严重程度清晰地排列审计发现
2. 提供可执行的修复步骤
3. 修复完成后重新审计
4. 为该协议记录经验教训

安全测试

除了代码审查，还要通过测试验证安全性：

• 单元测试：测试每条指令的边界情况
• 集成测试：测试指令之间的交互
• 模糊测试：使用 Trident 发现意外行为
• 漏洞利用场景：为已发现的漏洞编写 POC
• 升级测试：验证迁移路径的安全性

核心原则

在 Solana 的账户模型中，攻击者可以向任何指令传入任意账户。

安全要求显式验证：

• ✅ 每个账户的所有权
• ✅ 每个账户的类型（判别符）
• ✅ 每个账户之间的关系
• ✅ 每个账户的状态
• ✅ 每项签名者要求
• ✅ 每项算术运算
• ✅ 每次外部调用

不存在任何隐式保障。验证一切，不信任任何事物。