Rust contratos inteligentes en ataque de denegación de servicio

El ataque de denegación de servicio ( DoS ) puede hacer que los contratos inteligentes no funcionen correctamente durante un tiempo o incluso de forma permanente. Las principales razones incluyen:

1. La lógica del contrato tiene defectos de alta complejidad computacional, lo que provoca que el consumo de Gas supere el límite.

2. Al llamar a través de contratos, la ejecución del contrato depende de contratos externos poco confiables, lo que causa bloqueos.

3. El propietario del contrato pierde la clave privada, no puede ejecutar funciones privilegiadas para actualizar el estado importante.

A continuación, analizaremos las vulnerabilidades de ataque de denegación de servicio (DoS) a través de ejemplos concretos.

1. Recorrer estructuras de datos grandes controladas externamente

A continuación se muestra un contrato simple para "dividendos" para los usuarios:

ó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(), &0).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"); for cur_account in 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 ); } }

Aquí, el tamaño de self.registered es ilimitado, lo que permite a los usuarios malintencionados controlarlo para que se vuelva demasiado grande, lo que provoca que los costos de Gas superen el límite al ejecutar distribute_token.

Solución: No se recomienda recorrer estructuras de datos grandes controladas externamente. Se puede adoptar el modo de retiro, permitiendo a los usuarios recuperar "dividendos" por sí mismos.

2. La dependencia del estado entre contratos causa bloqueos

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!(amount > 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::gas_prepagado() - GAS_FOR_SINGLE_CALL * 4, (.then)ext_self::account_resolve) sender_id, cantidad, &env::current_account_id((, 0, GAS_FOR_SINGLE_CALL * 3, (); } log!) "current_leader: {} highest_bid: {}", self.current_leader, self.highest_bid ); PromiseOrValue::Value(0) }

Aquí, devolver los tokens al anterior mejor postor es un requisito para actualizar el estado. Si la cuenta de ese usuario ha sido cancelada, causará un bloqueo en todo el proceso de subasta.

Método de solución: considere que las llamadas externas pueden fallar, aumente el manejo de errores. Se pueden almacenar temporalmente los tokens no reembolsables, y posteriormente permitir que el usuario los retire por sí mismo.

3. Pérdida de la clave privada del propietario

Se establecieron algunas funciones clave para que solo el propietario pueda ejecutarlas. Si el propietario no puede cumplir con su función, (, como la pérdida de la clave privada ), resultará en el contrato sin poder funcionar correctamente.

Método de solución: establecer múltiples propietarios para gobernanza conjunta, o utilizar solicitudes de múltiples firmas en lugar del control de un solo propietario, para lograr una gobernanza descentralizada.

<accountid,balance><accountid,>