---
title: "O que é um ataque de reentrância em Solidity?"
description: "O que é, como funciona e como proteger seus smart contracts"
---

# O que é um ataque de reentrância em Solidity?

**Um ataque de reentrância** em [Solidity](https://www.alchemy.com/overviews/solidity) retira fundos repetidamente de um smart contract e os transfere para um contrato não autorizado até que os fundos se esgotem. O ataque ocorre durante o ciclo de execução na blockchain, quando agentes mal-intencionados encontram um smart contract explorável. Ataques de reentrância já liquidaram milhões de dólares de [DAOs](https://www.alchemy.com/dapps/top/daos) e protocolos de blockchain.

O artigo a seguir explica a mecânica de um ataque de reentrância, dois tipos de ataques de reentrância e as medidas preventivas que **desenvolvedores Solidity** podem adotar para proteger um smart contract contra vulnerabilidades nas blockchains Ethereum e Solana.

## O que é um ataque de reentrância?

Ataques de reentrância ocorrem quando uma função de smart contract cede temporariamente o controle de fluxo da transação ao fazer uma chamada externa a um contrato, às vezes escrito por agentes desconhecidos ou possivelmente hostis. Isso permite que o segundo contrato faça uma chamada recursiva de volta à [**função de smart contract**](https://www.alchemy.com/overviews/solidity-functions) principal para drenar seus fundos.

O ciclo de execução de um smart contract nas blockchains Ethereum verifica o saldo, envia os fundos e, em seguida, atualiza o saldo. Enquanto o smart contract está nesse período intermediário, agentes mal-intencionados podem [fazer outra chamada](https://www.alchemy.com/overviews/solidity-call) para retirar fundos. O ciclo se repete até que todos os fundos sejam efetivamente drenados.

## Como funciona um ataque de reentrância?

**Um ataque de reentrância cria um processo recursivo que transfere fundos entre dois smart contracts: o contrato vulnerável e o contrato malicioso.** Eis as etapas de um ataque de reentrância:

1. O agente mal-intencionado faz uma chamada no contrato vulnerável, "X", para transferir fundos para o contrato malicioso, "Y".
1. O contrato X determina se o atacante tem os fundos necessários e, em seguida, transfere os fundos para o contrato Y.
1. Quando o contrato Y recebe os fundos, ele executa uma função de _callback_ que chama de volta o contrato X antes que o saldo seja atualizado.
1. Esse processo recursivo continua até que todos os fundos tenham sido esgotados e transferidos.

**O diagrama abaixo ilustra o cenário do ataque:**

<ImageBlock
  src="https://media.alchemy.com/1704184186-reentrancy-attack-scenario.png"
  alt="Diagrama de um ataque de reentrância: um contrato malicioso chama a si mesmo recursivamente antes que o saldo seja atualizado"
  width={752}
  height={481}
  caption="Cenário de ataque de reentrância | Fonte da imagem: CryptoMarketPool"
/>

## **Quais são os diferentes tipos de ataques de reentrância?**

**Existem dois tipos de ataques de reentrância: um ataque de função única e um ataque de reentrância entre funções.**

### **1. Ataques de reentrância única**

Um ataque de reentrância única ocorre quando a função vulnerável é a mesma função que o atacante está tentando chamar recursivamente. Ataques de reentrância única são mais simples e mais fáceis de prevenir do que ataques de reentrância entre funções.

### **2. Ataques entre funções**

Um ataque de reentrância entre funções só é viável quando uma função vulnerável compartilha estado com outra função que tem um efeito desejável para o atacante. Ataques entre funções são mais difíceis de detectar e mais difíceis de prevenir.

### **3. Ataque entre contratos**

Um ataque de reentrância entre contratos ocorre quando um estado de um contrato é chamado em outro antes de ser totalmente atualizado. Ataques de reentrância entre contratos geralmente ocorrem quando vários contratos compartilham manualmente a mesma variável e alguns atualizam essa variável compartilhada de forma insegura.

## **Exemplos de ataques de reentrância em Solidity**

Os seguintes ataques de reentrância de destaque ilustram ainda mais como agentes mal-intencionados exploraram vulnerabilidades em protocolos de blockchain: o hack da DAO, o Lendf.me e o [Cream Finance](https://www.alchemy.com/dapps/cream-finance).

### 1. Hack da DAO \(2016\)

A DAO da Ethereum foi hackeada em aproximadamente $60 milhões em Ether. A DAO da Ethereum foi projetada como um fundo de investimento em que os membros da rede podiam votar diretamente nas decisões de investimento.

A DAO arrecadou cerca de $150 milhões, mas especialistas e participantes da comunidade expressaram preocupações sobre a segurança do smart contract que armazenava os fundos. Os fundos ficaram travados em um smart contract vulnerável a um ataque de reentrância devido a um bug de chamada recursiva no código-fonte. Antes que a equipe de desenvolvedores corrigisse o problema, um hacker executou um ataque e drenou o contrato.

### **2. Protocolo Lendf.me \(2020\)**

Em abril de 2020, um agente mal-intencionado roubou $25 milhões usando um ataque de reentrância no protocolo Lendf.me, um protocolo de finanças descentralizadas para operações de empréstimo na rede Ethereum.

Os desenvolvedores do protocolo não perceberam que os tokens ERC-777 contêm uma função de callback que notifica os usuários quando dinheiro é enviado ou recebido. Hackers exploraram a vulnerabilidade instituindo um smart contract malicioso como destinatário e drenando 99,5% dos fundos do protocolo Lendf.me.

### **3. Hack da Cream Finance \(2021\)**

Em outubro de 2021, um agente mal-intencionado roubou mais de $130 milhões em tokens ERC-20 e tokens de liquidez \(LP\) da CREAM usando um ataque de reentrância no recurso de "flash loan" do protocolo. A causa raiz da exploração foi a integração equivocada da AMP no protocolo CREAM Finance.

## **Como prevenir um ataque de reentrância**

**Desenvolver uma estrutura de segurança de blockchain rigorosa é fundamental para prevenir e mitigar possíveis danos de um ataque de reentrância.** As seguintes boas práticas anti-reentrância ajudarão desenvolvedores e a comunidade web3 em geral a proteger seus fundos: checks, effects and interactions \(CEI\), reentrancy guards, pull payments e limites de gas.

### **Checks, effects and interactions \(CEI\)**

O processo CEI é um método rudimentar para prevenir reentrância. Checks se referem à veracidade da condição, effects se referem a modificações de estado resultantes da interação, e interactions se referem a transações entre funções ou contratos.

Riscos de segurança potenciais e brechas associadas a colocar os effects antes das interactions são uma consideração importante para os desenvolvedores.

### **Reentrancy guard ou mutex**

Um reentrancy guard ou mutex pode ser criado como uma função ou [function modifier](https://www.alchemy.com/overviews/solidity-modifier). Um bloqueio booleano é colocado em torno da chamada de função vulnerável à reentrância. Isso implica que o estado inicial de "locked" é false; no entanto, ele é definido como true imediatamente antes do início da execução da função vulnerável e, em seguida, é rapidamente redefinido para false após o término.

### **Pull payment**

Uma transação ponta a ponta mais segura é obtida usando a metodologia de pull payment. O processo de pull payment exige o uso de um escrow intermediário para enviar fundos e evita o contato direto com um contato potencialmente hostil.

Ao enviar fundos por meio de um escrow intermediário, os fundos do smart contract ficam protegidos contra um ataque de reentrância. O escrow pode estar sujeito à reentrância se gerenciar fundos de várias contas. O padrão CEI e o reentrancy guard devem ser implementados onde for adequado.

### **Limite de gas**

Limites de gas não são um método ideal para deter um atacante, já que os custos de gas dependem dos opcodes da Ethereum, que estão sujeitos a mudanças. Por outro lado, o código do smart contract é imutável.

É importante entender a diferença entre as funções [_send_, _transfer_ e _call_](https://www.alchemy.com/overviews/solidity-functions). _Send_ e _transfer_ são efetivamente iguais, mas _transfer_ reverterá se a transação falhar, enquanto _send_ não.

Diferentemente de _send_ e _transfer_, a função _call_ não tem limite de gas e encaminhará seu gas para executar transações multi-contrato. Infelizmente, isso também significa que ataques de reentrância são possíveis.

## **Saiba mais sobre ataques de reentrância com a Alchemy University**

O ciclo de execução de um smart contract na Ethereum não é um processo à prova de falhas. Agentes mal-intencionados exploram a blockchain implementando [ataques de reentrância](https://solidity-by-example.org/hacks/re-entrancy/) para transferir e drenar fundos de smart contracts vulneráveis. Tomar medidas preventivas garantirá aos desenvolvedores Solidity ciclos de execução mais seguros e a proteção de seus protocolos de blockchain.

Para aprender sobre as melhores práticas de desenvolvimento de smart contracts em Solidity, participe do [Ethereum Developer Bootcamp de 7 semanas](https://www.alchemy.com/university/courses/ethereum?a=c1cf9a376f), gratuito, da Alchemy. Originalmente um curso de certificação de $3.000, o bootcamp da Alchemy University é o principal lugar para [aprender Solidity de graça](https://www.alchemy.com/overviews/learn-solidity).

Se os desenvolvedores forem novos no desenvolvimento em geral, o **curso intensivo de JavaScript de 3 semanas** da Alchemy é um ótimo pré-requisito antes de iniciar um bootcamp de Ethereum.
