Journal de développement de contrats intelligents Rust (7) Contrôle des accès pour la sécurité des contrats

Cet article présentera les aspects du contrôle des permissions dans les smart contracts Rust sous deux angles :

1. Visibilité d'accès/appel des méthodes (fonctions) de contrat
2. Contrôle d'accès des fonctions privilégiées / Répartition des droits et des responsabilités

1. Visibilité des fonctions (méthodes) du contrat

Lors de la rédaction de smart contracts, il est important de contrôler les droits d'appel des fonctions en spécifiant leur visibilité. Cela est essentiel pour protéger les parties sensibles du contrat contre un accès ou une manipulation accidentels.

Prenons l'exemple de l'échange Bancor Network, où un incident de sécurité s'est produit le 18 juin 2020 en raison d'une mauvaise configuration des droits d'accès aux fonctions clés du contrat. Ce contrat a été écrit en langage Solidity, et la visibilité des fonctions se divise en deux types : public/external et private/internal.

Lors de la correction d'une vulnérabilité de sécurité, Bancor a par erreur défini certaines fonctions de transfert clés comme publiques, ce qui a permis à quiconque d'appeler ces fonctions depuis l'extérieur du contrat pour effectuer des opérations de transfert, mettant ainsi en grave danger les actifs de 590 000 dollars des utilisateurs.

Dans les smart contracts Rust, le contrôle de la visibilité des fonctions est tout aussi important. Les fonctions de contrat marquées par le macro #[near_bindgen] défini par le NEAR SDK ont les attributs de visibilité suivants :

• pub fn: fonction publique, faisant partie de l'interface du contrat, pouvant être appelée depuis l'extérieur du contrat.
• fn : Fonction sans pub spécifiée, ne peut être appelée que dans le contrat.
• pub(crate) fn: limiter les appels à l'intérieur de la portée du crate.

Une autre façon de définir la méthode comme interne est de le faire dans un bloc de code impl Contract qui n'est pas annoté par #[near_bindgen].

Pour les fonctions de rappel, elles doivent être définies comme des propriétés publiques afin d'être appelées par un appel de fonction. Il est également nécessaire de s'assurer que la fonction de rappel ne peut être appelée que par le contrat lui-même, ce qui peut être réalisé en utilisant le macro #[private].

2. Contrôle d'accès des fonctions privilégiées ( Mécanisme de liste blanche )

En plus de la visibilité des fonctions, il est nécessaire d'établir un mécanisme complet de liste blanche de contrôle d'accès sur le plan sémantique. Certaines fonctions privilégiées (comme l'initialisation du contrat, l'activation/la mise en pause, le transfert unifié, etc.) ne peuvent être appelées que par le propriétaire du contrat (owner).

Il est possible de réaliser des Traits personnalisés pour contrôler l'accès aux fonctions privilégiées, en vérifiant si l'appelant de la transaction est le propriétaire du contrat :

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

Sur la base de ce principe, il est possible de définir des traits plus complexes pour configurer plusieurs utilisateurs ou plusieurs listes blanches dans la liste blanche, permettant ainsi un contrôle d'accès par groupes précis.

3. Méthodes de contrôle d'accès supplémentaires

D'autres méthodes de contrôle d'accès dans les smart contracts Rust incluent :

• Contrôle du moment d'appel des smart contracts
• Mécanisme d'appel multi-signatures des fonctions de contrat
• Gouvernance(DAO) de réalisation

Ces contenus seront détaillés dans la série de journaux de développement de smart contracts qui suivra.