A equipe de segurança do SlowMist disponibiliza os Requisitos de Prática de Segurança do Projeto Web3, que oferecem requisitos e recomendações práticas detalhadas para ajudar as equipes de desenvolvimento de projetos Web3 a identificar e evitar possíveis riscos à segurança. As equipes de projetos Web3 podem consultar esses requisitos de prática de segurança fornecidos neste artigo, adquirir as habilidades de segurança correspondentes, aprimorar a segurança dos projetos Web3 e proteger melhor os ativos dos projetos e os usuários.
Este artigo foi publicado pela primeira vez no GitHub:
https://github.com/slowmist/Web3-Project-Security-Practice-Requirements
Os links relacionados no artigo podem ser acessados no GitHub. Todos podem ler, compartilhar e salvar este artigo através do mesmo.
Os Requisitos de Prática de Segurança de Projeto Web3 incluem o seguinte conteúdo:
0x00 Visão geral
Atualmente, há uma crescente quantidade de ataques contra projetos Web3, e as interações entre os projetos estão se tornando cada vez mais complexas. A interação entre vários projetos frequentemente introduz novos problemas de segurança, e a maioria das equipes de desenvolvimento Web3 geralmente não possui experiência em ataques e defesa de segurança de ponta. Durante o desenvolvimento de projetos Web3, o foco está na demonstração dos aspectos comerciais do projeto e na implementação de suas funcionalidades, o que faz com que não haja energia suficiente para construir um sistema de segurança abrangente. Portanto, sem um sistema de segurança adequado, é difícil garantir a segurança de um projeto Web3 ao longo de seu ciclo de vida.
Normalmente, as equipes de projeto buscam uma equipe de segurança em blockchain de excelência para realizar auditorias de segurança em seu código, a fim de garantir projetos Web3 seguros. Embora as auditorias de segurança possam ajudar a atender a vários requisitos de práticas de segurança, elas são apenas uma medida de curto prazo e não permitem que a equipe de projeto estabeleça seu próprio sistema de segurança.
Portanto, a equipe de segurança da SlowMist disponibilizou os Requisitos de Prática de Segurança de Projeto Web3
abertamente. Esses requisitos pretendem auxiliar as equipes de projetos no ecossistema blockchain a dominar as habilidades de segurança específicas para projetos Web3. Espera-se que a equipe de projeto possa estabelecer e aprimorar seu próprio sistema de segurança com base nesses requisitos e também adquirir recursos de segurança adicionais após as auditorias de segurança.
0x01 Preparação para o Desenvolvimento
1 Requisitos de análise de requisitos de documentos
Certifique-se de incluir uma descrição completa do projeto;
Certifique-se de incluir o problema específico que o projeto deve resolver;
Certifique-se de incluir uma avaliação de risco de segurança / privacidade;
2 Requisitos de documentação do projeto de desenvolvimento
Certifique-se de incluir o diagrama de projeto arquitetônico do projeto;
Certifique-se de incluir descrições funcionais das funções no código;
Certifique-se de incluir uma descrição do relacionamento entre os contratos no código;
Certifique-se de incluir requisitos de segurança / privacidade;
3 Requisitos de documentação do processo comercial
Certifique-se de incluir uma descrição de cada processo de negócios no projeto;
Certifique-se de incluir um diagrama detalhado do processo comercial;
Certifique-se de incluir um diagrama de link de financiamento detalhado;
0x02 Processo de desenvolvimento
1 Requisitos de codificação de segurança de contrato inteligente
Certifique-se de desenvolver com base em bibliotecas conhecidas, como o OpenZeppelin, tanto quanto possível;
Certifique-se de incluir um compilador que use SafeMath ou 0.8.x para evitar a maioria dos problemas de estouro;
Siga as convenções de nomenclatura das funções, consulte: solidity style guide;
Verifique se a função e a visibilidade da variável são declaradas explicitamente;
Verifique se o valor de retorno da função está explicitamente atribuído;
Verifique se as funções e os parâmetros estão bem anotados;
Verifique se as chamadas externas verificam corretamente o valor do retorno, incluindo: transfer, transferFrom, send, call, delegcall, etc.;
Verifique se a implementação do tipo do parâmetro e do valor de retorno da interface está correta;
Verifique se os principais parâmetros do contrato estão configurados com autenticação e use eventos para gravar;
Verifique se a estrutura de dados do novo contrato de implementação do modelo atualizável é compatível com a estrutura de dados do antigo contrato de implementação;
Certifique-se de que a lógica envolvida nas operações aritméticas no código considera completamente o problema de precisão e evite o problema de possível perda de precisão causada pela divisão e multiplicação;
Verifique se o endereço de destino e funções de baixo nível, são esperadas como call;
Ao usar chamadas de baixo nível, como call, limite o gás conforme as necessidades dos negócios;
As especificações de codificação são restritas, siga primeiro, julgue, e depois escreva as variáveis e faça chamadas externas ( Verificações-Efeitos-Interações );
Verifique se os contratos externos que interagem nos negócios são compatíveis entre si, como: tokens de deflação / inflação, tokens reentrantes como ERC-777, ERC-677, ERC-721, consulte: Reentrancy Vulnerability Case;
Verifique se as chamadas externas consideram completamente o risco de reentrada;
Evite usar muitos loops para atribuir / ler a variável de armazenamento do contrato;
Evite o problema de concentração excessiva de autoridade, tanto quanto possível, especialmente a autoridade para modificar os principais parâmetros do contrato, separe a autoridade e use governança, contrato de timelock ou contrato de várias assinaturas para o gerenciamento o máximo possível;
A relação de herança dos contratos deve manter a herança linear e garantir que os contratos herdados sejam realmente necessários para os negócios;
Evite usar dados de bloco on-chain como fonte de semente aleatória;
Certifique-se de que a aquisição e o uso de números aleatórios considerem completamente a possibilidade de ataques de reversão;
Utilize o VRF (Verifiable Random Function) da Chainlink para obter aleatoriedade confiável. Consulte: Chainlink VRF;
Evite usar a quantidade de token do contrato de terceiros para calcular diretamente o preço do LP Token, consulte: How to get the price of LP correctly;
Evite uma única fonte de preço para obter os preços através de contratos de terceiros. Recomenda-se o uso de pelo menos três fontes;
Utilize eventos sempre que possível nos principais processos de negócios para registrar o status de execução visando análise de dados durante a execução do projeto;
Reserve a opção para uma suspensão de emergência do negócio global e principal,de forma a facilitar a interrupção de perdas a tempo quando ocorrer um evento de cisne negro;
2 Requisitos de código de caso de teste
Certifique-se de incluir o processo de negócios / função de teste de usabilidade funcional;
Verifique se a taxa de cobertura do teste unitário é superior a 95% e a taxa de cobertura do código principal deve chegar a 100%;
3 Requisitos básicos de configuração de segurança
Verifique se o email oficial usa provedores de serviços conhecidos, como o Gmail;
Verifique se a conta de email oficial abre a função MFA;
Verifique se o uso de provedores de serviços de nomes de domínio conhecidos, como o GoDaddy;
Certifique-se de que o uso de excelentes provedores de serviços CDN, como Akamai e Cloudflare;
Verifique se a configuração do DNS ativa o DNSSec; defina uma senha forte para a conta de gerenciamento na plataforma de gerenciamento de serviços de nomes de domínio e ative a autenticação MFA;
Verifique se todos os telefones celulares e dispositivos de computador usam software antivírus, como Kaspersky, AVG, etc.;
4 Requisitos de configuração de segurança front-end Web
Verifique se a comunicação HTTP de todo o site adota HTTPS;
Verifique se o HSTS está configurado para evitar ataques do tipo intermediário, como: sequestro de DNS e sequestro de BGP, consulte:HSTS Configuration Introduction;
Verifique se o X-FRAME-OPTIONS está configurado para impedir ataques de Clickjacking, consulte: X-FRAME-OPTIONS Configuration Introduction;
Verifique se as opções de tipo de conteúdo X estão configuradas para combater os riscos causados pelo comportamento de rastreamento do navegador:X-Content-Type-Options Configuration Introduction;
Verifique se as políticas de CSP estão configuradas para impedir ataques XSS, consulte: CSP Configuration Introduction;
Verifique se os cookies relacionados às permissões e credenciais do usuário estão configurados com os sinalizadores HttpOnly, Secure, Expires, SameSite, consulte: Cookie Configuration Introduction;
Certifique-se de que os subdomínios de diferentes empresas sejam estritamente separados para evitar os problemas XSS dos subdomínios que se afetam;
Verifique se os recursos de terceiros mencionados são restritos pelo atributo de integridade, para evitar que terceiros sejam invadidos e o site do projeto seja afetado, consulte:SRI Configuration Introduction;
Verifique se o CORS está configurado corretamente para permitir que apenas o domínio, protocolo e porta de origem especificados acesse os recursos do projeto, consulte: CORS Configuration Introduction;
Verifique se o addEventListener / postMessage implementado na empresa tem a origem e o destino da mensagem de verificação, consulte:postMessage Configuration Introduction;
5 Requisitos de configuração de segurança do ambiente do servidor
Verifique se selecionou bons provedores de servidores em nuvem, como AWS, Google Cloud etc.;
Verifique se a conta de gerenciamento da plataforma em nuvem usada pelo projeto usa uma senha forte e com o MFA ativo .
Certifique-se de reforçar a segurança do servidor antes que o código do projeto seja implantado nele, como instalar HIDS, usar chave SSH para fazer login, configurar alertas de login SSH, configurar autenticação do Google para login SSH, etc.;
Certifique-se de usar serviços de monitoramento de software profissionais e disponibilidade do servidor, como APM e Zabbix;
Certifique-se de usar instituições profissionais para testar regularmente a segurança de projetos, como SlowMist, Trail of Bits, etc.;
0x03 Processo de liberação
É necessário um processo completo de liberação de segurança online, que pode ser refinado consultando o seguinte conteúdo
1 Requisitos de congelamento de código
- O tempo estimado de lançamento é adiado 2 dias, ou seja, o código deve ser congelado e nenhuma alteração de código será feita 2 dias antes do lançamento;
2 Requisitos de teste da unidade
Verifique se a taxa de cobertura dos testes unitários está acima de 95% e a taxa de cobertura do código principal é de 100%;
Certifique-se de produzir relatórios de cobertura para testes unitários;
3 Requisitos de teste de regressão
- Certifique-se de produzir relatórios de cobertura para testes unitários;
4 Requisitos do relatório de teste
- 0,5 dias antes do lançamento, o desenvolvimento e o teste concluirão em conjunto o relatório de teste. Se o relatório de teste não for aprovado (incluindo testes unitários e de regressão), o tempo de lançamento será adiado, e o estágio de congelamento do código será reentrado após a conclusão do desenvolvimento e modificação ( ou seja, adiada por pelo menos 2 dias );
5 Requisitos de auditoria de segurança
Os auditores de segurança entram na regressão geral de segurança após o congelamento do código. Se for encontrado algum risco de vulnerabilidade ou segurança (grave, de alto e médio risco), o tempo de lançamento será adiado, e o código será congelado novamente após a conclusão do desenvolvimento e modificação (ou seja, atrasado por pelo menos 2 dias).
A auditoria de segurança requer pelo menos três equipes para realizar auditorias independentes e pode usar 1 equipe interna + 2 equipes externas;
0x04 Processo de tempo de execução
1 Monitoramento de segurança em tempo de execução
Tanto quanto possível, através dos eventos acionados nos principais processos de negócios para descobrir os problemas de segurança do tempo de execução do projeto, como:
Atualização de importantes permissões / parâmetros do contrato: monitore os eventos que a função de gerenciamento altera e os eventos onde a função de gerenciamento modifica os principais parâmetros do contrato, e a descoberta do possível roubo da chave privada;
Alterações nos fundos do contrato: monitore as mudanças de preço e os fundos do contrato e detecte oportunamente possíveis ataques, como empréstimos instantâneos;
Reconciliação periódica: reconcilie periodicamente eventos e transações na cadeia para descobrir possíveis problemas de lógica de negócios em tempo hábil;
2 Fortalecimento da segurança do ambiente de execução
Verifique o fortalecimento da segurança do servidor em que o código front-end está localizado, como:Instalação de HIDS,Login com chave SSH,Definiçãop de alerta de login SSH,Configuração do login SSH para o google-auth etc;
Verifique se o DNS Sec está ativado na configuração do DNS, defina uma senha forte para a conta de gerenciamento na plataforma de gerenciamento de serviços de nomes de domínio e ative 2 autenticações;
Verifique se a conta de gerenciamento da plataforma em nuvem usada pelo projeto usa uma senha forte e possui 2 autenticações ativadas;
3 Programa de recompensas de bugs de lançamento
- Publique um programa de recompensas por bugs ou participe de uma plataforma conhecida de recompensas por bugs para atrair "white hats" da comunidade para proteger o projeto; você pode escolher: BugRap,code4rena,imunodefi;
4 Forme um Grupo de Resposta de Emergência
- Estabeleça um Grupo de Resposta de Emergência nominal e forneça informações de contato para o mundo exterior. O grupo de resposta de emergência é responsável por lidar com problemas encontrados por "white hats" ou liderar os membros da equipe a realizar uma resposta de emergência quando ocorrer um cisne negro.
0x05 Resposta de emergência
1 Estabelecer um processo completo de resposta a emergências
- Desenvolva um processo completo de resposta a emergências, tanto quanto possível, e lide com os eventos de cisne negro de maneira ordenada, de acordo com o processo de resposta a emergências;
2 Requisitos de Disposição de Interrompimento de Perdas
De acordo com o alcance do problema e o grau de prejuízo, interrompa as perdas por meio do interruptor de pausa de emergência em tempo hábil;
Notifique os membros da comunidade sobre eventos de cisne negro para evitar que os usuários continuem interagindo com o projeto e causem perdas.
3 Requisitos de rastreamento de hackers
Analise rapidamente o endereço lucrativo do hacker e mantenha o registro de acesso do PC/Web/servidor (se houver um trojan, mantenha o arquivo do trojan);
Capture uma imagem do servidor e mantenha o registro do cenário do hack em tempo hábil;
Entre em contato com uma equipe de segurança profissional para ajudar no rastreamento, como MistTrack , Chainalysis;
4 Requisitos de resolução de problemas
Discuta as melhores correções para o problema com uma equipe de segurança profissional;
Implemente corretamente o plano fixo e solicite a uma equipe de segurança profissional que o verifique;
5 Requisitos de liberação de segurança
- Aplique os requisitos do processo de liberação para garantir que todas as alterações de código sejam testadas e a segurança auditada;
6 Requisitos de análise de problemas
Divulgue os relatórios de análise pós-incidente e sincronize os planos e soluções de restauração com os membros da comunidade;
O relatório de análise pós-incidente deve sincronizar a causa raiz do problema, o escopo do problema, as perdas específicas, a solução para o problema, o rastreamento do hacker e outros progressos relacionados.
Resumo
A segurança é um aspecto crítico e em constante evolução no gerenciamento de projetos Web3. Confiar exclusivamente em auditorias de curto prazo realizadas por equipes de segurança terceirizadas não é suficiente para garantir a segurança e estabilidade a longo prazo de um projeto. Portanto, é crucial estabelecer medidas adequadas e seguir os Requisitos de Prática de Segurança do Projeto SlowMist | Web3 para garantir a continuidade da segurança nos projetos Web3. As equipes de projetos devem desenvolver um entendimento abrangente da segurança e contar com os recursos necessários para garantir operações seguras e estáveis em seus projetos Web3.
Recomendamos fortemente que as equipes de projetos se envolvam ativamente com a comunidade de segurança e mantenham-se atualizadas com as mais recentes tecnologias, experiências de ataque e defesa de segurança. Ao colaborar com outras equipes de projeto e especialistas em segurança, eles podem trabalhar em conjunto para melhorar a segurança de todo o ecossistema. Além disso, fornecer treinamento interno de segurança e compartilhar conhecimento pode aumentar a conscientização e as capacidades de segurança de todos os funcionários, o que é uma etapa crítica para estabelecer e aprimorar o sistema de segurança.
Por fim, vale ressaltar que as práticas de segurança de projetos Web3 estão atualmente na versão 0.1 e estão sendo continuamente aprimoradas. Portanto, valorizamos qualquer feedback e sugestão para aprimorar ainda mais a segurança dos projetos Web3.
Se você precisar de ajuda, não hesite em nos contatar pelo e-mail [email protected] ou [email protected].
Convidamos você a nos seguir no Twitter para obter informações adicionais e relevantes.
Sobre o SlowMist
A SlowMist é uma empresa de segurança blockchain fundada em janeiro de 2018. A empresa foi criada por uma equipe com mais de dez anos de experiência em segurança de rede, com o objetivo de se tornar uma força global. Nosso objetivo é tornar o ecossistema blockchain o mais seguro possível para todos os usuários. Atualmente, somos uma renomada empresa internacional de segurança blockchain que colaborou em diversos projetos reconhecidos, tais como Huobi, OKX, Binance, imToken, Crypto.com, Amber Group, Klaytn, EOS, 1inch, PancakeSwap, TUSD, Alpaca Finance, MultiChain, O3Swap, entre outros.
- Website: https://www.slowmist.com/
- Twitter:https://twitter.com/SlowMist_Team
- Github: https://github.com/slowmist/
Este artigo foi escrito por SlowMist e traduzido por Adriano P. de Araujo. O original em inglês pode ser encontrado aqui.
Top comments (0)