BNB Chain é um dos blockchains mais populares do mundo Web3. Suas taxas razoáveis, transações rápidas e rico ecossistema de projetos atraem um grande número de usuários. Como acontece com qualquer blockchain, os desenvolvedores da Cadeia BNB devem primeiro considerar as questões de segurança durante o processo de desenvolvimento: porque qualquer perda de fundos levará ao enfraquecimento da confiança do usuário no protocolo e na plataforma, e vulnerabilidades de segurança e ataques de hackers são um dos maiores riscos os desenvolvedores enfrentam.
Neste artigo, fornecemos dez dicas práticas de segurança para que os desenvolvedores possam reduzir riscos e desenvolver contratos inteligentes mais seguros na Cadeia BNB.
01
╱Definição ╱
Os ataques de repetição, também conhecidos como ataques de repetição e ataques de repetição, são um tipo comum de ataque no ambiente blockchain. Na segurança cibernética, um "ataque de repetição" é um tipo de ataque à rede em que uma transmissão de dados válida é repetida ou atrasada de forma maliciosa ou fraudulenta.
No contexto da Web3 e dos contratos inteligentes, isso geralmente significa que um invasor é capaz de repetir uma transação ou ação em um contrato inteligente sem a permissão do usuário original. Isto pode levar a várias formas de fraude, como gastos duplos, etc.
Esses ataques podem ter consequências graves para usuários e desenvolvedores porque permitem que os invasores reutilizem a mesma assinatura para obter acesso não autorizado a todos os fundos ou outros ativos do contrato inteligente.
Para evitar ataques de repetição, os desenvolvedores devem projetar e implementar cuidadosamente seu código de contrato inteligente e seguir a verificação de assinatura, bem como os melhores padrões de segurança do setor.
02
╱Análise de Caso╱
O trecho de código a seguir representa o processo de implementação da transferência de um token na cadeia BNB. O código é vulnerável a ataques de repetição, permitindo que um invasor reutilize a mesma assinatura.
Esse recurso carece de proteção nonce ou de reprodução, permitindo que um invasor "reproduza" uma transferência assinada várias vezes. Um invasor pode interceptar uma transação assinada e enviá-la novamente para o mesmo contrato ou outro contrato, e o contrato ainda a considerará válida, para que o invasor possa explorar esta vulnerabilidade para roubar ativos.
03
╱ Métodos de melhoria ╱
Adicione um nonce à assinatura ou use variáveis de mapeamento para registrar a assinatura. As soluções mais específicas irão variar dependendo do desenho do projeto.
01
╱Definição ╱
Um ataque de reentrada ocorre quando um contrato malicioso chama repetidamente um contrato vulnerável antes que a chamada inicial seja concluída. Em outras palavras, um invasor pode “enganar” um contrato vulnerável fazendo-o pensar que completou uma transação e está livre para passar para a próxima, mas na realidade ainda está executando o código malicioso do invasor.
Isso pode fazer com que um invasor consiga manipular o estado do contrato de maneiras inesperadas e potencialmente obter fundos não autorizados.
02
╱Análise de Caso╱
No trecho de código abaixo, os usuários podem sacar fundos de suas contas chamando a função de saque e especificando o valor que desejam sacar. No entanto, como a função de retirada não protege contra chamadas recursivas à função, ela fica vulnerável a ataques de reentrada.
Um invasor pode explorar a vulnerabilidade criando um contrato malicioso que chama a função de saque diversas vezes antes que o saldo seja realmente debitado de sua conta. A função msg.sender.call envia fundos para o contrato malicioso, e o invasor usa a função recebe() do contrato malicioso para retirar fundos repetidamente antes que seu saldo seja reduzido a zero, esgotando assim todos os fundos do contrato da vítima.
03
╱ Métodos de melhoria ╱
Faça atualizações de status antes de qualquer chamada externa.
Esse padrão é chamado de padrão "Check-Effects-Interact" e é um padrão de design usado para evitar ataques de reentrada em contratos inteligentes. Esse padrão separa as alterações de estado das chamadas externas para outros contratos, primeiro verificando as pré-condições e depois atualizando o estado antes de fazer qualquer chamada externa. Dessa forma, se uma chamada externa acionar um retorno de chamada que tenta retornar ao contrato, mas o estado já foi atualizado, outros efeitos inesperados serão evitados.
Seguindo esse padrão, os desenvolvedores podem garantir que seus contratos sejam mais seguros e menos suscetíveis a ataques de reentrada.
Outra solução possível é usar um modificador para limitar múltiplas chamadas para a mesma função, assim como o ReentrancyGuard do OpenZeppelin.
01
╱Definição ╱
Os oráculos podem ajudar os contratos inteligentes a recuperar informações de fora do blockchain. Normalmente, o preço de um ativo de bolsa descentralizada (DEX) é determinado pelo preço extraído pelo oráculo da última transação bem-sucedida na DEX.
Porém, o problema é que o preço pode ser facilmente manipulado por qualquer pessoa, causando problemas no contrato inteligente. Freqüentemente vemos casos de manipulação de oráculos de preços por meio de empréstimos instantâneos. A razão é que os empréstimos instantâneos permitem que os usuários tomem emprestado grandes quantias de dinheiro sem garantia, desde que paguem o empréstimo no mesmo bloco. Isto torna mais fácil para os atacantes influenciarem ou mesmo manipularem os preços, lucrando com falsas liquidações, empréstimos excessivos ou negociações injustas.
02
╱ Análise de Caso ╱
Abaixo está um trecho de código vulnerável a ataques de manipulação do oráculo.
Este contrato permite que os usuários troquem o token A pelo token B usando um contrato de roteamento, mas depende de um oráculo externo (contrato Uniswap Pair) para obter reservas de token A e token B para calcular o preço. Um invasor conseguiu manipular as reservas do contrato Uniswap Pair, bem como a função getAmountOut, fazendo com que o swap fosse executado a um preço irracional.
03
╱ Métodos de melhoria ╱
Para evitar esse ataque, os desenvolvedores devem usar uma rede oracle descentralizada que possa obter o preço médio ponderado por volume (VWAP) ou o preço médio ponderado por tempo (TWAP) de exchanges centralizadas e descentralizadas em cadeia. Dessa forma, os dados serão coletados de múltiplas fontes e em um amplo intervalo de tempo, tornando o código menos suscetível a ataques e manipulações. É importante que os desenvolvedores sejam capazes de remover quaisquer vetores de ataque que manipulem oráculos de contratos inteligentes para evitar vulnerabilidades potenciais.
01
╱Definição ╱
Definir adequadamente a visibilidade das funções garante a segurança e integridade dos contratos inteligentes. O uso de configurações incorretas de visibilidade de função pode permitir que usuários não intencionais manipulem o estado do contrato, levando a problemas sérios, como roubo de fundos ou controle da funcionalidade do contrato.
Ao definir a visibilidade de uma função como privada ou interna, você garante que os desenvolvedores tenham acesso limitado a determinadas funções e que somente pessoal autorizado possa chamá-las. As funções privadas só podem ser chamadas a partir do próprio contrato, enquanto as funções internas também podem ser chamadas a partir do contrato atual. Isso permite que os desenvolvedores criem contratos mais poderosos e complexos, mantendo o controle sobre o acesso à funcionalidade.
02
╱ Análise de Caso ╱
A função setAdmin() permite que qualquer pessoa defina qualquer endereço como administrador do contrato. Dependendo das permissões concedidas no contrato para gerenciar endereços, isso pode fazer com que o desenvolvedor perca o controle do próprio contrato e até mesmo cause perda de fundos.
Ao definir a visibilidade da função como internal , algumas funções do contrato podem permitir internamente que determinados usuários sejam definidos como administradores.
03
╱ Métodos de melhoria ╱
Os modificadores de acesso são um recurso de segurança importante que determina quem pode acessar funções ou variáveis específicas em um contrato. Esses modificadores podem ser usados para limitar a visibilidade de determinadas funções ou variáveis a funções ou endereços específicos e impedir que atores mal-intencionados obtenham acesso não autorizado ou manipulação do estado do contrato.
Por exemplo, um contrato pode ter uma função que somente o proprietário do contrato pode chamar ou uma variável que só pode ser acessada por um conjunto específico de endereços.
O acesso à função setAdmin pode ser restrito ao endereço do proprietário do contrato alterando o modificador de visibilidade para externo e definindo o modificador de acesso para onlyOwner. Isto impedirá que partes externas mal-intencionadas assumam o controle de certas funções privilegiadas.
O uso adequado de visibilidade e modificadores restritivos pode facilitar o gerenciamento de contratos e reduzir ataques comuns, como reentrada (um invasor chama repetidamente uma função para manipular o estado do contrato) ou ataques front-running (um invasor monitora transações pendentes e manipula o estado do contrato antes que a lei seja legalizada). transações são executadas).
Ao usar esses recursos de maneira adequada, os desenvolvedores podem aumentar a segurança e a confiabilidade de seus contratos, reduzir o risco de acesso não autorizado e melhorar a qualidade geral e a capacidade de manutenção de seu código.
01
╱Definição ╱
Ao decidir se atualizará um contrato no futuro, é importante considerar cuidadosamente a concepção do contrato inicialmente. A capacidade de atualização do contrato refere-se à propriedade de que a lógica de um contrato inteligente pode ser modificada ou atualizada após ser implantada no blockchain. Embora a capacidade de atualização possa oferecer muitas vantagens (como corrigir bugs, melhorar a eficiência ou adicionar novas funcionalidades), ela também apresenta alguns riscos. As atualizações de contratos podem introduzir novas vulnerabilidades, aumentar a complexidade do contrato ou causar consequências indesejadas.
A capacidade de atualização de contratos também levanta questões de confiança porque os administradores de agentes podem atualizar contratos sem o consenso da comunidade. Os desenvolvedores precisam pesar cuidadosamente as vantagens e desvantagens da capacidade de atualização e determinar se a introdução de contratos atualizáveis é realmente necessária para o seu projeto. Em alguns casos, é mais seguro elaborar um contrato que seja imutável desde o início, em vez de confiar na capacidade de modificá-lo posteriormente.
02
╱ Métodos de melhoria ╱
Quando se trata de capacidade de atualização de contratos, há diversas práticas importantes a serem seguidas. Em primeiro lugar, não modifique a biblioteca proxy. A biblioteca de contratos Proxy é extremamente complexa, especialmente em termos de gerenciamento de armazenamento e mecanismos de atualização. Mesmo pequenos erros podem afetar muito a operação de contratos proxy e lógicos. Na verdade, muitos dos erros críticos relacionados ao proxy descobertos durante a auditoria foram causados por modificações inadequadas na biblioteca do proxy.
Outro aspecto importante da capacidade de atualização do contrato é a inclusão de uma “lacuna” de armazenamento no contrato base. Os contratos lógicos devem incluir uma lacuna de armazenamento no código do contrato para dar conta de novas variáveis que podem ser introduzidas ao implantar novas implementações lógicas. Depois de adicionar novas variáveis de estado, a atualização do tamanho da “lacuna” torna-se ainda mais importante. Essa prática garante que futuras atualizações ocorrerão sem problemas e sem problemas.
Finalmente, você deve evitar usar selfdestruct() ou executar delegadocall()/call() em contratos não confiáveis. Um invasor pode explorar essas funções para subverter a implementação lógica ou executar lógica personalizada. Para evitar isso, é importante validar a entrada do usuário! Não permita que contratos executem delegadocall()/call() em contratos não confiáveis. Além disso, não é recomendado usar delegadocall() em contratos lógicos, pois pode ser difícil gerenciar o layout de armazenamento em vários contratos. Seguindo essas práticas, os desenvolvedores podem minimizar vulnerabilidades e riscos nas atualizações de seus contratos.
01
╱Definição ╱
O front-running sempre foi um problema teimoso e difícil de resolver, onde os usuários conseguem lucrar com o atraso entre o envio de uma transação e sua confirmação no blockchain. Esse atraso é causado pelo mempool.
mempool é uma área de armazenamento temporário usada para armazenar transações não confirmadas que foram transmitidas para a rede. Todos os nós da rede mantêm um mempool, permitindo que qualquer pessoa veja as transações pendentes e potencialmente intercepte e lucre com elas. Mempool também oferece aos mineradores a oportunidade de reorganizar as transações para maximizar seus lucros, criando o que é conhecido como valor extraível do minerador (ou máximo) (MEV).
02
╱ Análise de Caso ╱
Abaixo está um exemplo de um recurso de lance de leilão que tende a ser antecipado.
Esse recurso permite que os usuários façam lances em leilões, mas pode estar sujeito a ataques frontais. Suponha que um usuário mal-intencionado monitore o blockchain e veja que outro usuário apresentou um lance alto. O usuário mal-intencionado pode enviar rapidamente um lance mais alto e ser priorizado, vencendo o leilão.
Na versão seguinte, os usuários enviam preços de lances desconhecidos e esses lances são armazenados em um mapeamento. Os valores dos lances são criptografados até o final do período de lances.
03
╱ Métodos de melhoria ╱
Ao final do período de licitação, o usuário pode revelar seu lance enviando o valor original do lance e um valor secreto. O contrato verifica se o valor do lance e o hash secreto correspondem ao lance secreto armazenado, garantindo que o lance foi enviado antes do final do período do leilão. Se esse lance for superior ao lance máximo atual, ele se tornará o novo lance máximo. Esse recurso mitiga ataques frontais, mascarando os valores dos lances até o final do período do leilão.
Front-running e MEV tornaram-se grandes preocupações na comunidade blockchain, e várias soluções, como transações e Fair Ordering Services (FSS), foram propostas para resolver essas questões. As transações podem ajudar a evitar o front-running, ocultando os detalhes da transação de outros usuários até que a transação seja executada no blockchain. Por outro lado, o FSS pode reduzir o impacto do front-running e do MEV através de pedidos seguros de transações fora da cadeia.
Ter um plano de resposta claro e abrangente é fundamental para lidar com incidentes de segurança de emergência. O plano deve ser regularmente revisado, atualizado e testado quanto à eficácia. Quando ocorre uma emergência de segurança, o tempo é essencial. O plano deve, portanto, ser personalizado antecipadamente e incluir etapas operacionais detalhadas para identificação, controlo e mitigação.
O plano deve ser implementado de forma eficaz para manter todas as partes interessadas informadas. Ao mesmo tempo, o backup regular dos dados também é importante para evitar a perda de dados. O plano precisa delinear o processo de recuperação para restaurar dados e sistemas ao seu estado anterior. Os membros da equipe devem receber treinamento sistemático sobre o plano para garantir que todos compreendam suas funções e responsabilidades.
Um plano de resposta bem preparado pode não ser capaz de resolver o problema, mas pode minimizar o impacto do incidente e manter a confiança dos utilizadores e das partes interessadas.
Auditorias regulares de código são essenciais para manter a segurança do seu aplicativo. Trabalhar com um auditor profissional especializado em segurança de contratos inteligentes é uma etapa importante no processo de desenvolvimento. Os auditores examinarão o código em busca de vulnerabilidades e fornecerão recomendações para melhorar a segurança geral.
Priorizar e resolver problemas identificados e manter uma comunicação aberta com os auditores são essenciais para melhorar a segurança.
Além disso, a comunicação com os auditores também é crítica. Os auditores podem explicar detalhadamente os problemas e vulnerabilidades que descobriram e fornecer orientação e ajuda prática sobre como resolver a vulnerabilidade. Ao cooperar com agências/pessoal de auditoria profissional, a segurança será “levada para o próximo nível”.
Para os desenvolvedores da rede BNB, a realização de auditorias regulares é parte integrante de qualquer estratégia de segurança abrangente. Identificar e resolver proativamente vulnerabilidades em seu código pode minimizar o risco de violações de segurança.
Usar um programa de recompensas é uma forma eficaz de incentivar hackers de chapéu branco na comunidade a relatar vulnerabilidades de segurança no código de um projeto. Ao fornecer incentivos como tokens ou outras recompensas, qualquer projeto pode encorajar pessoas experientes a revisar o código e relatar quaisquer problemas potenciais que encontrarem.
É importante ter um programa de recompensas de bugs claro e transparente. O plano precisa incluir: quais tipos de vulnerabilidades descobertas são elegíveis para recompensas, como avaliar o valor dessas vulnerabilidades, etc. Ao mesmo tempo, incluir um terceiro respeitável em um programa de recompensas por bugs pode ajudar a garantir o bom funcionamento do programa e a distribuição justa de recompensas.
Ao mesmo tempo, é importante ter um “grupo de caçadores de recompensas” diversificado. Diferentes hackers de chapéu branco têm diferentes áreas de especialização e podem se concentrar em encontrar problemas que outros possam não perceber.
Finalmente, uma vez comunicadas as vulnerabilidades, devem ser tomadas medidas rápidas e eficazes para as resolver. Os programas de recompensas podem ser uma ferramenta eficaz para identificar vulnerabilidades, mas só fazem sentido se a equipe de desenvolvimento realmente resolver o problema.
Educar os usuários da Web3 sobre segurança é um passo fundamental na construção de um ecossistema seguro. Garantir a segurança dos clientes ajudará a garantir a segurança da plataforma. Os usuários devem ser informados sobre as melhores práticas para proteger suas contas e informações confidenciais.
A parte mais importante é aprender como evitar golpes de phishing.
Os golpistas de phishing enganam os usuários para que revelem suas chaves privadas ou senhas, fingindo ser um site ou serviço legítimo. CertiK recomenda que os usuários sempre verifiquem qualquer URL de e-mail, fonte, etc. do site usado ao receber qualquer informação e nunca insiram chaves privadas ou senhas em sites não confiáveis.
E outra parte importante é ter senhas seguras e fortes. A CertiK recomenda que os usuários usem senhas exclusivas e complexas para cada conta e evitem reutilizar senhas em diferentes serviços. Além disso, as senhas devem ser armazenadas de forma segura usando um gerenciador de senhas ou outro mecanismo de armazenamento seguro.
Finalmente, proteger as chaves privadas é extremamente importante. A chave privada equivale à senha do usuário e deve ser garantido que não será acessada por terceiros em nenhum momento. Os usuários devem evitar compartilhar suas chaves privadas com qualquer pessoa e mantê-las em um local seguro.
Resumir
Os desenvolvedores que criam contratos inteligentes e dApps na cadeia BNB devem adotar uma abordagem de segurança abrangente para manter os fundos e ativos de seus usuários seguros. O mais importante é ser proativo em vez de reativo ao lidar com violações de segurança; ter um plano em vigor quando ou mesmo antes de ocorrer uma violação e fornecer educação de segurança adequada a todos os utilizadores e partes interessadas relevantes. Ao combinar todas as medidas acima referidas, os projetos podem ser ajudados a reduzir significativamente o risco de violações de segurança e ataques de hackers.