Diário de Desenvolvimento de Contratos Inteligentes Rust (7) Segurança de Contratos e Controle de Acesso
Este artigo irá abordar o controle de permissões em contratos inteligentes Rust a partir de duas perspetivas:
Visibilidade de acesso/chamada de métodos (funções) do contrato
Controle de acesso/funções de privilégio/atribuição de responsabilidades
1. Visibilidade de funções (métodos) de contratos
Ao escrever contratos inteligentes, a visibilidade das funções do contrato pode ser especificada para controlar os direitos de chamada das funções, protegendo as partes críticas do contrato contra acessos ou manipulações indevidas.
Tomando como exemplo a exchange Bancor Network, no dia 18 de junho de 2020, ocorreu um incidente de segurança de ativos devido a uma configuração errada dos controles de acesso das funções chave do contrato. Este contrato foi escrito na linguagem Solidity, e a visibilidade das funções do contrato é dividida em duas categorias: public/external e private/internal. A primeira permite que as funções do contrato sejam chamadas por chamadores externos.
Ao modificar uma determinada vulnerabilidade de segurança, devido a um descuido, algumas funções de transferência críticas no contrato foram inadvertidamente definidas como públicas, permitindo que qualquer pessoa pudesse chamar essas funções a partir do exterior do contrato para realizar operações de transferência, colocando em sério risco os ativos de 590 mil dólares dos usuários.
Em contratos inteligentes Rust, também é fundamental prestar atenção ao controle de visibilidade das funções do contrato. As funções de contrato inteligente Rust marcadas com o macro #[near_bindgen] definido pelo NEAR SDK possuem os seguintes atributos de visibilidade diferentes:
pub fn: indica que este método é público e faz parte da interface do contrato, podendo ser chamado a partir do exterior do contrato.
fn: Se não for explicitamente indicado pub, significa que não pode ser chamado diretamente de fora do contrato, apenas pode ser chamado internamente por outras funções dentro do contrato.
pub(crate) fn: equivalente a pub( em crate), restringindo o método para ser chamado apenas dentro do escopo do crate.
Outra forma de definir o método do contrato como interno é definir um bloco de código impl Contract independente dentro do contrato, cuja implementação não é decorada com #[near_bindgen].
Para a função de callback (Callbacks), sua definição deve ser configurada como um atributo público, mas deve-se garantir que só possa ser chamada pelo próprio contrato. O NEAR SDK fornece o macro #[private] para implementar essa funcionalidade.
É importante notar que, na linguagem Rust, tudo é privado por padrão, exceto os subitens no pub Trait e as variáveis Enum no pub Enum que são públicas por padrão.
2. Controlo de Acesso a Funções Privilegiadas(Mecanismo de Lista Branca)
Além do controle de visibilidade das funções, é necessário estabelecer um mecanismo completo de lista branca de controle de acesso a partir do nível semântico do contrato. Certas funções privilegiadas (, como inicialização do contrato, ativação/desativação, transferências unificadas, etc., ) só podem ser chamadas pelo proprietário do contrato ( owner ). Essas funções são geralmente chamadas de funções "only owner".
Embora essas funções-chave precisem ser definidas como atributos públicos, é possível definir regras de controle de acesso, que devem ser atendidas para que a execução completa ocorra. Em contratos inteligentes Rust, é possível implementar um Trait personalizado semelhante ao modificador onlyOwner do Solidity:
Utilizando este trait é possível implementar o controle de acesso a funções privilegiadas no contrato, exigindo que o chamador seja o proprietário do contrato. Com base neste princípio, é possível definir modificadores ou traits mais complexos personalizados para configurar múltiplos usuários na lista branca, ou estabelecer várias listas brancas para alcançar um controle de acesso em grupos mais refinado.
3. Mais métodos de controlo de acesso
Outros métodos de controle de acesso em contratos inteligentes Rust incluem:
Controle do momento da chamada do contrato
Mecanismo de chamada múltipla de funções de contratos
Governança(DAO) da implementação
Este conteúdo será apresentado nos artigos subsequentes do diário de desenvolvimento de contratos inteligentes desta série.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
11 Curtidas
Recompensa
11
6
Compartilhar
Comentário
0/400
CompoundPersonality
· 22h atrás
Mais uma vez, teremos de lutar com a inteligência sobre os direitos de acesso.
Ver originalResponder0
MEVSupportGroup
· 22h atrás
Erro de permissão, estou a ficar frustrado. Juntando-me ao grupo para me aquecer.
Ver originalResponder0
MetaMaximalist
· 22h atrás
ugh, outro erro de principiante ao nível do bancor... é por isso que precisamos de verificação formal para todos os deployments de protocolos, a verdade seja dita.
Ver originalResponder0
TokenomicsTherapist
· 22h atrás
Eu lembro do Bancor, na época foi um desastre.
Ver originalResponder0
TokenEconomist
· 23h atrás
deixa-me explicar - o controlo de acesso é literalmente o abc da segurança dos contratos smh
Ver originalResponder0
Layer2Arbitrageur
· 23h atrás
lmao imagina escrever contratos rust sem o controlo de acesso adequado... ngmi a sério
Segurança de contratos inteligentes Rust: Guia completo de controle de permissões
Diário de Desenvolvimento de Contratos Inteligentes Rust (7) Segurança de Contratos e Controle de Acesso
Este artigo irá abordar o controle de permissões em contratos inteligentes Rust a partir de duas perspetivas:
1. Visibilidade de funções (métodos) de contratos
Ao escrever contratos inteligentes, a visibilidade das funções do contrato pode ser especificada para controlar os direitos de chamada das funções, protegendo as partes críticas do contrato contra acessos ou manipulações indevidas.
Tomando como exemplo a exchange Bancor Network, no dia 18 de junho de 2020, ocorreu um incidente de segurança de ativos devido a uma configuração errada dos controles de acesso das funções chave do contrato. Este contrato foi escrito na linguagem Solidity, e a visibilidade das funções do contrato é dividida em duas categorias: public/external e private/internal. A primeira permite que as funções do contrato sejam chamadas por chamadores externos.
Ao modificar uma determinada vulnerabilidade de segurança, devido a um descuido, algumas funções de transferência críticas no contrato foram inadvertidamente definidas como públicas, permitindo que qualquer pessoa pudesse chamar essas funções a partir do exterior do contrato para realizar operações de transferência, colocando em sério risco os ativos de 590 mil dólares dos usuários.
Em contratos inteligentes Rust, também é fundamental prestar atenção ao controle de visibilidade das funções do contrato. As funções de contrato inteligente Rust marcadas com o macro #[near_bindgen] definido pelo NEAR SDK possuem os seguintes atributos de visibilidade diferentes:
Outra forma de definir o método do contrato como interno é definir um bloco de código impl Contract independente dentro do contrato, cuja implementação não é decorada com #[near_bindgen].
Para a função de callback (Callbacks), sua definição deve ser configurada como um atributo público, mas deve-se garantir que só possa ser chamada pelo próprio contrato. O NEAR SDK fornece o macro #[private] para implementar essa funcionalidade.
É importante notar que, na linguagem Rust, tudo é privado por padrão, exceto os subitens no pub Trait e as variáveis Enum no pub Enum que são públicas por padrão.
2. Controlo de Acesso a Funções Privilegiadas(Mecanismo de Lista Branca)
Além do controle de visibilidade das funções, é necessário estabelecer um mecanismo completo de lista branca de controle de acesso a partir do nível semântico do contrato. Certas funções privilegiadas (, como inicialização do contrato, ativação/desativação, transferências unificadas, etc., ) só podem ser chamadas pelo proprietário do contrato ( owner ). Essas funções são geralmente chamadas de funções "only owner".
Embora essas funções-chave precisem ser definidas como atributos públicos, é possível definir regras de controle de acesso, que devem ser atendidas para que a execução completa ocorra. Em contratos inteligentes Rust, é possível implementar um Trait personalizado semelhante ao modificador onlyOwner do Solidity:
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 proprietário do contrato. Com base neste princípio, é possível definir modificadores ou traits mais complexos personalizados para configurar múltiplos usuários na lista branca, ou estabelecer várias listas brancas para alcançar um controle de acesso em grupos mais refinado.
3. Mais métodos de controlo de acesso
Outros métodos de controle de acesso em contratos inteligentes Rust incluem:
Este conteúdo será apresentado nos artigos subsequentes do diário de desenvolvimento de contratos inteligentes desta série.