Ataque de reentrância

O que é um ataque de reentrância no mercado cripto?

Um ataque de reentrância é uma exploração de contrato inteligente na qual um contrato externo chama de volta um contrato vulnerável antes que a primeira chamada de função seja concluída.

No mercado cripto, esse ataque geralmente tem como alvo contratos inteligentes que mantêm fundos, registram saldos, processam saques, calculam recompensas, gerenciam cotas de vaults ou interagem com outros contratos.

O problema central é que o contrato vulnerável transfere o controle para outro contrato antes de terminar de atualizar seu próprio estado interno.

Se o invasor conseguir entrar novamente no contrato enquanto esse estado ainda não foi atualizado, poderá repetir uma ação que deveria ser permitida apenas uma vez.

Um exemplo comum é uma função de saque que envia cripto ao usuário antes de reduzir o saldo registrado desse usuário.

Se o destinatário for um contrato malicioso, ele poderá usar sua lógica de fallback ou callback para chamar novamente a função de saque antes da atualização do saldo.

Isso pode permitir que o invasor saque mais do que tem direito a receber.

A página da OWASP sobre reentrância no Smart Contract Top 10 de 2026 define reentrância como uma situação em que um contrato faz uma chamada externa e o contrato chamado retorna ao contrato original antes que o estado seja totalmente atualizado.

A reentrância é uma das vulnerabilidades mais conhecidas de contratos inteligentes porque ataca diretamente o modelo de confiança da contabilidade on-chain.

É especialmente perigosa em finanças descentralizadas porque contratos inteligentes costumam gerenciar grandes pools de liquidez e dependem de outros contratos para swaps, garantias, recompensas ou dados de preço.

Como funciona um ataque de reentrância

Um ataque de reentrância começa quando um contrato inteligente vulnerável faz uma chamada externa para outro contrato ou endereço.

Essa chamada externa pode enviar criptomoeda nativa, transferir tokens, chamar um hook, solicitar um callback, executar uma estratégia ou interagir com outro protocolo.

Ao fazer essa chamada, o contrato vulnerável dá temporariamente ao contrato destinatário a oportunidade de executar seu próprio código.

Se o contrato destinatário estiver sob o controle de um invasor, ele poderá aproveitar esse momento para chamar novamente o contrato vulnerável.

O contrato vulnerável ainda pode ter valores antigos de estado porque não atualizou saldos, dívidas, cotas, índices de recompensa ou indicadores de bloqueio.

O invasor pode explorar esses valores antigos para repetir um saque, reivindicar recompensas duas vezes, tomar empréstimos acima do permitido ou manipular um cálculo.

O ataque continua até que o contrato vulnerável fique sem fundos, a transação fique sem gas ou um mecanismo de proteção interrompa as chamadas repetidas.

A documentação do Solidity sobre chamadas externas alerta que, ao interagir com outro contrato, o controle é transferido para ele e que esse contrato pode chamar de volta o contrato original antes de a primeira chamada retornar.

Esse alerta é a base das defesas contra reentrância.

Qualquer chamada externa deve ser tratada como um possível ponto em que as premissas do contrato podem ser quebradas.

Exemplo simples de reentrância

Imagine um contrato de empréstimo que registra o saldo de depósito de cada usuário.

Um usuário deposita 10 ETH no contrato.

O contrato registra que o usuário tem um saldo de 10 ETH.

Mais tarde, o usuário chama uma função de saque para receber os 10 ETH de volta.

Um contrato seguro reduziria o saldo do usuário a zero antes de enviar os ETH.

Um contrato vulnerável envia os ETH primeiro e atualiza o saldo depois.

Se o usuário for, na verdade, um contrato malicioso, sua função receive poderá ser executada quando os ETH forem enviados.

Essa função receive pode chamar imediatamente a função de saque outra vez, enquanto o contrato vulnerável ainda acredita que o usuário tem 10 ETH.

O mesmo saque pode se repetir várias vezes dentro de uma única transação.

Por isso, a ordem da lógica em contratos inteligentes é tão importante.

Em um software tradicional, um pequeno erro de ordenação pode causar um erro contábil comum.

Em um contrato inteligente que mantém criptoativos, o mesmo erro de ordenação pode abrir um caminho direto para o roubo de ativos.

