Detalles de las tres vulnerabilidades de ataque DoS en contratos inteligentes y estrategias de prevención

Análisis profundo del ataque de denegación de servicio en contratos inteligentes

ataque de denegación de servicio(DoS)puede llevar a que los contratos inteligentes no puedan ser utilizados de manera temporal o permanente. Las principales razones incluyen:

  1. La lógica del contrato tiene defectos. Por ejemplo, algunas funciones públicas no consideran la complejidad de cálculo, lo que puede superar el límite de Gas y provocar el fallo de la transacción.

  2. En las llamadas entre contratos, la ejecución del contrato depende del estado del contrato externo. La ejecución poco fiable del contrato externo puede bloquear la ejecución de este contrato, como cuando los fondos del usuario están bloqueados y no se pueden depositar ni retirar.

  3. Factores humanos, como la pérdida de la clave privada por parte del propietario del contrato, que impiden la llamada a ciertas funciones privilegiadas y la actualización del estado del sistema importante.

A continuación, se analizará la vulnerabilidad de ataque de denegación de servicio (DoS) con ejemplos concretos:

1. Recorrer grandes estructuras de datos que pueden ser modificadas externamente

A continuación se muestra un contrato simple para "dividendos" a 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");

para cur_account en self.registered.iter() {
    let balance = self.accounts.get(\u0026cur_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
    );
}

}

El tamaño de los datos de estado del contrato self.registered no tiene restricciones y puede ser manipulado por usuarios malintencionados. Cuando hay demasiados usuarios registrados, la ejecución de distribute_token puede exceder el límite de Gas, lo que provoca el fallo de la transacción.

Se sugiere modificar el modo de retiro: no distribuir dividendos activamente a todos los usuarios, sino llevar un registro y establecer una función de retiro para que los usuarios retiren sus recompensas por sí mismos.

2. La dependencia del estado entre contratos causa bloqueo

Considera un escenario de contratos de licitación:

ó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::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!) "current_leader: {} highest_bid: {}",} self.current_leader, self.highest_bid ); PromiseOrValue::Value(0) }

#( pub fn account_resolve)&mut self, sender_id: AccountId, amount: u128[private] { match env::promise_result(0) { PromiseResult::NotReady => unreachable!(), PromiseResult::Successful(_) => { ext_ft_token::ft_transfer( self.current_leader.clone)(, self.highest_bid, &FTTOKEN, 0, GAS_FOR_SINGLE_CALL * 2, (; self.current_leader = sender_id; self.highest_bid = amount; } PromiseResult::Failed => { ext_ft_token::ft_transfer) sender_id.clone)(, cantidad, &FTTOKEN, 0, GAS_FOR_SINGLE_CALL * 2, (; log!)"Regresar Ahora"); } }; }

Este contrato requiere que se devuelvan los tokens del anterior máximo postor para actualizar la oferta más alta. Si el anterior cancela su cuenta en un contrato externo, el sistema no podrá actualizar al máximo postor.

Se sugiere agregar un mecanismo de manejo de errores, como depositar los tokens no reembolsables en la cuenta lost_found del contrato, permitiendo posteriormente a los usuarios retirarlos.

3. Pérdida de la clave privada del propietario

Algunas funciones del contrato están configuradas para ser ejecutadas solo por el owner, utilizadas para cambiar variables críticas del sistema. Cuando el owner no puede desempeñar su función (, como en el caso de pérdida de la clave privada ), esto puede llevar a la congelación de fondos o la suspensión de transacciones.

Se sugiere adoptar un mecanismo de multi-firma en lugar de un control de permisos de un solo propietario, para lograr una gobernanza descentralizada.

En resumen, durante el desarrollo de contratos, se deben considerar plenamente los diversos riesgos potenciales de ataque de denegación de servicio (DoS), tomar las medidas de prevención adecuadas y garantizar el funcionamiento estable a largo plazo del contrato.

<accountid,balance><accountid,>

Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
  • Recompensa
  • 7
  • Compartir
Comentar
0/400
DeFiChefvip
· hace4h
La minería ya no tiene tanto auge, todos los días hay ataques DoS que causan destrucción.
Ver originalesResponder0
PrivacyMaximalistvip
· hace19h
Llave privada perdida y g. ¿Quién entiende?
Ver originalesResponder0
GmGnSleepervip
· hace19h
Es de nuevo culpa de las tarifas de Gas.
Ver originalesResponder0
NFTHoardervip
· hace19h
¿Otra vez se le ha perdido la llave privada a un hermano?
Ver originalesResponder0
NFTArchaeologisvip
· hace19h
Las vulnerabilidades de los contratos inteligentes de la era temprana de la Guerra del Gas son, sin duda, un valioso material arqueológico digital para conservar.
Ver originalesResponder0
MemeCuratorvip
· hace19h
¿Otra persona ha sido hackeada en su contrato? Las fallas en el contrato eran tan obvias que deberían haberse evitado.
Ver originalesResponder0
CompoundPersonalityvip
· hace19h
Los jugadores de ape que se tumban en la cadena probablemente están jugando con contratos inteligentes y trabajando en seguridad.
Ver originalesResponder0
Opere con criptomonedas en cualquier momento y lugar
qrCode
Escanee para descargar la aplicación Gate
Comunidad
Español
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)