Esse artigo foi escrito por: Zuhaib Mohammed e traduzido por Dimitris Calixto, artigo original disponível aqui
O espaço web3 é bastante novo e em evolução, e a maioria dos usuários são muito negligentes. Não investigam o projeto e apenas mergulham com o seu capital, na esperança de um retorno de 10x-100x.
Neste exemplo, tentaremos compreender a importância de auditar o código antes de interagir com o seu contrato. Todos sabemos que o código do contrato pode ser verificado através do portal etherscan.io.
Os invasores são inteligentes
Os criadores de um dApp publicam o seu código e endereço contratual no etherscan.io para que todos o vejam e auditem. Isto cria algum tipo de confiança para o projeto mas, existe uma forma de usar o desenvolvedor para esconder o código malicioso.
No exemplo dado abaixo, há dois contratos chamados Foo e Bar. Qualquer pessoa que olhe para o código pode facilmente dizer que o Foo recebe a entrada do endereço de contrato de Bar e depois chama a função de registro através da função callBar.
Mas, o invasor malicioso escreve uma função log separada no contrato Mal e passa o endereço do contrato destacado do contrato Mal em vez de Bar durante a implementação efetiva. Assim, uma vez que o dApp esteja em funcionamento, qualquer utilizador que interaja com o contrato Foo acaba por chamar a função log do contrato Mal, e o código malicioso é executado, o que geralmente acaba por roubar os fundos do usuário.
A Cadeia de Eventos
- Eve implementa Mal
- Eve implementa Foo com o endereço de Mal
- Alice chama a função Foo.callBar() depois de ler o código
- Alice esperava que Bar.log() fosse executado, mas Mal.log() foi executado.
A solução
Este tipo de ataque pode enganar muitos dos auditores que andam por aí. Portanto, uma boa solução é rever o código para qualquer endereço externo não verificado chamado através do construtor.
Uma menção ao SmartContractProgrammer para a maravilhosa série sobre hacking Solidity.
Espero que você tenha gostado de ler.
Ciao!
Top comments (0)