Por que os ataques de reentrância são perigosos

Os ataques de reentrância são perigosos porque contratos inteligentes frequentemente controlam ativos que podem ser difíceis de recuperar após uma exploração.

As blockchains públicas são projetadas para executar transações válidas e preservar seu histórico.

Se uma transação maliciosa seguir as regras da blockchain, mas explorar um erro no contrato, normalmente será difícil reverter os danos.

O guia de segurança de contratos inteligentes da Ethereum.org explica que geralmente é difícil alterar o código de contratos inteligentes já implantados e que é difícil recuperar ativos roubados devido à imutabilidade da blockchain.

Por isso, prevenir é muito mais importante do que tentar corrigir o problema depois.

Uma falha de reentrância pode drenar pools de liquidez, vaults, bridges, sistemas de staking, marketplaces de NFT, contratos de recompensa e protocolos de empréstimo.

Também pode prejudicar a confiança dos usuários, mesmo que o valor roubado seja recuperado posteriormente.

No mercado cripto, o risco de contratos inteligentes não é apenas um problema para desenvolvedores.

Pode se tornar, ao mesmo tempo, um problema para os usuários, para a liquidez, para a governança e para a reputação.

Reentrância clássica

A reentrância clássica ocorre quando um invasor entra novamente na mesma função que fez a chamada externa.

O exemplo mais comum é uma função de saque vulnerável.

A função verifica se o usuário tem saldo, envia fundos para ele e só depois atualiza o saldo.

O contrato do invasor recebe os fundos e chama novamente a mesma função de saque antes que o saldo seja reduzido.

Isso cria um ciclo em que o mesmo saldo registrado pode ser usado várias vezes.

A reentrância clássica é fácil de entender, mas continua sendo perigosa porque muitos desenvolvedores ainda fazem chamadas externas cedo demais na lógica.

Também é perigosa porque os contratos modernos costumam ter uma contabilidade mais complexa do que um simples mapeamento de depósitos e saques.

Uma função vulnerável pode envolver cotas, posições de dívida, multiplicadores de recompensa, ativos de vaults, tokens de liquidez ou contabilização de taxas.

Mesmo que o padrão pareça diferente do exemplo clássico, o mesmo problema central ainda pode existir.

Reentrância entre funções

A reentrância entre funções ocorre quando o invasor entra novamente em uma função diferente do mesmo contrato.

É mais sutil do que a reentrância clássica porque a função atacada pode parecer segura quando analisada isoladamente.

Por exemplo, uma função pode iniciar um saque e fazer uma chamada externa.

Durante essa chamada externa, o invasor pode chamar outra função que dependa do mesmo saldo, cota ou estado de permissão.

Se a primeira função ainda não tiver terminado de atualizar o estado, a segunda poderá ler informações desatualizadas.

Isso pode permitir que o invasor reivindique recompensas, transfira cotas, tome ativos emprestados ou altere uma posição antes da conclusão da primeira ação.

A reentrância entre funções mostra por que os desenvolvedores precisam considerar as invariantes de todo o contrato, em vez de proteger apenas uma função de saque óbvia.

Uma invariante de contrato é uma regra que deve continuar verdadeira antes e depois de toda operação válida.

Se chamadas externas puderem violar temporariamente uma invariante, outras funções poderão se tornar caminhos de ataque.

Reentrância entre contratos

A reentrância entre contratos ocorre quando o caminho de callback passa por vários contratos.

Isso pode acontecer em sistemas DeFi nos quais vaults, estratégias, routers, contratos de tokens, leitores de oráculos, módulos de staking e distribuidores de recompensas interagem entre si.

Um vault pode chamar uma estratégia.

A estratégia pode chamar um token ou outro protocolo.

O contrato chamado pode acionar um callback que retorna ao vault ou a um contrato relacionado do qual o vault depende.

O estado vulnerável pode não estar no mesmo contrato que fez a primeira chamada externa.

As considerações de segurança do Solidity observam que a reentrância não ocorre apenas em transferências de Ether e que também é necessário considerar situações envolvendo vários contratos.

Isso é importante porque os aplicativos cripto modernos são altamente composáveis.

