Skip to main content

Anchor

anchor docs

Anchor docs

Anchor - Introduction

Crate anchor_lang

来自 anchor_lang - Rust

Crate anchor_spl

来自 anchor_spl - Rust

Constraints ref: Accounts in anchor_lang - Rust

vulns with anchor

kinds of vulns which can be avoid by anchor:

  1. Account ownership (owner is program id)
  2. Account Type Confusion
  3. Account (re)init

TLDR; Account constraints


Anchor can't protect program from:

  1. Signer auth (But the Signer type is really useful )
  2. Arbitrary CPI
  3. CPI auth
  4. Accounts cache after CPI
  5. Bump seed canonicalization
  6. Overflow
  7. Constraints are not working on ctx.remaining_accounts
  8. Oracle status (e.g. pyth oracle)
  9. Two of the Anchor account types, AccountInfo and UncheckedAccount do not implement any checks on the account being passed. But the complie will throw an error if there is not a /// CHECK comment for it.

Reference

Reference:

10 vulnerabilities to avoid when writing Solana programs.

来自 pencilflip 🍄 on Twitter / X

漏洞随笔:通过 Jet Protocol 任意提款漏洞浅谈 PDA 与 Anchor 账号验证

来自 漏洞随笔:通过 Jet Protocol 任意提款漏洞浅谈 PDA 与 Anchor 账号验证

The Vulnerabilities You'll Write With Anchor

来自 The Vulnerabilities You'll Write With Anchor | Zellic — Research

solana-smart-contract-security-best-practices

来自 GitHub - slowmist/solana-smart-contract-security-best-practices

issues?

  • ✅Issue1: if anchor AccountLoader::load_mut() check the account owner? How does it call the try_from() ? -> It does check.
  • Issue2: Why the authority check is so important in the solana program? Solana splits the code(program) and data(account). So the main storage of a contract should be the main authority key for the whole program. And anyone can apply a new storage created by the program. So how to verify the storage is applied by the program admin?