Successfully reported this slideshow.
Your SlideShare is downloading. ×

Seguranca.pdf

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 27 Ad

More Related Content

Recently uploaded (20)

Advertisement

Seguranca.pdf

  1. 1. Smart Contract Security Ou como dormir a noite sabendo que pessoas podem perder dinheiro usando seu código
  2. 2. Sobre mim ● Trabalho com Solidty há ~5 anos. ● ~3 Anos trabalhando exclusivamente com auditor de smart contracts. ● Desenvolvedor full time num protocolo de Defi. ● Desenvolvi alguns projetos de NFT paralelamente.
  3. 3. O que é segurança 1. Garantir que o smart contract faz o que você quer. 2. Garantir que o smart contract não faz o que você não quer.
  4. 4. 1. Exemplos ● 11k ETH trancado num contrato de NFT ● MoonCats
  5. 5. 2. Exemplos ● Rekt News
  6. 6. Segurança é um espectro ● Nenhum Smart Contract é 100% seguro. ● Relativo ao "valor" do contrato. ● Relativo ao tempo de uso do contrato. ● SEGURANÇA É UM PROCESSO.
  7. 7. Vulnerabilidades comuns ● Ethereum Smart Contract Security Recommendations ● List of security vulnerabilities ● Smart contract vulnerabilities
  8. 8. A maioria dos exploits acontecem por problemas específicos.
  9. 9. Partes do Processo ● Unit Tests ● Integration tests ● Fuzz tests ● Invariant tests ● User testing ● Auditoria(s) Interna ● Auditoria(s) Externa ● Bug Bounty ● Crowd audits ● Verificacao formal ● Guarded releases
  10. 10. Se você quer desenvolver alguma coisa com valor, 80% do tempo deve ser gasto testando.
  11. 11. Unit Test ● Garantir que a menor "unidade" do seu código funciona. ● Isolar ao máximo fatores e elementos externos. ● Mais fácil para funções puras. ● Geralmente, é o ponto mais fácil de começar. ● Faz-se o uso de mocks e harnesses.
  12. 12. Exemplo Unit Testing
  13. 13. Integration Tests ● Testar que diferentes elementos do código funcionam juntos. ● Testar que diferentes contratos do protocolo funcionam juntos. ● Preferencialmente não utilizar mocks e harnesses. ● Mais proveitoso quando já se sabe que os elementos funcionam individualmente.
  14. 14. Fuzz Tests Casos de testes que aceitam inputs aleatórios. ● Bom para descobrir edge cases. ● Bom para entender/definir quais são os limites do código. ● Delegar parte do trabalho de pensar em cenários para um software. ● Pode ser feito tanto em unit tests quanto em integration tests.
  15. 15. Exemplo Fuzz Test solmate
  16. 16. Invariant testing Bombardear o contrato ou protocolo com transações aleatórias para garantir que algumas condições sejam sempre verdadeiras. ● Bom para descobrir edge cases. ● Bom para determinar quais são os estados desejáveis do contrato. ● Requer um bom tempo para montar a infraestrutura do código.
  17. 17. Exemplo de invariante ERC20 "A soma de todas as balances deve ser igual ao total supply" solmate
  18. 18. User testing Em um ambiente controlado, fazer exatamente o que o usuário fará. ● Inclui testar a interface. ● Idealmente feito por pessoas que não desenvolveram. ● Bom para achar erros que não são "exclusivos" dos smart contracts. ● É bastante trabalhoso. ● Umas das últimas fases antes do release.
  19. 19. Verificacao Formal É o processo de elaborar uma prova matemática abstrata que corresponde ao funcionamento do sistema. ● É uma mistura de teste e auditoria. ● É bem caro e complexo. ● Bom para tipos específicos de contratos.
  20. 20. Auditorias são como backups. Se você só tem um, você não tem nenhum.
  21. 21. O que é uma auditoria
  22. 22. O que é uma auditoria Processo de analisar o código, por diversos métodos, a fim de achar falhas. ● É necessário que haja o distanciamento entre o auditor e o desenvolvedor. ● São custosas e demoradas. ● Bom para achar erros nos "pontos cegos" dos desenvolvedores.
  23. 23. Auditoria Interna Os próprios desenvolvedores fazem uma auditoria do código.
  24. 24. Auditoria Externa Delegar para terceiros, ou indivíduos ou empresas, que analisam o código. ● Cada auditor tem seu método próprio. ● Não é garantia de segurança. ● As baratas geralmente são ruins. O "resultado" é um relatório para os desenvolvedores sobre potenciais problemas no código.
  25. 25. Crowd Audits / Bug Bounties Ao invés de contratar uma única empresa para realizar uma auditoria, pública-se o código e se oferece recompensas para quem achar problemas. ● Os "incentivos" dos auditores são diferentes ● Tende a ser mais barata que uma auditoria externa. ● Não se tem a métrica de quem analisou o código. Exemplos: Code4rena e Immunefi
  26. 26. Guarded Launches Deployar o sistema com "guardas", que são removidas lentamente, à medida que se ganha confiança no código. ● Forma de diminuir o risco e impacto de potenciais problemas. ● Recomendável para a maioria dos contratos/protocolos.
  27. 27. Dúvidas?

×