A composabilidade permite que protocolos se conectem e se baseiem uns nos outros, mas também cria mais caminhos para callbacks inesperados.

Reentrância somente de leitura

A reentrância somente de leitura ocorre quando uma função view ou de leitura retorna informações enganosas durante uma transição de estado ainda não concluída.

À primeira vista, isso pode parecer inofensivo porque funções view não alteram diretamente o estado.

No entanto, outros contratos podem usar funções view para calcular preços, cotas, valores de garantia, taxas de câmbio ou valores de recompensa.

Se ocorrer um callback enquanto um contrato está em um estado intermediário, uma função view poderá retornar um valor temporário que não deve ser considerado confiável.

Um invasor pode usar esse valor temporário em outro contrato que dependa dele.

Isso pode causar manipulação semelhante à de um oráculo ou erros contábeis, sem drenar diretamente o primeiro contrato por meio de uma função de saque normal.

A reentrância somente de leitura lembra que a segurança não depende apenas de uma função gravar ou não em armazenamento.

Também importa saber se outros contratos podem observar um estado incompleto e tomar decisões financeiras com base nele.

Reentrância baseada em hooks

A reentrância baseada em hooks ocorre quando padrões de tokens ou interfaces de protocolo chamam intencionalmente a lógica de um destinatário durante uma transferência ou operação.

Alguns padrões de tokens e NFTs incluem hooks de recebimento para que os contratos possam reagir ao receber ativos.

Sistemas de flash loan também usam callbacks para que um tomador possa utilizar a liquidez emprestada e pagar o empréstimo na mesma transação.

Esses hooks são úteis, mas também criam oportunidades para callbacks.

Se um contrato presumir que uma transferência de tokens é uma ação simples, sem execução de código externo, essa premissa pode estar errada.

Dependendo do padrão e da implementação do token, uma transferência pode acionar a lógica de recebimento, hooks de operador ou outros comportamentos de contratos.

Os desenvolvedores devem analisar toda interação externa com tokens como um possível ponto de reentrância.

Isso é especialmente importante para contratos que oferecem suporte a muitos tokens, ativos de vaults ou integrações externas.

Alvos comuns de ataques de reentrância

As funções de saque são os alvos mais comuns de reentrância porque frequentemente enviam fundos para fora de um contrato.

As funções de depósito e saque de vaults também são alvos comuns porque atualizam saldos de cotas e contabilização de ativos.

Protocolos de empréstimo podem ser alvos porque acompanham garantias, dívidas, juros, limites de liquidação e saldos emprestados.

Contratos de staking podem ser alvos porque calculam recompensas ao longo do tempo e podem transferir tokens de recompensa durante reivindicações.

Marketplaces de NFT podem ser alvos porque compras e pagamentos podem acionar hooks de recebimento de tokens ou lógicas externas de royalties.

Contratos de bridge podem ser alvos porque gerenciam mensagens entre blockchains, bloqueio de ativos e lógica de liberação.

Contratos de execução de governança podem ser alvos porque chamam contratos externos durante a execução de propostas.

Provedores e destinatários de flash loans podem ser alvos porque seu funcionamento depende de callbacks.

Qualquer contrato inteligente que transfira valor ou chame código não confiável antes de concluir a contabilidade interna deve ser considerado um possível alvo de reentrância.

Padrão Checks-Effects-Interactions

O padrão Checks-Effects-Interactions é uma das defesas mais importantes contra ataques de reentrância.

Checks significa que o contrato primeiro verifica se o usuário tem permissão para realizar a ação.

Effects significa que o contrato atualiza seu estado interno antes de fazer qualquer chamada externa.

Interactions significa que o contrato só faz chamadas externas depois de concluir as verificações e as atualizações de estado.

Em uma função de saque, o contrato deve verificar se o usuário tem saldo, reduzir esse saldo e só então enviar os fundos.

Assim, se o destinatário tentar entrar novamente, o contrato já refletirá o saldo atualizado.

A documentação do Solidity sobre Checks-Effects-Interactions descreve esse padrão como uma forma comum de prevenir ataques de reentrância.

Esse padrão é simples, mas é indispensável para contratos que interagem com código externo não confiável.

