Análisis de vulnerabilidades de ataque DoS en contratos inteligentes Rust

El ataque DoS (Denial of Service) puede hacer que los contratos inteligentes no puedan ser utilizados normalmente durante un período de tiempo o incluso de forma permanente. Las principales razones incluyen:

1. Existen defectos en la lógica del contrato. Por ejemplo, algunas funciones públicas no consideran la complejidad computacional, lo que provoca que el consumo de Gas exceda el límite.

2. Dependencia del estado de ejecución de contratos externos al llamar a contratos cruzados. La ejecución de contratos externos puede no ser confiable y puede hacer que este contrato quede bloqueado.

3. Factores humanos, como la pérdida de la clave privada por parte del propietario del contrato, que impiden que el estado importante del sistema se actualice a tiempo.

A continuación, se analizará la vulnerabilidad de ataque DoS a través de ejemplos concretos.

1. Recorrido en bucle de estructuras de datos grandes que pueden ser modificadas externamente

A continuación se presenta un contrato simple de "dividendos" para usuarios registrados:

óxido #[near_bindgen] #[derive(BorshDeserialize, BorshSerialize)] pub struct Contract { pub registered: Vec\u003caccountid\u003e, pub accounts: UnorderedMap\u003caccountid, balance=""\u003e, }

pub fn register_account(&mut self) { if self.accounts.insert(&env::predecessor_account_id(), &60).is_some() { env::panic("La cuenta ya está registrada".to_string().as_bytes()); } else { self.registered.push(env::predecessor_account_id()); } log!("Cuenta registrada {}", env::predecessor_account_id()); }

pub fn distribute_token(&mut self, amount: u128) { assert_eq!(env::predecessor_account_id(), DISTRIBUTOR, "ERR_NOT_ALLOWED");

para cur_account en self.registered.iter() {
    let balance = self.accounts.get(&cur_account).expect("ERR_GET");
    self.accounts.insert(\u0026cur_account, \u0026balance.checked_add(amount).expect("ERR_ADD"));
    log!("Intenta distribuir a la cuenta {}", &cur_account);
    
    ext_ft_token::ft_transfer(
        cur_account.clone(),
        cantidad,
        &FTTOKEN,
        0,
        GAS_FOR_SINGLE_CALL
    );
}

}

Los datos del estado del contrato self.registered no tienen un tamaño limitado, lo que permite a los usuarios maliciosos manipularlo para que sea demasiado grande. Esto provoca que la ejecución de distribute_token falle debido a un consumo de Gas que excede el límite.

Recomiendo cambiar al modo de retiro: la parte contratante primero lleva la contabilidad, el usuario puede recuperar la recompensa por sí mismo a través de la función withdraw. El contrato solo necesita mantener la cantidad de recompensas de un único usuario.

2. La dependencia del estado entre contratos provoca el bloqueo de contratos

Considera un contrato de "subasta":

óxido #[near_bindgen] #[derive(BorshDeserialize, BorshSerialize)] pub struct Contract { pub registered: Vec\u003caccountid\u003e, pub bid_price: UnorderedMap\u003caccountid,balance\u003e, pub current_leader: AccountId, pub highest_bid: u128, pub reembolso: bool }

PromiseOrValue { assert!(cantidad > self.highest_bid);

if self.current_leader == DEFAULT_ACCOUNT {
    self.current_leader = sender_id;
    self.highest_bid = amount;
} else {
    ext_ft_token::account_exist(
        self.current_leader.clone)(,
        &FTTOKEN,
        0,
        env::prepaid_gas() - GAS_FOR_SINGLE_CALL * 4,
    (.then)ext_self::account_resolve)
        sender_id,
        cantidad,
        &env::current_account_id((,
        0,
        GAS_FOR_SINGLE_CALL * 3,
     ();
}

log!)
    "líder_actual: {} oferta_más_alta: {}", 
    self.current_leader,
    self.highest_bid
);

PromiseOrValue::Value(0)

}

La lógica de este contrato depende de que se devuelva el token del licitador más alto anterior para poder actualizar la nueva oferta más alta. Si la cuenta anterior ha sido cancelada, la nueva oferta será bloqueada.

Método de solución: considerar la posibilidad de que las llamadas externas puedan fallar y aumentar el manejo de errores. Se pueden almacenar temporalmente los tokens no recuperables, y luego el usuario puede extraerlos por sí mismo.

3. Pérdida de la clave privada del propietario

Algunas funciones del contrato están configuradas para ser ejecutadas solo por el propietario, utilizadas para cambiar variables clave del sistema. Si el propietario no puede cumplir con su función (, como la pérdida de la clave privada ), estas funciones no estarán disponibles, lo que podría llevar a la paralización del contrato.

Método de solución:

• Configurar múltiples propietarios para la gobernanza conjunta
• Adoptar un esquema de múltiples firmas en lugar de un control de permisos de propietario único
• Implementar un mecanismo de gobernanza descentralizada

Un diseño de permisos razonable y un mecanismo de gobernanza pueden reducir eficazmente el riesgo de fallos de punto único y mejorar la robustez del contrato.

<accountid,balance><accountid,>