Continuamos nossa série de artigos educativos e hoje veremos algumas dicas específicas para auditoria durante o desenvolvimento de contratos inteligentes no Solidity!
O dia de hoje também marca a conclusão de uma série de três partes na qual exploraremos vários aspectos das funções de um auditor (ou desenvolvedor, se estivermos falando de auditoria interna), desde a otimização de gas até a proteção contra ataques e limites de EVM. Garantimos que será agradável! Mais artigos serão publicados em breve!
A propósito, há algumas vagas agora. Portanto, se o seu projeto precisar de uma auditoria, sinta-se à vontade para nos escrever, visite nossa página de relatórios públicos aqui. Entre em contato: [email protected]!
Por que você precisa ler este artigo?
As auditorias são essenciais para detectar possíveis riscos à segurança e evitar possíveis explorações que possam ser aproveitadas por agentes mal-intencionados. Elas fornecem uma camada extra de garantia ao identificar falhas que podem ter sido negligenciadas durante o desenvolvimento. Além disso, as auditorias ajudam a atender aos requisitos regulamentares e, ao mesmo tempo, aumentam a credibilidade e a confiança entre usuários e investidores, pois demonstram um compromisso com a segurança.
A Practical Introduction To Solidity Assembly: Part 1
Além disso, as auditorias podem ajudar a avaliar os aspectos econômicos e de teoria dos jogos dos contratos inteligentes. Garantir que a lógica e os incentivos do contrato estejam alinhados com os resultados desejados é fundamental em sistemas descentralizados. Ao auditar o contrato, podemos verificar se ele se comporta como esperado e se as variáveis econômicas, como mecanismos de emissão de tokens ou mecanismos de staking estão alinhadas com as metas do projeto.
Nos últimos meses, temos desenvolvido ativamente nossos próprios detectores Slither (consulte nossa ferramenta Slitherin) para auxiliar na revisão do código e no processo de auditoria. Informe-nos caso tenha descoberto um problema/bug/vulnerabilidade por meio de nossos detectores Slither personalizados. Você pode entrar em contato conosco abrindo um PR/Issue ou diretamente, o que for mais conveniente para você!
Podemos dizer com segurança que essas dicas podem ser lidas publicamente em poucos lugares e nosso blog é um desses lugares. A seguir, apresentamos nossas observações - apenas fatos secos para auditores, truques e os melhores hacks do dia a dia compartilhados por nossos melhores auditores.
Tudo o que você vê abaixo é baseado em nossa experiência pessoal. E hoje, queridos leitores, isso será disponibilizado para vocês!
Concluímos nossa própria pesquisa há alguns meses; leia-a se ainda não o fez:
Short Types in Solidity: Rare Tricks Uncovered
Você também encontrará uma lista de ferramentas e pesquisas para seu próprio estudo e recomendamos enfaticamente que você as leia separadamente para melhor compreensão! Vamos começar!
I — Limitações da EVM
Ninguém pode negar que a base de qualquer integração segura é uma abordagem única para a criação de códigos. Como resultado, este artigo se concentra apenas nas áreas que podem ser muito valiosas para manter seu código seguro e protegido.
Desde 2016, nosso time acumulou um número considerável de observações, que forneceremos aqui, juntamente com vários conselhos de segurança. As técnicas listadas abaixo podem ajudá-lo a aumentar consideravelmente a segurança da integração do seu projeto:
- Limite de tamanho de bytecode do contrato — 24kb;
- Os erros personalizados ocupam menos espaço no bytecode do que revert(“error text”) ;
- A inclusão do codificador antigo `pragma abicoder v1; Abicoder V2 é necessário se houver arrays de arrays ou arrays de estruturas no contrato. Mas, mesmo para argumentos simples, ele torna o bytecode muito mais complexo - tenha isso em mente;
- Em geral: public->external, memory->calldata;
- Os getters (incluindo variáveis públicas) podem ser removidos ou mesclados para reduzir o tamanho do contrato;
- Você também pode recusar tipos curtos (deixe apenas no armazenamento, use tipos completos em variáveis locais, cálculos e parâmetros);
- Os modificadores podem ser usados com menos frequência para reduzir o tamanho do contrato;
- Para reduzir o bytecode, você pode fazer Optimizer runs=1. Mas, infelizmente, ele gera chamadas mais caras;
- {}— blocos para restringir a visibilidade das variáveis locais;
Checagens Setter
- Normalmente há um Access Control (controle de acesso);
- Normalmente, é necessário emitir o evento;
- O armazenamento deve ser atualizado: um argumento de função é gravado no armazenamento (vi todas as três variantes incorretas - elas são bastante populares 🙂);
- Em projetos complexos, consideramos situações em que a alteração do endereço de um dos componentes do sistema afetará todo o protocolo;
Checagens de Loops
- Verifica se eles não são infinitos e que não possam se tornar infinitos (ou se há uma variante limitada disponível);
- Os loops vindos do final fazem uma verificação eficiente, e não
uint i = N; i >= 0(porque o tipo uint sempre retorna um valor positivo); -
Antes do Solidity 0.5.0,
continuedentro de do-while não funcionava corretamente:continuemuda a execução paradosem verificar a condição emwhile- isso torna o loopdo whileinfinito;
Timestamp/Dependência de Bloco
- Não meça o tempo em blocos (a menos que estejamos falando de hard-forks - eles estão vinculados a números de blocos). Às vezes, os blocos ficam mais lentos devido ao TimeBomb, e a mudança para o PoS fixará o tempo entre os blocos em 12 segundos, em vez dos atuais 13 segundos em média (PoW);
- Ocasionalmente, os contratos baseiam-se em intervalos muito pequenos. Em geral, se um contrato precisar de precisão superior a 15 minutos, pode ser perigoso;
- Alguns contratos verificam se algo acontece no máximo uma vez por bloco. Isso é aceitável como otimização (por exemplo, cobrança de juros), mas não é aceitável como medida de proteção contra qualquer reentrância \ flash loans (empréstimos relâmpago) \ outros ataques. Isso também interrompe as integrações - muitos usuários virão por meio de um contrato.
Checagens do Assembly
- O código em si não deve quebrar a memória:
a) " Desarrumar" o terceiro ou quarto espaço;
b) “Corromper" a memória já alocada - a partir do quarto slot e até o ponteiro de memória livre (valor no terceiro slot);
c) Muitas vezes, a quebra ocorre devido à cópia de
returndatapara o início da memória,returndatacopy(0, 0, returndatasize())- — consulte o segundo bloco de código na seção;
- Os blocos do Assembly devem ser rotulados como “memory-safe” se o forem (e não rotulados se não seguirem as convenções de memória);
- Não há checagens de overflow/underflow no Assembly;
- Ao gravar/ler de um slot storage exato, considere a estrutura de armazenamento ao herdar. Se B herdar de A, ao usar sstore() em B, deve-se tomar cuidado para não sobrescrever acidentalmente os slots do contrato base de A;
- Alterações nos designs em diferentes versões do Solidity: selfdestru é usado em vez de suicide desde a versão 0.5.0 e keccak256 é usado em vez de sha3 a partir da versão 0.5.0.
II — Referências Úteis
Gostaríamos de expressar nossa sincera gratidão aos autores de todos os materiais de apoio! Dê uma olhada nele:
- Smart Contract Security Verification Standard
- Opinionated security and code quality standard for Solidity smart contracts.
- Rare Tools For Audits
- AAVE V3 Integration Tips
PUSH1: or "Parsing EVM Bytecode"
Nós da pessimistic esperamos sinceramente que nosso trabalho seja útil e apreciamos qualquer feedback. Portanto, não hesite em entrar em contato conosco! As melhores respostas e perguntas poderão ser incluídas na próxima postagem do blog. Esperamos que este artigo tenha sido informativo e útil para você!
A propósito, várias auditorias foram concluídas com sucesso! Por falar nisso, há algumas vagas agora. Portanto, se o seu projeto precisar de uma auditoria, sinta-se à vontade para nos escrever, visite nossa página de relatórios públicos aqui!
Mantenha-se em segurança!
Esse artigo foi escrito por Officer's Notes e traduzido por Fátima Lima. O original pode ser lido aqui.
Top comments (0)