Os desenvolvedores devem adotá-lo como prática padrão sempre que uma função alterar o estado e fizer chamadas para fora do contrato.

Proteções contra reentrância

Uma proteção contra reentrância é um bloqueio que impede que uma função protegida seja chamada novamente antes que a primeira chamada termine.

Em contratos Solidity, isso costuma ser implementado com uma variável de status que marca uma função como em execução.

Se uma chamada reentrante tentar acessar novamente o mesmo caminho protegido, a proteção a rejeita.

A documentação do ReentrancyGuard do OpenZeppelin Contracts 5.x descreve o ReentrancyGuard como um módulo que fornece o modificador nonReentrant para prevenir chamadas reentrantes aninhadas.

As proteções contra reentrância são úteis porque acrescentam uma camada de segurança clara a funções de alto risco.

No entanto, uma proteção não substitui uma contabilidade correta.

Os desenvolvedores ainda devem usar Checks-Effects-Interactions e revisar todas as chamadas externas.

A OpenZeppelin também observa que, como há uma única proteção nonReentrant, funções marcadas como nonReentrant não podem chamar umas às outras diretamente.

Uma solução comum é tornar privada a lógica interna e expor pontos de entrada externos separados, protegidos por nonReentrant.

Armazenamento transitório e bloqueios contra reentrância

O armazenamento transitório é um recurso mais recente da EVM que pode ser usado para valores temporários, válidos apenas durante uma transação.

Ele pode ser útil para bloqueios contra reentrância porque nem sempre é necessário manter o bloqueio em armazenamento permanente após o fim da chamada.

A documentação do ReentrancyGuardTransient da OpenZeppelin descreve uma variante do ReentrancyGuard baseada em armazenamento transitório para redes em que o EIP-1153 está disponível.

A documentação do Solidity sobre armazenamento transitório afirma que é seguro usar armazenamento transitório para bloqueios contra reentrância que são removidos no fim do quadro de chamada.

Isso não significa que todo contrato deva usar armazenamento transitório automaticamente.

Os desenvolvedores precisam confirmar que a blockchain de destino oferece suporte ao recurso exigido e que o bloqueio é removido corretamente.

Um bloqueio mal gerenciado pode prejudicar a composabilidade ou dificultar o uso do contrato em transações complexas.

A melhor opção depende da blockchain de destino, da versão do compilador, da versão da biblioteca, do padrão de atualização e dos requisitos de auditoria.

Por que transfer e send não são defesas completas

Orientações antigas de Solidity frequentemente tratavam transferências com gas limitado como uma forma prática de mitigar a reentrância.

As orientações atuais são mais cautelosas porque os custos de gas e o comportamento da EVM podem mudar com o tempo.

A documentação do Solidity sobre membros de endereços alerta que send e transfer foram descontinuados e recomenda outros meios de proteção contra reentrância.

Isso importa porque confiar apenas em um limite de gas pode criar uma falsa sensação de segurança.

Um contrato deve ser seguro porque sua lógica de estado está correta, e não porque presume que o destinatário não terá gas suficiente para fazer algo perigoso.

A abordagem mais segura é atualizar o estado antes das chamadas externas, usar proteções contra reentrância quando apropriado, verificar os valores de retorno e projetar cuidadosamente os fluxos de saque.

Os desenvolvedores também devem revisar códigos antigos que ainda dependem de transfer ou send como proteção principal contra reentrância.

As práticas de segurança cripto mudam à medida que evoluem as regras dos protocolos, os custos de gas e as técnicas comuns de ataque.

Pagamentos pull como defesa

Um padrão de pagamento pull permite que os destinatários saquem os fundos por conta própria, em vez de um contrato enviar os fundos durante outra operação.

Isso reduz o risco porque o contrato pode registrar um pagamento devido e permitir que o destinatário o reivindique em uma etapa separada.

Por exemplo, um marketplace pode registrar os valores devidos ao vendedor em vez de enviar fundos a ele dentro da transação de compra do comprador.

Mais tarde, o vendedor chama uma função de saque para reivindicar os fundos.

Esse padrão pode limitar os danos causados por um destinatário malicioso que rejeite pagamentos ou tente entrar novamente durante um pagamento.

