Contratos inteligentes de auto-auditoria com ChatGPT

Ao auditar contratos inteligentes, é necessário abranger uma vasta gama de questões para garantir que o código é seguro. Estas questões abrangem vários aspectos, incluindo o controlo de acesso, a gestão de activos, a gestão de dados, os pressupostos, as dependências e as listas de verificação de segurança. Abaixo, fornecemos uma lista de verificação detalhada e instruções para as perguntas do ChatGPT para o orientar no processo de auditoria de contratos inteligentes.

Se quiser investigar um contrato inteligente em busca de vulnerabilidades e técnicas de burla ocultas, o primeiro passo é um prompt ChatGPT corretamente elaborado.

Um pedido útil para o ChatGPT seria o seguinte comando:

Forneça uma lista exaustiva de todos os problemas e vulnerabilidades do seguinte contrato inteligente. Descreva os problemas e as possíveis vulnerabilidades em pormenor. Fornecer um cenário de exploração para cada vulnerabilidade. Apresentar uma tabela válida em formato markdown com uma lista de objectos, cada um com as colunas "descrição", "ação", "gravidade", "actores", "cenário", "tipo" e "linha". O "tipo" pode ser "usabilidade", "vulnerabilidade", "otimização" ou "sugestão". "actores" é uma lista dos actores envolvidos. "severity" (gravidade) pode ser "low" (baixa), "medium" (média) ou "high" (alta). "linha" é o número da linha do problema. Certifique-se de que todos os campos do quadro estão preenchidos.

Em seguida, utilize as seguintes perguntas para explorar o contrato inteligente em maior profundidade.

Cenários de utilização:

1. Quem são os actores do sistema?


2. Que acções tem o sistema?


3. Quais são as limitações do sistema?


4. Quais são algumas formas potenciais de quebrar o sistema?


5. Que defesas são utilizadas para contrariar os ataques?


6. Descreva, com base nas restrições, as mudanças de estado de cada função.


7. Fornecer informações sobre os modelos Solidity e DeFi utilizados.


8. Escrever axiomas positivos e negativos com base em informações sobre o sistema.


9. Enumerar as formas de otimizar e modificar o código para o tornar mais fiável (com trechos de código).


10. Enumerar os métodos de fraude oculta utilizados no código (com excertos de código).

Sugestão: A representação visual dos dados permite muitas vezes compreender melhor o funcionamento do sistema. Ao trabalhar com o ChatGPT, recomenda-se que solicite visualizações dos dados de saída, tais como modificações de estado sob a forma de diagramas de caracteres ASCII. Embora nem todas as visualizações possam ser significativas, algumas podem fornecer informações muito valiosas sobre o funcionamento de um contrato inteligente.

Em essência, embora o ChatGPT não possa substituir um auditor humano, ele complementa significativamente o processo de auditoria, fornecendo uma compreensão mais clara das transições de estado do protocolo, restrições, invariantes e compatibilidade. Esta ferramenta é particularmente eficaz para compreender as transições de estado do protocolo e as restrições.

Sugestão: Antes de iniciar uma auditoria, fornecer ao chatbot documentação sobre o protocolo que está a ser auditado pode melhorar bastante a precisão e a relevância das respostas. Basta mencionar "Esta é a documentação que fornece o melhor contexto para o 'nome_do_protocolo' que estou a auditar" e inserir o documento.

Pode dizer-se que o ChatGPT é um assistente poderoso para os auditores, fornecendo uma abordagem estruturada e aprofundada à auditoria de contratos inteligentes. No entanto, deve ter-se em conta que o ChatGPT (e serviços semelhantes) são apenas interpretações complexas de análises de máquinas que trabalham com probabilidades, pelo que produzem frequentemente erros e imprecisões. Por conseguinte, não se deve confiar plenamente no resultado do ChatGPT - é apenas uma boa ferramenta nas mãos certas e um "ponto de partida" na investigação de contratos inteligentes.

Por conseguinte, para se proteger de possíveis riscos, os contratos inteligentes devem ser examinados com mais cuidado para detetar possíveis vulnerabilidades e esquemas fraudulentos.

Como realizar uma auditoria aprofundada de contratos inteligentes? 100 principais pedidos para ChatGPT

Acima, considerámos um pedido geral (prompt) ao ChatGPT, a partir do qual se pode começar a analisar um contrato inteligente. Mas, como é óbvio, uma análise detalhada não se limita ao pedido introdutório.

Os burlões estão constantemente a melhorar as suas tácticas, pelo que é necessário estar informado e ser cauteloso de muitas formas - estas são estratégias essenciais para proteger o seu investimento em tokens.

Vejamos uma lista das 100 principais consultas que lhe darão uma abordagem profissional para uma auditoria de contrato inteligente:

