Análise profunda do ataque de negação de serviço em contratos inteligentes

ataque de negação de serviço(DoS)pode levar a contratos inteligentes a ficarem temporariamente ou permanentemente fora de uso. As principais razões incluem:

1. A lógica do contrato tem falhas. Por exemplo, algumas funções públicas não consideram a complexidade computacional, o que pode exceder o limite de Gas e causar a falha da transação.

2. Nas chamadas entre contratos, a execução do contrato depende do estado do contrato externo. A execução do contrato externo pode ser pouco confiável e pode bloquear a execução deste contrato, como quando os fundos do usuário ficam bloqueados e não podem ser depositados ou retirados.

3. Fatores humanos, como a perda da chave privada pelo proprietário do contrato, levam à impossibilidade de chamar certas funções privilegiadas e à atualização de estados importantes do sistema.

Abaixo, analisamos a vulnerabilidade de ataque de negação de serviço (DoS) com exemplos específicos:

1. Percorrer grandes estruturas de dados que podem ser alteradas externamente

Aqui está um contrato simples para "dividendos" para os usuários:

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

pub fn register_account(&mut self) { se self.accounts.insert(&env::predecessor_account_id(), &0).is_some() { env::panic("A conta já está registrada".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(), DISTRIBUTOR, "ERR_NOT_ALLOWED");

para cur_account em self.registered.iter() {
    let balance = self.accounts.get(\u0026cur_account).expect("ERR_GET");
    self.accounts.insert(&cur_account, &balance.checked_add(amount).expect("ERR_ADD"));
    log!("Tentar distribuir para a conta {}", &cur_account);
    ext_ft_token::ft_transfer(
        cur_account.clone(),
        quantidade,
        &FTTOKEN,
        0,
        GAS_FOR_SINGLE_CALL
    );
}

}

Os dados de estado do contrato self.registered não têm limite de tamanho e podem ser manipulados por usuários mal-intencionados. Quando o número de usuários registrados é excessivo, a execução do distribute_token pode ultrapassar o limite de Gas, resultando em falha na transação.

Sugere-se a transformação do modo de retirada: não distribuir ativamente dividendos a todos os usuários, mas sim manter um registro e definir uma função de retirada que permita aos usuários retirarem suas recompensas.

2. A dependência de estado entre contratos causa bloqueio

Considere um cenário de contrato de licitação:

ferrugem #[near_bindgen] #[derive(BorshDeserialize, BorshSerialize)] pub struct Contrato { pub registrado: Vec, pub bid_price: UnorderedMap<accountid,balance>, pub current_leader: AccountId, pub highest_bid: u128, pub refund: 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, montante, &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) }

#( 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)(, montante, &FTTOKEN, 0, GAS_FOR_SINGLE_CALL * 2, (; log!)"Return Back Now"); } }; }

Este contrato exige que os tokens do licitante anterior sejam devolvidos para que a maior oferta possa ser atualizada. Se o anterior cancelar a conta em um contrato externo, isso fará com que o sistema não consiga atualizar o licitante mais alto.

Sugere-se a adição de um mecanismo de tratamento de erros, como armazenar os tokens não retornáveis na conta lost_found do contrato, permitindo posteriormente que os usuários os retirem.

3. Perda da chave privada do proprietário

Algumas funções de contratos são definidas para serem executadas apenas pelo owner, usadas para alterar variáveis críticas do sistema. Quando o owner não consegue cumprir suas funções (, como na perda da chave privada ), isso pode resultar no bloqueio de fundos ou na interrupção de transações.

Sugere-se a adoção de um mecanismo de múltiplas assinaturas em vez de um único controle de permissões do proprietário, para alcançar a governança descentralizada.

Em suma, no desenvolvimento de contratos, deve-se considerar plenamente os vários riscos potenciais de ataque de negação de serviço (DoS), adotando as medidas de prevenção adequadas para garantir a operação estável e a longo prazo do contrato.

</accountid,balance></accountid,>