A documentação dos utilitários de segurança da OpenZeppelin descreve PullPayment como um padrão que pode ajudar a evitar ataques de reentrância.

Os pagamentos pull não são perfeitos para todos os projetos porque podem exigir etapas adicionais dos usuários.

No entanto, podem ser muito úteis quando muitos usuários ou contratos precisam receber pagamentos do mesmo sistema.

Controles de pausa de emergência

Um controle de pausa de emergência permite que contas autorizadas ou sistemas de governança suspendam funções sensíveis durante um incidente.

Isso pode ajudar a limitar os danos se um comportamento suspeito ou uma possível exploração por reentrância for detectado.

Uma função de pausa pode interromper saques, depósitos, reivindicações de recompensa, novos empréstimos ou outras ações arriscadas enquanto a equipe investiga.

A OpenZeppelin apresenta Pausable como um mecanismo comum de resposta a emergências que pode suspender funcionalidades enquanto se aguarda uma correção.

Um sistema de pausa deve ser projetado com cuidado porque envolve concessões entre governança e centralização.

Se a autoridade de pausa for poderosa demais, os usuários podem temer censura ou uso indevido.

Se for fraca ou lenta demais, talvez não ajude durante uma exploração ativa.

Para protocolos cripto de alto valor, o planejamento de resposta a emergências deve fazer parte do projeto de segurança desde o início.

Como os desenvolvedores podem detectar riscos de reentrância

Os desenvolvedores podem detectar riscos de reentrância revisando todas as chamadas externas do contrato.

Chamadas externas incluem transferências de moedas nativas, transferências de tokens, chamadas de baixo nível, chamadas de interface, callbacks de flash loans, hooks de recebimento de NFTs e chamadas para módulos de protocolo.

Para cada chamada externa, os desenvolvedores devem perguntar se o estado interno já foi atualizado.

Também devem verificar se outra função pode ser chamada durante a chamada externa e observar um estado desatualizado.

Devem analisar se vários contratos compartilham premissas que poderiam ser quebradas por um callback.

Devem testar contratos receptores maliciosos que tentem chamar de volta todas as funções públicas e externas.

Devem usar em conjunto análise estática, fuzz testing, testes unitários, testes de invariantes e revisão manual.

A documentação do SMTChecker do Solidity inclui propriedades de reentrância entre os tipos de comportamento que podem ser analisados em chamadas externas para código desconhecido.

Nenhuma ferramenta isolada pode garantir que um contrato seja seguro.

A detecção de reentrância funciona melhor quando ferramentas automatizadas são combinadas com uma análise de segurança feita por profissionais experientes.

Como os usuários podem avaliar o risco de reentrância

A maioria dos usuários não consegue auditar completamente um contrato inteligente antes de usá-lo.

No entanto, ainda é possível reduzir os riscos observando sinais de boas práticas de segurança.

Um protocolo deve fornecer informações claras sobre auditorias, programas de bug bounty, controles de emergência, permissões de atualização e divulgações de risco.

Os usuários devem ter cuidado com contratos novos que mantêm grandes valores, mas foram pouco analisados publicamente.

Também devem ter cuidado quando um protocolo oferece rendimentos excepcionalmente altos sem explicar de onde vêm os retornos e quais são os riscos dos contratos inteligentes.

O risco de reentrância pode existir mesmo quando a interface do usuário parece refinada e profissional.

Uma boa interface não prova que a lógica do contrato subjacente é segura.

Os usuários devem evitar depositar em contratos não auditados ou experimentais mais do que podem se dar ao luxo de perder.

Também devem entender que auditorias reduzem os riscos, mas não os eliminam completamente.

Reentrância e composabilidade DeFi

A composabilidade DeFi significa que contratos inteligentes podem se conectar uns aos outros como blocos de construção financeiros.

Esse é um dos recursos mais poderosos do mercado cripto porque permite que carteiras, vaults, mercados de empréstimo, swaps, derivativos, sistemas de staking e ferramentas de governança interajam.

No entanto, a composabilidade também aumenta o risco de reentrância porque uma transação pode passar por muitos contratos.

Uma operação que parece segura em um contrato pode acionar comportamentos complexos em outro.

Um callback pode chegar a um terceiro contrato e alterar um valor do qual o primeiro depende.

