Rust smart contracts journal (7) Contract Security and Access Control
Cet article présentera le contrôle des accès dans les smart contracts Rust sous deux aspects :
Visibilité des méthodes d'accès/appel des smart contracts
Contrôle d'accès des fonctions privilégiées / Répartition des droits et responsabilités
1. Visibilité des fonctions de contrat
Il est crucial de définir correctement la visibilité des fonctions des contrats pour protéger les parties essentielles. Prenons l'exemple de l'incident de sécurité de l'échange Bancor Network en juin 2020, où la fonction de transfert clé a été par erreur définie comme publique, mettant ainsi en danger les actifs des utilisateurs.
Dans les smart contracts Rust, la visibilité des fonctions est également importante. Le macro #[near_bindgen] dans le SDK NEAR définit les attributs de visibilité suivants :
pub fn: fonction publique, peut être appelée depuis l'extérieur du contrat
fn: ne peut être appelé que de l'intérieur du contrat
pub(crate) fn: limiter les appels à l'intérieur de crate
Vous pouvez également définir des méthodes internes via des blocs impl Contract qui ne sont pas annotés par #[near_bindgen].
Pour la fonction de rappel, elle doit être définie comme publique mais ne peut être appelée que par le contrat lui-même. Cette fonctionnalité peut être réalisée à l'aide de la macro #[private].
Il convient de noter que la visibilité par défaut dans Rust est privée, mais les éléments dans les traits et les énumérations sont des exceptions.
2. Contrôle d'accès des fonctions privilégiées
En plus de la visibilité des fonctions, il est nécessaire d'établir un mécanisme de liste blanche de contrôle d'accès complet. À l'instar des contrats Ownable de Solidity, certaines fonctions privilégiées ne peuvent être appelées que par le propriétaire.
Dans un contrat Rust, il est possible de mettre en œuvre le trait Ownable suivant :
Cela permet de mettre en place une liste blanche pour le propriétaire. Il est également possible de définir des listes blanches multi-utilisateurs ou un contrôle d'accès par groupe via des paramètres de traits plus complexes personnalisés.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
14 J'aime
Récompense
14
6
Partager
Commentaire
0/400
CryptoTarotReader
· 07-16 04:56
Peut-on vraiment l'interdire~
Voir l'originalRépondre0
FloorSweeper
· 07-15 01:10
Pas possible, il faut apprendre autant.
Voir l'originalRépondre0
WhaleWatcher
· 07-13 07:29
D'abord Ownable, ensuite on en parlera.
Voir l'originalRépondre0
GateUser-e51e87c7
· 07-13 07:23
Il suffit d'avoir des mains, c'est aussi simple que ça.
Voir l'originalRépondre0
DecentralizeMe
· 07-13 07:22
Wuwu logique de base
Voir l'originalRépondre0
ChainSpy
· 07-13 07:21
Le contrôle d'accès est si complexe qu'il vaut mieux tout rendre public.
Contrôle d'accès des smart contracts Rust : visibilité des fonctions et gestion des accès privilégiés
Rust smart contracts journal (7) Contract Security and Access Control
Cet article présentera le contrôle des accès dans les smart contracts Rust sous deux aspects :
1. Visibilité des fonctions de contrat
Il est crucial de définir correctement la visibilité des fonctions des contrats pour protéger les parties essentielles. Prenons l'exemple de l'incident de sécurité de l'échange Bancor Network en juin 2020, où la fonction de transfert clé a été par erreur définie comme publique, mettant ainsi en danger les actifs des utilisateurs.
Dans les smart contracts Rust, la visibilité des fonctions est également importante. Le macro #[near_bindgen] dans le SDK NEAR définit les attributs de visibilité suivants :
Vous pouvez également définir des méthodes internes via des blocs impl Contract qui ne sont pas annotés par #[near_bindgen].
Pour la fonction de rappel, elle doit être définie comme publique mais ne peut être appelée que par le contrat lui-même. Cette fonctionnalité peut être réalisée à l'aide de la macro #[private].
Il convient de noter que la visibilité par défaut dans Rust est privée, mais les éléments dans les traits et les énumérations sont des exceptions.
2. Contrôle d'accès des fonctions privilégiées
En plus de la visibilité des fonctions, il est nécessaire d'établir un mécanisme de liste blanche de contrôle d'accès complet. À l'instar des contrats Ownable de Solidity, certaines fonctions privilégiées ne peuvent être appelées que par le propriétaire.
Dans un contrat Rust, il est possible de mettre en œuvre le trait Ownable suivant :
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); }
Cela permet de mettre en place une liste blanche pour le propriétaire. Il est également possible de définir des listes blanches multi-utilisateurs ou un contrôle d'accès par groupe via des paramètres de traits plus complexes personnalisés.