Finanças Descentralizadas comuns vulnerabilidades de segurança e medidas de prevenção
Recentemente, um especialista em segurança compartilhou uma aula sobre segurança em Finanças Descentralizadas com os membros da comunidade. Ele revisou os principais eventos de segurança que o setor Web3 enfrentou no último ano e meio, discutiu as causas desses eventos de segurança e como evitá-los, resumiu as vulnerabilidades de segurança comuns em contratos inteligentes e as medidas preventivas, e ainda deu algumas recomendações de segurança para as equipes de projeto e usuários comuns.
Os tipos comuns de vulnerabilidades em Finanças Descentralizadas incluem empréstimos relâmpago, manipulação de preços, problemas de permissões de funções, chamadas externas arbitrárias, problemas com funções de fallback, vulnerabilidades de lógica de negócios, vazamento de chaves privadas e ataques de reentrada. Este artigo se concentrará em empréstimos relâmpago, manipulação de preços e ataques de reentrada.
Empréstimo Relâmpago
Os empréstimos relâmpago são uma inovação das Finanças Descentralizadas, mas quando explorados por hackers, eles podem emprestar grandes quantidades de fundos sem custo algum, realizar arbitragem e devolvê-los, pagando apenas uma pequena taxa de Gas para obter lucros enormes.
Muitos projetos de Finanças Descentralizadas parecem oferecer altos retornos, mas na realidade, o nível das equipes por trás dos projetos varia bastante. Alguns projetos podem ter códigos que foram comprados; mesmo que o código em si não tenha vulnerabilidades, ainda podem existir problemas lógicos. Por exemplo, um determinado projeto pode distribuir recompensas em horários fixos com base na quantidade de tokens que os detentores possuem, mas os atacantes podem aproveitar empréstimos relâmpago para comprar uma grande quantidade de tokens e, assim, obter a maior parte das recompensas quando estas são distribuídas.
Além disso, há alguns projetos que calculam preços através de tokens, que podem ser afetados por empréstimos relâmpago. Como parte do projeto, deve-se estar atento a essas questões.
Manipulação de Preços
O problema de manipulação de preços está intimamente relacionado com os empréstimos relâmpago, e existem principalmente dois tipos comuns:
Utiliza dados de terceiros ao calcular preços, mas a forma de utilização é incorreta ou a verificação está em falta, levando a que os preços sejam manipulados de forma maliciosa.
Usar a quantidade de tokens de certos endereços como variável de cálculo, onde o saldo de tokens desses endereços pode ser temporariamente aumentado ou diminuído.
Ataque de Reentrada
Um dos principais perigos de chamar contratos externos é que eles podem assumir o controle do fluxo e fazer alterações nos dados chamando funções de maneira não prevista. Por exemplo:
Uma vez que o saldo do usuário só é definido como 0 no final da função, a segunda (e posteriores) chamadas ainda terão sucesso e retirarão o saldo repetidamente.
Para resolver o problema da reentrada, é necessário prestar atenção aos seguintes pontos:
Não se limita a prevenir o problema de reentrada de uma única função.
Seguir o padrão Checks-Effects-Interactions ao codificar
Use um modifier de proteção contra reentrância testado ao longo do tempo
Há muitas melhores práticas de segurança neste campo que devemos usar diretamente em vez de reinventar a roda. Usar soluções maduras e testadas tem muito menos probabilidade de apresentar problemas do que desenvolver novas soluções por conta própria.
Sugestões de segurança para o projeto
O desenvolvimento de contratos deve seguir as melhores práticas de segurança.
Contratos atualizáveis e pausáveis: muitos ataques não transferem todos os fundos de uma só vez, mas executam em várias transações. Se houver um mecanismo de monitoramento relativamente sólido, é possível detectar e pausar o contrato a tempo, reduzindo efetivamente as perdas.
Utilizar um bloqueio temporal: Se houver um bloqueio temporal, pode-se dar tempo suficiente para que as pessoas detectem anomalias e tomem medidas.
Aumentar o investimento em segurança e estabelecer um sistema de segurança completo: a segurança é um sistema, que inclui não apenas auditoria de contratos, mas também gestão de chaves privadas, modelos econômicos e outros aspectos.
Aumentar a consciência de segurança de todos os colaboradores: muitos problemas de segurança podem ser evitados aumentando a vigilância.
Prevenir a má conduta interna, aumentando o controle de risco ao mesmo tempo que se melhora a eficiência: a utilização de mecanismos como multi-assinaturas e bloqueios de tempo pode aumentar a segurança sem comprometer a eficiência.
Segurança da introdução de terceiros: deve haver validação de segurança para ambos os lados, especialmente para contratos não abertos, que devem ser tratados com cautela.
Como os usuários/LP podem determinar se um contrato inteligente é seguro?
O contrato é de código aberto: não participe de projetos que não sejam de código aberto.
O proprietário utiliza múltiplas assinaturas? As múltiplas assinaturas são descentralizadas?
Ver a situação das transações existentes do contrato: inclui tempo de implantação, número de interações, etc.
O contrato é um contrato proxy, é atualizável, tem um bloqueio de tempo?
O contrato foi auditado por várias instituições? Os direitos do proprietário são excessivos?
Atenção aos oráculos: projetos que utilizam oráculos conhecidos são relativamente mais seguros, enquanto oráculos próprios ou facilmente manipuláveis devem ser tratados com cautela.
Em resumo, em um ambiente Web3, manter-se alerta e fazer mais perguntas do porquê pode evitar muitos riscos potenciais. Tanto os desenvolvedores de projetos quanto os usuários comuns devem valorizar as questões de segurança, estabelecendo uma consciência de segurança abrangente e mecanismos de prevenção.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
9 Curtidas
Recompensa
9
6
Compartilhar
Comentário
0/400
MEVHunterNoLoss
· 10h atrás
Esses problemas de segurança são uma der
Ver originalResponder0
AirdropHustler
· 21h atrás
Ainda é melhor ensinar como fazer Airdrop.
Ver originalResponder0
BearMarketBuilder
· 22h atrás
Você já publicou todas as vulnerabilidades, como os hackers vão brincar agora?
Ver originalResponder0
LightningAllInHero
· 22h atrás
Não diga mais nada, da última vez tudo em foi culpa dos Empréstimos Flash.
Ver originalResponder0
FUD_Whisperer
· 22h atrás
Depois de mais de meio ano de DeFi, não sou tão rápido quanto um hacker.
Guia de Segurança DeFi: Estratégias de Prevenção para Empréstimos Flash, Manipulação de Preços e Ataques de Reentrada
Finanças Descentralizadas comuns vulnerabilidades de segurança e medidas de prevenção
Recentemente, um especialista em segurança compartilhou uma aula sobre segurança em Finanças Descentralizadas com os membros da comunidade. Ele revisou os principais eventos de segurança que o setor Web3 enfrentou no último ano e meio, discutiu as causas desses eventos de segurança e como evitá-los, resumiu as vulnerabilidades de segurança comuns em contratos inteligentes e as medidas preventivas, e ainda deu algumas recomendações de segurança para as equipes de projeto e usuários comuns.
Os tipos comuns de vulnerabilidades em Finanças Descentralizadas incluem empréstimos relâmpago, manipulação de preços, problemas de permissões de funções, chamadas externas arbitrárias, problemas com funções de fallback, vulnerabilidades de lógica de negócios, vazamento de chaves privadas e ataques de reentrada. Este artigo se concentrará em empréstimos relâmpago, manipulação de preços e ataques de reentrada.
Empréstimo Relâmpago
Os empréstimos relâmpago são uma inovação das Finanças Descentralizadas, mas quando explorados por hackers, eles podem emprestar grandes quantidades de fundos sem custo algum, realizar arbitragem e devolvê-los, pagando apenas uma pequena taxa de Gas para obter lucros enormes.
Muitos projetos de Finanças Descentralizadas parecem oferecer altos retornos, mas na realidade, o nível das equipes por trás dos projetos varia bastante. Alguns projetos podem ter códigos que foram comprados; mesmo que o código em si não tenha vulnerabilidades, ainda podem existir problemas lógicos. Por exemplo, um determinado projeto pode distribuir recompensas em horários fixos com base na quantidade de tokens que os detentores possuem, mas os atacantes podem aproveitar empréstimos relâmpago para comprar uma grande quantidade de tokens e, assim, obter a maior parte das recompensas quando estas são distribuídas.
Além disso, há alguns projetos que calculam preços através de tokens, que podem ser afetados por empréstimos relâmpago. Como parte do projeto, deve-se estar atento a essas questões.
Manipulação de Preços
O problema de manipulação de preços está intimamente relacionado com os empréstimos relâmpago, e existem principalmente dois tipos comuns:
Utiliza dados de terceiros ao calcular preços, mas a forma de utilização é incorreta ou a verificação está em falta, levando a que os preços sejam manipulados de forma maliciosa.
Usar a quantidade de tokens de certos endereços como variável de cálculo, onde o saldo de tokens desses endereços pode ser temporariamente aumentado ou diminuído.
Ataque de Reentrada
Um dos principais perigos de chamar contratos externos é que eles podem assumir o controle do fluxo e fazer alterações nos dados chamando funções de maneira não prevista. Por exemplo:
solidity mapping (address => uint) private userBalances;
função withdrawBalance() pública { uint amountToWithdraw = userBalances[msg.sender]; (bool sucesso, ) = msg.sender.call.value(quantiaParaRetirar)(""); require(success); userBalances[msg.sender] = 0; }
Uma vez que o saldo do usuário só é definido como 0 no final da função, a segunda (e posteriores) chamadas ainda terão sucesso e retirarão o saldo repetidamente.
Para resolver o problema da reentrada, é necessário prestar atenção aos seguintes pontos:
Há muitas melhores práticas de segurança neste campo que devemos usar diretamente em vez de reinventar a roda. Usar soluções maduras e testadas tem muito menos probabilidade de apresentar problemas do que desenvolver novas soluções por conta própria.
Sugestões de segurança para o projeto
O desenvolvimento de contratos deve seguir as melhores práticas de segurança.
Contratos atualizáveis e pausáveis: muitos ataques não transferem todos os fundos de uma só vez, mas executam em várias transações. Se houver um mecanismo de monitoramento relativamente sólido, é possível detectar e pausar o contrato a tempo, reduzindo efetivamente as perdas.
Utilizar um bloqueio temporal: Se houver um bloqueio temporal, pode-se dar tempo suficiente para que as pessoas detectem anomalias e tomem medidas.
Aumentar o investimento em segurança e estabelecer um sistema de segurança completo: a segurança é um sistema, que inclui não apenas auditoria de contratos, mas também gestão de chaves privadas, modelos econômicos e outros aspectos.
Aumentar a consciência de segurança de todos os colaboradores: muitos problemas de segurança podem ser evitados aumentando a vigilância.
Prevenir a má conduta interna, aumentando o controle de risco ao mesmo tempo que se melhora a eficiência: a utilização de mecanismos como multi-assinaturas e bloqueios de tempo pode aumentar a segurança sem comprometer a eficiência.
Segurança da introdução de terceiros: deve haver validação de segurança para ambos os lados, especialmente para contratos não abertos, que devem ser tratados com cautela.
Como os usuários/LP podem determinar se um contrato inteligente é seguro?
O contrato é de código aberto: não participe de projetos que não sejam de código aberto.
O proprietário utiliza múltiplas assinaturas? As múltiplas assinaturas são descentralizadas?
Ver a situação das transações existentes do contrato: inclui tempo de implantação, número de interações, etc.
O contrato é um contrato proxy, é atualizável, tem um bloqueio de tempo?
O contrato foi auditado por várias instituições? Os direitos do proprietário são excessivos?
Atenção aos oráculos: projetos que utilizam oráculos conhecidos são relativamente mais seguros, enquanto oráculos próprios ou facilmente manipuláveis devem ser tratados com cautela.
Em resumo, em um ambiente Web3, manter-se alerta e fazer mais perguntas do porquê pode evitar muitos riscos potenciais. Tanto os desenvolvedores de projetos quanto os usuários comuns devem valorizar as questões de segurança, estabelecendo uma consciência de segurança abrangente e mecanismos de prevenção.