Um preço, valor de cota ou saldo pode ser consultado durante um estado temporário que nunca deveria ter sido observado externamente.

Por isso, as análises modernas de reentrância devem incluir todo o caminho de interação.

Os desenvolvedores não devem analisar cada contrato como se ele existisse isoladamente.

Devem analisar como os contratos se comportam quando combinados com routers, tokens, vaults, flash loans e estratégias externas.

Reentrância e flash loans

Os flash loans podem tornar os ataques de reentrância mais poderosos porque permitem que invasores acessem uma grande liquidez temporária em uma única transação.

Um flash loan, por si só, não é um ataque de reentrância.

É uma ferramenta que pode ser usada para arbitragem legítima, refinanciamento, liquidação e operações eficientes em termos de capital.

No entanto, se um contrato vulnerável puder ser manipulado em uma única transação, um flash loan pode fornecer capital suficiente para tornar a exploração lucrativa.

Callbacks de flash loans também precisam ser projetados com cuidado porque sistemas baseados em callbacks transferem intencionalmente o controle para outro contrato.

Os desenvolvedores devem tratar cada callback como uma chamada externa não confiável, a menos que haja um motivo sólido para não fazê-lo.

Sempre que possível, devem atualizar o estado antes dos callbacks e verificar o pagamento final, os saldos e as invariantes após o retorno do callback.

As integrações de flash loans devem ser testadas com contratos de tomadores maliciosos, não apenas com exemplos de tomadores comuns.

Reentrância e contratos atualizáveis

Contratos atualizáveis exigem cuidados especiais no uso de proteções contra reentrância.

Um proxy atualizável separa o armazenamento voltado aos usuários da lógica de implementação.

Se uma proteção contra reentrância usar armazenamento, os desenvolvedores devem garantir que o layout de armazenamento esteja correto e seja compatível entre atualizações.

Alterar incorretamente o layout de armazenamento pode desativar a proteção ou corromper variáveis de estado importantes.

Os desenvolvedores devem usar bibliotecas compatíveis com contratos atualizáveis.

Também devem testar as atualizações com estados anteriores do contrato, e não apenas em novas implantações.

Um contrato pode ser seguro na versão um e se tornar vulnerável depois de uma atualização que altere a ordem das chamadas ou adicione uma nova integração externa.

As revisões de atualizações devem incluir uma análise de reentrância para cada nova chamada externa.

Sistemas de governança ou administração que executam atualizações também devem contar com atrasos, revisões e controles de emergência quando o protocolo mantiver valores significativos.

Boas práticas para prevenir ataques de reentrância

Atualize o estado interno antes de fazer chamadas externas.

Use o padrão Checks-Effects-Interactions em saques, reivindicações, transferências, swaps e alterações contábeis.

Aplique uma proteção contra reentrância aos pontos de entrada externos de alto risco.

Não presuma que as transferências de tokens são sempre simples, pois alguns padrões e implementações de tokens podem acionar hooks ou callbacks.

Não confie apenas nos limites de gas de transfer ou send como defesa contra reentrância.

Use padrões de pagamento pull quando pagamentos diretos criarem riscos desnecessários.

Analise a reentrância entre funções e entre contratos, não apenas a reentrância clássica na mesma função.

Teste com contratos receptores maliciosos que tentem entrar novamente durante cada chamada externa.

Use testes de invariantes para confirmar que saldos totais, cotas, dívidas e reservas continuam corretos em interações complexas.

Inclua pausas de emergência e planos de resposta a incidentes para sistemas de alto valor.

Solicite uma análise de segurança independente antes de implantar contratos que mantêm fundos de usuários.

Mantenha as dependências atualizadas e consulte as notas de migração das bibliotecas antes de mudar versões principais.

Erros comuns de desenvolvedores

Um erro comum é atualizar os saldos depois de enviar os fundos.

Outro erro comum é proteger apenas a função de saque e deixar funções relacionadas vulneráveis à reentrância entre funções.

Outro erro é presumir que uma transferência de tokens não pode executar código externo.

Outro erro é usar uma proteção contra reentrância em um contrato e ignorar chamadas a contratos relacionados que compartilham premissas contábeis.

