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:
A lógica do contrato tem uma falha de alta complexidade de cálculo, resultando em consumo de Gas que excede o limite.
Durante a chamada entre contratos, a execução do contrato depende de contratos externos não confiáveis, causando bloqueio.
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:
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
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.
8 gostos
Recompensa
8
7
Partilhar
Comentar
0/400
gaslight_gasfeez
· 07-19 19:58
As formigas das taxas de Gas já se uniram.
Ver originalResponder0
ImpermanentTherapist
· 07-19 19:57
Está a fazer manobras com contratos externos novamente.
Ver originalResponder0
WealthCoffee
· 07-19 19:53
É outra vez a questão das taxas de Gas, que chatice!
Ver originalResponder0
LiquidationTherapist
· 07-19 19:50
Contrato bloqueado, é assim tão simples.
Ver originalResponder0
SquidTeacher
· 07-19 19:44
Você cometeu um erro tão básico como perder a chave privada?
Ver originalResponder0
BlockTalk
· 07-19 19:42
Chave privada perdida é realmente assustador
Ver originalResponder0
CryptoAdventurer
· 07-19 19:32
Outra vez os contratos inteligentes foram destruídos, o endereço da carteira está em chamas, irmão.
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:
A lógica do contrato tem uma falha de alta complexidade de cálculo, resultando em consumo de Gas que excede o limite.
Durante a chamada entre contratos, a execução do contrato depende de contratos externos não confiáveis, causando bloqueio.
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.