Diário de Desenvolvimento de Contratos Inteligentes Rust (7) Segurança de Contratos e Controle de Acesso

Este artigo abordará o controle de permissões em contratos inteligentes Rust sob duas perspetivas:

1. Visibilidade de acesso/chamada de métodos (funções) em contratos
2. Controle de acesso/funções privilegiadas/divisão de responsabilidades

1. Visibilidade de funções (métodos) de contrato

Ao escrever contratos inteligentes, é possível controlar os direitos de chamada das funções especificando a visibilidade das funções do contrato, protegendo assim as partes críticas do contrato contra acessos ou manipulações acidentais.

Tomando como exemplo a exchange Bancor Network, ocorreu um incidente de segurança de ativos em 18 de junho de 2020, devido a um erro na configuração das permissões de controle de acesso das funções chave do contrato. O contrato foi escrito na linguagem Solidity, e a visibilidade das funções do contrato é dividida em public/external e private/internal. A primeira permite que as funções do contrato sejam chamadas por chamadores externos, podendo ser vistas como parte da interface do contrato.

A Bancor Network, ao corrigir uma certa vulnerabilidade de segurança, definiu erroneamente algumas funções de transferência chave no contrato como públicas, permitindo que qualquer pessoa pudesse chamar essas funções a partir de fora do contrato para realizar operações de transferência. Essa vulnerabilidade crítica colocou os ativos de 590.000 dólares dos seus usuários em sério risco.

Na Rust, os contratos inteligentes também precisam dar atenção ao controle de visibilidade das funções do contrato. O macro #[near_bindgen] definido pelo NEAR SDK pode ser usado para modificar as funções dos contratos inteligentes em Rust, e existem as seguintes diferentes propriedades de visibilidade:

• pub fn: indica que este método é público, faz parte da interface do contrato e pode ser chamado externamente.
• fn: Não especificar explicitamente pub significa que não pode ser chamado diretamente de fora do contrato, apenas pode ser chamado dentro do contrato.
• pub(crate) fn: Restringir o método para ser chamado dentro do escopo do crate.

Outra forma de definir o método do contrato como internal é definir um bloco de código impl Contract independente que não seja decorado com #[near_bindgen] dentro do contrato.

Para a função de retorno de chamada (Callbacks), deve ser definido como um atributo public na definição para poder ser chamado através de function call. Também é necessário garantir que a função de retorno de chamada não possa ser chamada por outros, ou seja, o chamador deve ser o próprio contrato. O SDK da NEAR fornece o macro #[private] para implementar essa funcionalidade.

É importante notar que, na linguagem Rust, por padrão, todo o conteúdo é privado, exceto os subitens em pub Trait e as variáveis Enum em pub Enum, que são públicas por padrão.

2. Controle de Acesso a Funções Privilegiadas(mecanismo de lista branca)

Além da visibilidade das funções, é necessário estabelecer um mecanismo completo de lista branca de controle de acesso a partir da perspectiva semântica do contrato. Certas funções privilegiadas (, como a inicialização do contrato, ativação/pausa, transferência unificada, etc., ) só podem ser chamadas pelo proprietário do contrato (owner), e essas funções são geralmente chamadas de funções "only owner".

Embora estas funções-chave tenham de ser definidas como propriedades públicas para serem chamadas externamente, podem ser definidas regras de controlo de acesso, que devem ser cumpridas para serem executadas na íntegra. Por exemplo, pode-se implementar o seguinte Trait personalizado:

ferrugem pub trait Ownable { fn assert_owner(&self) { assert_eq!(env::predecessor_account_id(), self.get_owner()); } AccountId; fn set_owner(&mut self, owner: AccountId); }

Utilizando este trait, é possível implementar o controle de acesso a funções privilegiadas no contrato, exigindo que o chamador seja o owner do contrato. Com base neste princípio, é possível definir modificadores ou traits personalizados mais complexos para configurar múltiplos usuários ou várias listas brancas, permitindo um controle de acesso em grupo mais refinado.