Outro erro é confiar em premissas antigas sobre transfer e send, em vez de projetar corretamente a lógica de estado.

Outro erro é adicionar uma nova integração externa durante uma atualização sem verificar novamente todo o caminho de chamadas.

Outro erro é tratar funções view como inofensivas, mesmo quando outros contratos dependem de seus valores durante transações complexas.

Outro erro é esquecer que contratos maliciosos podem se comportar deliberadamente de maneira diferente de usuários comuns.

Os testes de segurança devem pressupor comportamentos hostis, e não apenas o uso normal da interface.

Perguntas frequentes

O que significa ataque de reentrância?

Um ataque de reentrância ocorre quando um contrato malicioso chama novamente um contrato inteligente vulnerável antes que a primeira chamada de função termine e antes que o estado seja atualizado com segurança.

Por que a reentrância é perigosa no mercado cripto?

A reentrância é perigosa porque pode permitir que invasores drenem fundos, reivindiquem recompensas várias vezes, manipulem a contabilidade ou quebrem as premissas do contrato em uma única transação.

A reentrância está relacionada apenas a transferências de ETH?

Não. A documentação do Solidity alerta que a reentrância não está relacionada apenas a transferências de Ether, pois qualquer chamada a um contrato externo pode criar um risco de callback.

Qual é a defesa mais conhecida contra reentrância?

O padrão Checks-Effects-Interactions é uma das defesas mais conhecidas porque atualiza o estado do contrato antes de fazer chamadas externas.

O que é ReentrancyGuard?

ReentrancyGuard é um utilitário para contratos inteligentes que fornece o modificador nonReentrant para impedir chamadas aninhadas em funções protegidas.

O ReentrancyGuard pode prevenir todas as falhas de reentrância?

Não. O ReentrancyGuard ajuda a proteger determinados pontos de entrada, mas os desenvolvedores ainda precisam de uma contabilidade correta, ordem segura de chamadas e análise entre contratos.

O que é reentrância entre funções?

A reentrância entre funções ocorre quando um invasor entra novamente em uma função diferente do mesmo contrato enquanto a primeira função ainda não foi concluída.

O que é reentrância somente de leitura?

A reentrância somente de leitura ocorre quando uma função view retorna um estado temporário enganoso durante uma operação não concluída e outro contrato depende desse valor.

Transferências de tokens podem causar reentrância?

Sim. Alguns padrões e implementações de tokens podem acionar hooks ou callbacks, por isso as transferências de tokens devem ser analisadas como possíveis chamadas externas.

Os usuários devem evitar todos os contratos inteligentes por causa da reentrância?

Não. Os usuários não precisam evitar todos os contratos inteligentes, mas devem preferir protocolos com auditorias robustas, documentação clara, monitoramento ativo e controles de risco responsáveis.

Conclusão

Um ataque de reentrância é uma exploração de contrato inteligente que se aproveita de um estado ainda não concluído durante uma chamada externa.

O invasor entra novamente no contrato vulnerável antes que a primeira chamada seja concluída e usa dados contábeis desatualizados para obter mais valor do que o permitido.

Embora o exemplo clássico envolva repetir um saque, a reentrância moderna também pode envolver chamadas entre funções, fluxos entre contratos, estado somente de leitura, hooks de tokens, callbacks de flash loans e composabilidade DeFi.

A principal lição é que toda chamada externa deve ser tratada como uma possível transferência de controle para código não confiável.

Os desenvolvedores podem reduzir o risco de reentrância seguindo o padrão Checks-Effects-Interactions, usando proteções contra reentrância, evitando padrões inseguros de pagamento, testando callbacks maliciosos e analisando todos os caminhos de interação entre contratos.

Os usuários podem reduzir sua exposição escolhendo protocolos que levam a segurança de contratos inteligentes a sério e evitando sistemas não auditados que mantêm valores significativos.

A reentrância continua sendo um conceito importante de segurança cripto porque transforma um pequeno erro na ordem da lógica em uma exploração financeira potencialmente grave.

Entender a reentrância ajuda os desenvolvedores a criar contratos mais seguros e ajuda os usuários a compreender por que auditorias de contratos inteligentes, padrões de segurança e controles de risco são importantes.