Busque em todas as páginas da documentação
A segurança de programas Solana é segurança de conta. Chamadores escolhem quais contas e programas entram em uma instrução; Sealevel impõe bloqueios, regras de escrita de propriedade e orçamentos de computação, não o saldo do seu cofre, lista de administradores ou vínculo de mint.
Esta página é o mapa conceitual para Segurança e Auditoria de Programa - superfície de ataque Sealevel, validação de conta, verificações de signatário e proprietário, ataques PDA e de semente, reinicialização, aritmética, risco de CPI e reentrância, e um fluxo de auditoria prático no Agave 4.1.1.
#[derive(Accounts)], preparar para auditoria externa, triar achados ou ensinar o modelo de ameaças Solana.UncheckedAccount e remaining_accounts reintroduzem risco; revisões de segurança não substituem fuzzing ou revisão de design econômico.Sealevel executa programas como executáveis sem estado. O estado durável reside em contas que a transação lista antecipadamente. Clientes (ou atacantes) fornecem essas contas, flags de signatário e flags de escrita (is_writable). O runtime verifica se os signatários declarados realmente assinaram e se apenas o programa proprietário pode escrever dados da conta. Ele não sabe que "esta TokenAccount deve corresponder ao mint do cofre" ou "apenas a autoridade pode sacar."
Essa lacuna é a superfície de ataque:
Client / attacker supplies:
program_id | instruction data | AccountMeta[] (keys, is_signer, is_writable)
Runtime guarantees:
signatures match is_signer | locks from is_writable | owner write rules | CU budget
Your program must guarantee:
right identity signed | right owners and types | right PDAs | right amounts | safe CPIsFail closed é a postura padrão: se a validação estiver incompleta, rejeite com um erro tipado. Nunca assuma "clientes honestos" ou "nosso frontend só constrói transações boas." Frontends e indexadores não fazem parte da fronteira de confiança; verificações on-chain sim.
O Anchor 0.32.1 codifica verificações comuns (Signer, Account<T>, seeds, has_one, Program<T>). Isso não constitui uma revisão completa. Lacunas aparecem com AccountInfo, UncheckedAccount, remaining_accounts, init_if_needed sem guarda, e restrições de regras de negócio que não podem ser expressas.
Modelo de ameaça para um programa típico de cofre ou mercado:
| Ativo em risco | Falha típica | Controle de primeira linha |
|---|---|---|
| Tokens / lamports | Signatário ausente ou conta de token incorreta | Signer, restrições de mint/proprietário |
| Autoridade admin / config | Reinicialização ou has_one ausente | Inicialização única, autoridade armazenada + signatário |
| Contabilidade do protocolo | Overflow, arredondamento incorreto | checked_*, intermediários u128 |
| Composabilidade | CPI para programa impostor | Lista de permissões de ID de programa, CEI |
| Identidade do estado | PDA incorreta ou confusão de tipo | seeds + bump, discriminadores |
Atacantes passam contas que parecem utilizáveis: mesmo tamanho, de propriedade do seu programa, ou deserializáveis em um tipo incorreto. Validação significa mais do que "deserializa".
Checklist por papel da conta:
Account<T> para seus tipos; require_keys_eq! para SPL Token, Sysvar, etc.).Vault nunca seja User.mut.seeds + bump armazenado para que o endereço seja derivado, não escolhido livremente.#[derive(Accounts)]
pub struct Deposit<'info> {
// `has_one = mint` exigiria um campo de conta `mint` nesta struct; a
// restrição explícita de mint abaixo cobre a ligação sem um.
#[account(mut, has_one = authority)]
pub vault: Account<'info, Vault>,
#[account(
mut,
constraint = user_ata.mint == vault.mint @ ErrorCode::MintMismatch,
constraint = user_ata.owner == user.key() @ ErrorCode::WrongAtaOwner,
)]
pub user_ata: Account<'info, TokenAccount>,
pub authority: Signer<'info>,
pub user: Signer<'info>,
pub token_program: Program<'info, Token>,
}UncheckedAccount e AccountInfo brutos pulam as verificações de proprietário e discriminador até que você as adicione. Trate cada campo assim como uma falha até que seja provado validado.
Signatário: qualquer caminho que move fundos, altera autoridade, fecha contas ou atualiza configurações sensíveis requer uma assinatura criptográfica da chave correta (ou uma PDA assinada via invoke_signed com sementes controladas pelo programa).
Proprietário: apenas o programa proprietário pode reescrever dados. Ler uma conta que seu programa não possui sem verificar o proprietário é como a confusão de tipo e a entrada de mints falsos. Para contas de token, o proprietário deve ser o programa Token ou Token-2022 que você pretende; para seu estado, o proprietário deve ser seu program_id.
Padrão crítico comum: o cofre armazena authority: Pubkey, mas a instrução nunca exige authority como Signer ou nunca o vincula com has_one.
PDAs são a autoridade e a identidade do endereço. Sementes fracas ou ambíguas permitem que um atacante apresente uma PDA diferente que seu programa ainda "aceita".
Regras gerais:
bump = account.bump depois (sem busca ambígua de bump em caminhos críticos).b"vault", tags de versão).#[account(
seeds = [b"vault", authority.key().as_ref(), mint.key().as_ref()],
bump = vault.bump,
)]
pub vault: Account<'info, Vault>,A inicialização (init) escreve discriminadores, autoridades e saldos. Reexecutar a inicialização (ou init_if_needed sem uma flag) pode redefinir o administrador para o atacante ou reativar uma forma de conta fechada.
Prefira init único para estado permanente. Se precisar de init_if_needed, exija !is_initialized (ou equivalente) antes de escrever campos de autoridade, e nunca reabra contas fechadas sem um caminho deliberado e auditado. Ao fechar, zere os dados / discriminador e transfira os lamports para que a conta não possa ser tratada como estado ativo.
Builds de release BPF fazem wrap em operações +, -, * simples. A matemática de cofres, cunhagem de shares, acúmulo de taxas e fórmulas AMM precisam de checked_* (ou operações saturating onde intencional) e frequentemente intermediários u128 antes de converter de volta para u64.
O arredondamento deve favorecer o protocolo em cunhagens e resgates voltados ao usuário, para que poeira não possa ser explorada para obter valor gratuito. Divisão por zero e casos extremos de pool vazio são bugs de segurança, não meros problemas de UX.
A invocação entre programas estende a confiança a outro programa. Riscos:
ReentrancyNotAllowed), mas pode modificar contas que você já desserializou, então sua cópia em memória fica desatualizada. Uma instrução de nível superior posterior na mesma transação também pode ler saldos que ainda parecem pré-atualização.Mitigações: liste permissões de chamados com Program<'info, T> ou require_keys_eq!; atualize o estado do programa antes da CPI externa (CEI); evite callbacks não confiáveis, a menos que você projete verificações explícitas de dívida estilo flash-loan; passe apenas as contas que o chamado precisa.
vault.balance = vault.balance.checked_sub(amount).ok_or(ErrorCode::Overflow)?;
// efeitos primeiro, depois interação
token::transfer(cpi_ctx, amount)?;Solana não é idêntica à reentrância EVM, mas ordem de chamada incorreta e alvos CPI não confiáveis ainda resultam em perda de fundos.
O trabalho de segurança é tanto um processo quanto código:
Accounts ou aritmética.| Camada de controle | O que captura | O que não captura | Quando reforçar |
|---|---|---|---|
| Tipos de conta Anchor | Proprietário + discriminador para Account<T>, muitas restrições de PDA | Regras de negócio, caminhos Unchecked | Padrão para todas as contas de estado |
require_* manual | Invariantes relacionais e econômicas | Fácil de omitir em novas instruções | Toda revisão de novo handler |
| CEI + lista de permissões de programa | Roubo clássico de CPI / programas impostores | Bugs de design econômico | Qualquer movimentação de token ou callback |
| Matemática verificada + testes de propriedade | Limites de overflow e matemática de share | Jogos de oráculo e MEV | Cofres, AMMs, empréstimos |
| Auditoria externa + bounty | Novos olhares, classes conhecidas do catálogo | Ataques de orçamento infinito, upgrades futuros | Pré-lançamento e upgrades importantes |
Oráculos são entradas não confiáveis: verifique o proprietário do feed, a atualidade e a confiança; falhe fechado em dados ruins.
Extensões Token-2022 (hooks, delegados permanentes) alteram quem pode mover tokens. Fixe o ID do programa de token; não assuma a semântica clássica do SPL Token.
Fechamento e aluguel (rent): exija o signatário e o destino corretos; zere os dados para que as contas não possam ser reativadas com verificações fracas. Prefira close = do Anchor com restrições.
Autoridade de upgrade é a raiz. Multisig ou governança, builds verificáveis e imutabilidade opcional após maturidade são segurança operacional.
Clientes (@solana/kit 7.0.0, carteiras) ajudam apenas usuários honestos. Programas defendem contra todos os outros.
No Agave 4.1.1 (CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1), exercite conjuntos adversariais de contas no LiteSVM ou em validadores locais. Trate cada nova instrução como uma nova superfície de ataque.
Unchecked, restrições incorretas e bugs de matemática ainda são lançados.Tudo o que o chamador pode escolher: quais contas e programas aparecem, quem assina, dados da instrução e alvos de CPI. O runtime não impõe seus invariantes de mint, autoridade ou saldo. Veja Catálogo de Ataques Sealevel.
Sem um Signer obrigatório (ou caminho invoke_signed de PDA), qualquer chave de conta pode ser nomeada como "autoridade", enquanto apenas o pagador de taxa realmente assina. Isso permite saques não autorizados e tomada de controle administrativo. Veja Verificações de Signatário e Proprietário.
Passar um cofre, conta de token, mint ou configuração diferente do que o protocolo pretende, muitas vezes ainda de propriedade de um programa plausível. Corrija com restrições relacionais (has_one, igualdade de mint, sementes). Veja Ataques de Validação de Conta.
Se as sementes omitirem campos de identidade ou os bumps não forem canônicos, os atacantes derivam PDAs alternativas que sua instrução ainda aceita, personificando cofres ou escrows. Armazene os bumps e fixe listas completas de sementes. Veja Ataques de PDA e Semente.
Quando init pode ser executado novamente em estado ativo: init_if_needed sem guardas, discriminadores ausentes, ou contas fechadas que são recriadas sob verificações fracas. Veja Ataques de Reinicialização.
Sim, para caminhos de valor. A aritmética simples pode fazer wrap on-chain; fórmulas de share e swap devem usar checked_* e arredondamento cuidadoso. Veja Aritmética e Overflow.
Revisado por Chris St. John·Última atualização: 15 de jul. de 2026