1. O código é compilado com êxito?
2. Que versão do Solidity é utilizada no código? É a versão estável atual?
3. Existem comentários claros que explicam o objetivo das funções e variáveis?
4. O contrato utiliza o regime "Apropriável"? Em caso afirmativo, para que funções?
5. As variáveis de estado estão corretamente atribuídas utilizando modificadores de visibilidade?
6. Os eventos são utilizados para o registo adequado?
7. São fornecidas mensagens de erro fáceis de utilizar?
8. O valor de retorno das chamadas de baixo nível é verificado?
9. Existem cenários em que o proprietário pode autorizar-se a si próprio, o que poderia levar a uma "puxada de tapete"?
10. Quem tem controlo sobre as contas privilegiadas e quais são os mecanismos de controlo?
11. Que mecanismos de governação existem no contrato, e a governação é totalmente aberta ou limitada?
12. São utilizados outros contratos no sistema e que funções desempenham (por exemplo, contrato de procuração)?
13. Existe um mecanismo de bloqueio de tempo e este pode ser contornado?
14. Existe documentação adequada disponível?
15. Existem potenciais vulnerabilidades a ataques DoS ou de reentrada no código?
16. Todas as funções são internas, exceto as que são explicitamente obrigadas a ser públicas/externas?
17. Não há transbordos/subtransbordamentos aritméticos em operações matemáticas?
18. Está a ser utilizada a biblioteca segura OpenZeppelin?
19. Éter ou tokens não podem ser enviados acidentalmente para um endereço nulo (0x0)?
20. As condições são verificadas com require antes das operações e alterações de estado?
21. O estado é definido antes e durante a execução das acções?
22. É utilizada proteção contra ataques de reentrada (A chama B chama A) (A chama B chama A)?
23. A interface ERC20 está corretamente implementada?
24. O modificador é utilizado em vários locais apenas se for realmente necessário?
25. Todos os tipos estão definidos explicitamente (por exemplo, uint256 é utilizado em vez de uint)?
26. Todos os métodos e ciclos estão dentro do limite máximo admissível de gás?
27. Não há inicializações desnecessárias no construtor (lembre-se que os valores por defeito estão definidos)?
28. A cobertura dos testes é total: todos os métodos de contratos inteligentes e todos os tipos de dados de entrada possíveis são testados?
29. O teste de fuzz foi efectuado com entradas aleatórias?
30. São testados todos os estados possíveis em que um contrato pode ser celebrado?
31. As quantidades predefinidas de éter e fichas são especificadas em unidades de wei?
32. O bloco/horário de fim do crowdsale é posterior ao bloco/horário de início (início/ativação da negociação)?
33. A taxa de câmbio/conversão dos tokens de crowdsale está corretamente definida?
34. Existe um limite suave/duro para a venda colectiva?
35. A contribuição mínima/máxima permitida para a venda colectiva está definida e testada?
36. A funcionalidade de lista branca de crowdsale foi testada?
37. A lógica de reembolso da venda colectiva foi testada?
38. Os participantes na crowdsale recebem um número proporcional de tokens ou podem reclamar a sua contribuição?
39. A duração de cada fase do crowdsale (por exemplo, pré-venda, venda pública) está corretamente configurada?
40. Especifica quais as funções que só devem ser controladas pelo proprietário (por exemplo, pausar a venda colectiva, passar para outra fase da venda colectiva, permitir a distribuição de fichas, etc.)?
41. A lógica de aquisição de direitos (vesting) do crowdsale foi testada?
42. O Crowdsale tem um modo de segurança que, quando ativado pelo proprietário, limita as chamadas de recursos e inclui um recurso de reembolso?
43. A venda colectiva tem uma funcionalidade de recurso se fizer sentido.
44. As bibliotecas importadas foram previamente verificadas e não contêm partes indesejadas que possam ser substituídas em versões futuras e que possam ser utilizadas para fins maliciosos?
45. Métodos de transferência de tokens (transferência) envolvidos no require?
46. O require e o assert são utilizados corretamente? O método assert só é utilizado para coisas que nunca deveriam acontecer, normalmente é utilizado para verificar o estado após uma alteração ter sido efectuada.
47. Existe uma defesa contra ataques de chamadas recursivas?
48. Os comprimentos das cadeias arbitrárias na entrada são limitados?
49. Sempre que possível, evitar a utilização de matrizes e utilizar mapeamentos?
50. Os hashes de bloco não são utilizados para tratar valores aleatórios (os mineiros podem afetar este aspeto)?
51. Não utiliza tx.origin em lado nenhum?
52. Os elementos da matriz são deslocados para baixo quando um elemento é eliminado, de modo a não deixar espaços vazios?
53. É utilizado o revert em vez do throw?
54. As funções terminam imediatamente se as condições não forem cumpridas?
55. Os avisos do compilador foram resolvidos?
56. A biblioteca SafeMath é utilizada nos cálculos?
57. Alguma das ranhuras de memória (ranhuras de armazenamento) é lida mais do que uma vez?
58. Estão a ser utilizados loops/matrizes sem restrições que possam causar DoS?
59. O block.timestamp só é utilizado para intervalos longos?
60. Não está a utilizar block.number para calcular o tempo decorrido?
61. A chamada delegatecall é evitada, especialmente para contratos externos (mesmo que de confiança)?
62. O comprimento da matriz não é atualizado ao iterar sobre ela?
63. As assinaturas estão protegidas contra replay com nonce e block.chainid?
64. Certificar-se de que todas as assinaturas estão a utilizar o EIP-712?
65. O resultado de abi.encodePacked() não deve ser submetido a hash se forem utilizados mais de 2 tipos dinâmicos. Em geral, é preferível utilizar abi.encode().
66. Verificar cuidadosamente as inserções de código de montagem.
67. Evitar o consumo insuficiente de gás (gas griefing).
68. Todos os dados privados são realmente privados?
69. A atualização de uma estrutura/matriz na memória (memory) não a altera no armazenamento (stage)?
70. As variáveis da fase são ofuscadas?
71. Calcular o valor de uma variável em tempo real é mais barato do que armazená-lo?
72. Todas as variáveis de estado são lidas a partir do contrato correto (master vs. clone)?
73. Os operadores de comparação (>, <, >=, <=) são utilizados corretamente, especialmente para evitar erros de comparação?
74. Os operadores lógicos (==, !=, &&, ||, !) são utilizados corretamente, especialmente para evitar erros de um para um?
75. A multiplicação é sempre efectuada antes da divisão (a menos que a multiplicação possa transbordar)?
76. Os números mágicos são substituídos por uma constante com um nome intuitivo?
77. Se um destinatário de ETH tiver uma função de recurso (fallback ) que possa ser cancelada (revertida), isso pode levar a um DoS?
78. É utilizada a norma SafeERC20 e os valores de retorno são verificados de forma segura?
79. Parte-se do princípio de que o remetente da msg.sender é sempre um utilizador relevante?
80. O tx.origin não é utilizado para autorização?
81. Não se utiliza address.transfer() ou address.send() em vez de .call.value()?
82. Quando utilizar chamadas de baixo nível, certifique-se de que existe um contrato antes de efetuar a chamada.
83. O código de montagem é utilizado para aceder ao chainid ou ao código/tamanho/hash do contrato em vez da sintaxe do Solidity?
84. A palavra-chave delete é utilizada quando se define uma variável para um valor nulo (0, false, "", etc.)?
85. As expressões passadas para operadores lógicos/comparações (&&/||/>=/==/etc) não devem ter efeitos secundários.
86. Ao lidar com vários endereços, pergunte a si próprio o que acontece se forem iguais?
87. O código está bem documentado? São fornecidos comentários e exemplos sempre que é utilizado código não normalizado?
88. Se for utilizada uma chamada externa, certificar-se de que é realmente necessária uma chamada externa do contrato?
89. O resultado da chamada externa é verificado e os erros são tratados?
90. O que acontece se a Chamada Externa utilizar todo o gás fornecido?
91. Se a Chamada externa chamar uma função específica, certificar-se de que a função existe efetivamente (funções fantasma).
92. Certificar-se de que não são utilizadas chamadas externas nos modificadores (modificadores)
93. São emitidos eventos para cada função que modifica o armazenamento?
94. Verifique os seus pressupostos sobre o que os contratos externos utilizados no essencial fazem e o que rendem.
95. Tenha em atenção os tokens que utilizam demasiadas ou poucas casas decimais. Certifique-se de que os valores máximos e mínimos suportados estão documentados.
96. A autoridade associada às funções está documentada?
97. Quais são os riscos quando os direitos de acesso são violados e como é que isso pode afetar os vários componentes do sistema?
98. O proprietário pode manipular tokens e ETH dentro do contrato?
99. Como é definido o endereço do oráculo (Oracle) e qual é o processo subjacente? Existem oráculos de reserva para backup?
100. Como são implementadas funções semelhantes noutros projectos, foram tidas em conta as melhores práticas?

Esta lista de verificação ajudá-lo-á a garantir a realização de uma auditoria de segurança completa dos contratos inteligentes Solidity. Abrange uma vasta gama de aspectos críticos para identificar e mitigar potenciais vulnerabilidades e riscos no código e nos sistemas relacionados.

 

Esperamos que estes exemplos o tenham ajudado a compreender melhor a metodologia de auditoria de contratos inteligentes.

Uma vez que toda a informação na cadeia de blocos é aberta (desde que, obviamente, o código-fonte do contrato seja verificado), munido deste conhecimento pode estudar independentemente os contratos inteligentes e identificar vários esquemas de burla.

No entanto, nós já fizemos tudo isso por ti! Inscreve-te para uma subscrição premium e obtém acesso a filtros exclusivos sobre características de contratos inteligentes e novas análises. Aumenta as tuas hipóteses de investir com sucesso em tokens lucrativos.

Cumprimentos, equipa do Lotus Market.

All posts