Diário de desenvolvimento de contratos inteligentes em Rust: prevenção de ataque de negação de serviço

ataque de negação de serviço ( DoS ) pode causar que contratos inteligentes não funcionem corretamente por um período de tempo ou até permanentemente. As causas comuns incluem:

1. O problema da complexidade computacional na lógica do contrato, que leva ao consumo de Gas além do limite.

2. Ao chamar contratos cruzados, a dependência inadequada do estado de execução de contratos externos causa o bloqueio deste contrato.

3. A perda da chave privada do proprietário do contrato impede a chamada de funções privilegiadas, e o estado importante do sistema não pode ser atualizado.

Abaixo, analisaremos as vulnerabilidades de ataque de negação de serviço (DoS) e suas soluções através de alguns exemplos concretos.

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

Segue um contrato de "dividendos" simples, que apresenta risco de ataque de negação de serviço:

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

impl Contrato { pub fn register_account(&mut self) { if 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!("Tente distribuir para a conta {}", &cur_account);
        
        ext_ft_token::ft_transfer(
            cur_account.clone(),
            montante,
            &FTTOKEN,
            0,
            GAS_FOR_SINGLE_CALL
        );
    }
}

}

O problema é que o tamanho do array registered não tem limite, podendo ser manipulado por usuários maliciosos para se tornar excessivamente grande, levando ao consumo de Gas do função distribute_token a ultrapassar o limite.

Sugestão de solução:

1. Limitar o tamanho do array registered.

2. Adotar o modo "retirada", permitindo que os usuários retirem as recompensas por conta própria, em vez de serem distribuídas ativamente pelo contrato.

2. A dependência do estado entre contratos causa o bloqueio dos contratos

Segue um exemplo de contrato de "leilão":

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

impl Contrato { 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!)
        "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] {
    corresponder 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)(,
                quantidade,
                &FTTOKEN,
                0,
                GAS_FOR_SINGLE_CALL * 2,
            (;
            log!)"Return Back Now");
        }
    };
}

}

O problema é que a atualização do estado do contrato depende da chamada de contratos externos. Se a conta do anterior maior licitante tiver sido cancelada, os licitantes subsequentes não conseguirão atualizar o estado.

Sugestão de solução:

Considerar a possibilidade de falha em chamadas externas e implementar um mecanismo de tratamento de erros razoável. Por exemplo, armazenar temporariamente os tokens não reembolsáveis no contrato, permitindo posteriormente que os usuários os retirem ativamente.

3. Chave privada do proprietário perdida

Muitos contratos possuem funções privilegiadas que só podem ser executadas pelo proprietário. Se a chave privada do proprietário for perdida, essas funções não poderão ser chamadas, o que pode levar o contrato a não funcionar corretamente.

Sugestão de solução:

1. Definir vários proprietários de contratos para gerirem em conjunto.

2. Adotar um mecanismo de múltiplas assinaturas para substituir o controle de um único proprietário.

3. Implementar um mecanismo de governança de contratos descentralizado.

Através das medidas acima, é possível reduzir efetivamente o risco de ataque de negação de serviço em contratos inteligentes, aumentando a segurança e a fiabilidade do contrato.

</accountid,balance></accountid,>