Anchor
anchor docs
Anchor docs
Crate anchor_lang
Crate anchor_spl
Constraints ref: Accounts in anchor_lang - Rust
vulns with anchor
kinds of vulns which can be avoid by anchor:
- Account ownership (owner is program id)
- Account Type Confusion
- Account (re)init
TLDR; Account constraints
Anchor can't protect program from:
- Signer auth (But the Signer type is really useful )
- Arbitrary CPI
- CPI auth
- Accounts cache after CPI
- Bump seed canonicalization
- Overflow
- Constraints are not working on ctx.remaining_accounts
- Oracle status (e.g. pyth oracle)
- 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?