Análise de ataque DoS em contratos inteligentes: interpretação de casos e estratégias de defesa

Ataque de negação de serviço em contratos inteligentes Rust

ataque de negação de serviço(DoS) pode fazer com que contratos inteligentes não funcionem corretamente por um período de tempo ou até permanentemente. As principais razões incluem:

  1. A lógica do contrato tem uma falha de alta complexidade de cálculo, resultando em consumo de Gas que excede o limite.

  2. Durante a chamada entre contratos, a execução do contrato depende de contratos externos não confiáveis, causando bloqueio.

  3. O proprietário do contrato perdeu a chave privada, não conseguindo executar funções privilegiadas para atualizar estados importantes.

Abaixo, analisaremos a vulnerabilidade de ataque de negação de serviço (DoS) através de exemplos específicos.

1. Percorrer grandes estruturas de dados controláveis externamente

Segue um contrato simples para dar "dividendos" aos usuários:

ferrugem #[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) { se self.accounts.insert(\u0026env::predecessor_account_id(), \u00260).is_some() { env::panic("A conta já está registada".to_string().as_bytes()); } else { self.registered.push(env::predecessor_account_id()); }
log!("Conta registrada {}", env::predecessor_account_id()); }

pub fn distribute_token(&mut self, amount: u128) { assert_eq!(env::predecessor_account_id(), DISTRIBUIDOR, "ERR_NOT_ALLOWED"); for cur_account in 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!("Tente distribuir para a conta {}", &cur_account); ext_ft_token::ft_transfer( cur_account.clone(), quantia, &FTTOKEN, 0, GAS_FOR_SINGLE_CALL ); } }

Aqui, o tamanho de self.registered não tem limites, podendo ser manipulado por usuários maliciosos para se tornar excessivo, resultando em custos de Gas que excedem o limite durante a execução de distribute_token.

Solução: não é recomendado percorrer grandes estruturas de dados controladas externamente. Pode-se adotar o modo de retirada, permitindo que os usuários recuperem "dividendos" por conta própria.

2. Dependência de estado entre contratos causa bloqueio

Considere um contrato de "licitação":

ferrugem #[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); se 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, quantia, &env::current_account_id((, 0, GAS_FOR_SINGLE_CALL * 3, (); } log!) "líder_atual: {} maior_lance: {}", self.current_leader, self.highest_bid ); PromiseOrValue::Value(0) }

Aqui, a devolução dos tokens do anterior maior licitante é uma condição prévia para a atualização do estado. Se a conta desse usuário tiver sido cancelada, isso levará a um bloqueio de todo o processo de licitação.

Solução: considerar que chamadas externas podem falhar e aumentar o tratamento de erros. Pode-se armazenar temporariamente os tokens que não podem ser devolvidos, permitindo que os usuários os retirem posteriormente.

3. Chave privada do proprietário perdida

Algumas funções-chave são definidas para serem executadas apenas pelo proprietário. Se o proprietário não puder cumprir suas funções, (, como a perda da chave privada ), resultará na incapacidade do contrato de funcionar corretamente.

Solução: definir vários proprietários para governança conjunta ou utilizar solicitações de múltiplas assinaturas em vez de controle de um único proprietário, para alcançar a governança descentralizada.

</accountid,balance></accountid,>

Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
  • Recompensa
  • 7
  • Partilhar
Comentar
0/400
gaslight_gasfeezvip
· 07-19 19:58
As formigas das taxas de Gas já se uniram.
Ver originalResponder0
ImpermanentTherapistvip
· 07-19 19:57
Está a fazer manobras com contratos externos novamente.
Ver originalResponder0
WealthCoffeevip
· 07-19 19:53
É outra vez a questão das taxas de Gas, que chatice!
Ver originalResponder0
LiquidationTherapistvip
· 07-19 19:50
Contrato bloqueado, é assim tão simples.
Ver originalResponder0
SquidTeachervip
· 07-19 19:44
Você cometeu um erro tão básico como perder a chave privada?
Ver originalResponder0
BlockTalkvip
· 07-19 19:42
Chave privada perdida é realmente assustador
Ver originalResponder0
CryptoAdventurervip
· 07-19 19:32
Outra vez os contratos inteligentes foram destruídos, o endereço da carteira está em chamas, irmão.
Ver originalResponder0
Negocie cripto em qualquer lugar e a qualquer hora
qrCode
Digitalizar para transferir a aplicação Gate
Novidades
Português (Portugal)
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)