Comprobaciones de Signatario y Propietario

La validación faltante de signatario y propietario causa más exploits de programas de Solana que cualquier otra clase de error. Cada instrucción debe probar que las cuentas correctas firmaron y pertenecen a los programas esperados.

Receta

Tarjeta de receta de referencia rápida - lista para copiar y pegar.

#[derive(Accounts)]
pub struct TransferOut<'info> {
    #[account(mut, has_one = authority)]
    pub vault: Account<'info, Vault>,
    pub authority: Signer<'info>,
}
 
// Comprobación manual de signatario en una autoridad UncheckedAccount
require!(ctx.accounts.authority.is_signer, ErrorCode::MissingSigner);
 
// Comprobación manual de propietario en una mint UncheckedAccount (una mint no firma)
require_keys_eq!(*ctx.accounts.mint.owner, anchor_spl::token::ID, ErrorCode::InvalidOwner);

Cuándo usar esto:

• Cualquier instrucción que mueva lamports o tokens.
• Cambios de autoridad y actualizaciones de configuración.
• Aceptar AccountInfo de metadatos proporcionados por el usuario.
• Revisar hallazgos de auditoría sobre control de acceso.

Ejemplo de Trabajo

use anchor_lang::prelude::*;
use anchor_spl::token::{self, Token, TokenAccount, Transfer};
 
#[account]
pub struct Vault {
    pub authority: Pubkey,
    pub bump: u8,
}
 
#[derive(Accounts)]
pub struct Withdraw<'info> {
    #[account(
        mut,
        seeds = [b"vault", authority.key().as_ref()],
        bump = vault.bump,
        has_one = authority,
    )]
    pub vault: Account<'info, Vault>,
 
    #[account(mut)]
    pub vault_token: Account<'info, TokenAccount>,
 
    #[account(mut)]
    pub destination: Account<'info, TokenAccount>,
 
    pub authority: Signer<'info>,
    pub token_program: Program<'info, Token>,
}
 
pub fn withdraw(ctx: Context<Withdraw>, amount: u64) -> Result<()> {
    // Vincula la Pubkey a una variable local primero - `authority.key()` devuelve por valor y
    // la temporal se eliminaría mientras `seeds` todavía la toma prestada (E0716).
    let authority_key = ctx.accounts.authority.key();
    let bump = ctx.accounts.vault.bump;
    let seeds: &[&[u8]] = &[b"vault", authority_key.as_ref(), &[bump]];
    let signer = &[seeds];
 
    let cpi = CpiContext::new_with_signer(
        ctx.accounts.token_program.to_account_info(),
        Transfer {
            from: ctx.accounts.vault_token.to_account_info(),
            to: ctx.accounts.destination.to_account_info(),
            authority: ctx.accounts.vault.to_account_info(),
        },
        signer,
    );
    token::transfer(cpi, amount)?;
    Ok(())
}

Lo que esto demuestra:

• Signer en authority impone la aprobación humana.
• has_one = authority vincula el estado de la bóveda a la clave pública del signatario.
• PDA firma la transferencia de tokens a través de semillas de invoke_signed.

Análisis Profundo

Cómo Funciona

• La transacción incluye una firma Ed25519 por cada clave firmante.
• El runtime establece is_signer en las metadatos de cuenta coincidentes.
• El campo owner en las cuentas restringe qué programa puede escribir datos.
• Las macros de Anchor codifican patrones comunes de signatario/propietario; el código nativo utiliza comprobaciones de AccountInfo.

Matriz de Comprobación

Notas de Rust

// Equivalente de programa nativo
if !authority.is_signer {
    return Err(ProgramError::MissingRequiredSignature);
}
if vault.owner != program_id {
    return Err(ProgramError::IncorrectProgramId);
}

Trampas Comunes

• Signatario en la cuenta incorrecta - El pagador de tarifas firma pero la autoridad no. Solución: has_one o constraint = authority.key() == vault.authority explícito.
• PDA como autoridad sin invoke_signed - CPI falla o usa un signatario incorrecto. Solución: Pasar semillas a CpiContext::new_with_signer.
• Propietario de la cuenta de token - Account<'info, TokenAccount> ya comprueba que la cuenta es propiedad del programa SPL Token, y .owner en ese tipo es el campo de autoridad de token, no el propietario del programa. Solución: Añadir una comprobación sobre la autoridad del token: constraint = vault_token.owner == vault.key().
• Sysvar como UncheckedAccount - El atacante pasa una sysvar falsa. Solución: Usar cuentas tipadas Sysvar<'info, Clock>.
• Multifirma - La multifirma SPL requiere metadatos de signatario adicionales. Solución: Coincidir con el diseño de multifirma del programa de tokens.
• Restauración de cuenta cerrada - Una cuenta cerrada puede ser reasignada en la misma transacción en algunos patrones. Solución: Ver las protecciones de reinicialización.

Alternativas

Preguntas Frecuentes

Relacionado

• Conceptos Básicos de Seguridad - introducción al modelo de amenazas
• Ataques de Validación de Cuentas - confusión de tipos
• Ataques de PDA y Semillas - autoridad de PDA
• Catálogo de Ataques de Sealevel - lista de verificación completa

Versiones de Stack: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0, y LiteSVM 0.6.x.