Journal de développement des smart contracts en Rust (7) Sécurité des contrats : précision des calculs
Cet article présentera le contrôle d'accès dans les smart contracts Rust sous deux aspects :
Accessibilité/Appel des méthodes de contrat
Contrôle d'accès des fonctions privilégiées / Répartition des responsabilités
1. Visibilité des fonctions de contrat
Il est essentiel de définir correctement la visibilité des fonctions des contrats pour protéger la sécurité des contrats. Prenons l'exemple de l'incident de sécurité survenu le 18 juin 2020 sur l'échange Bancor Network, où une fonction de transfert clé a été définie comme publique par erreur, mettant ainsi les actifs des utilisateurs en grave danger.
Dans les smart contracts Rust, la visibilité des fonctions se divise principalement en plusieurs types :
pub fn: fonction publique, tout le monde peut l'appeler depuis l'extérieur du contrat
fn : par défaut privé, ne peut être appelé que à l'intérieur du contrat
pub(crate) fn: restreindre l'appel à l'intérieur de crate
De plus, il est possible d'implémenter des méthodes internes en définissant un bloc impl sans #[near_bindgen].
Pour les fonctions de rappel, elles doivent être définies comme publiques mais nécessitent un contrôle d'accès supplémentaire :
rouille
#[private]
pub fn resolve_transfer(&mut self) {
env::log_str("Ceci est un rappel");
}
2. Contrôle d'accès aux fonctions privilégiées
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. On peut personnaliser les Traits pour obtenir un effet similaire au modificateur onlyOwner dans Solidity :
Cela peut limiter l'accès à certaines fonctions privilégiées uniquement au propriétaire. Sur cette base, il est possible de configurer des listes blanches multi-utilisateurs plus complexes ou plusieurs listes blanches, afin de réaliser un contrôle d'accès par groupes plus précis.
Dans les smart contracts Rust, il existe d'autres méthodes de contrôle d'accès, telles que le contrôle du timing des appels et le mécanisme de multi-signature, qui seront présentées dans des articles ultérieurs.
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.
Sécurité des smart contracts Rust : Pratiques de visibilité des fonctions et de contrôle d'accès
Journal de développement des smart contracts en Rust (7) Sécurité des contrats : précision des calculs
Cet article présentera le contrôle d'accès dans les smart contracts Rust sous deux aspects :
1. Visibilité des fonctions de contrat
Il est essentiel de définir correctement la visibilité des fonctions des contrats pour protéger la sécurité des contrats. Prenons l'exemple de l'incident de sécurité survenu le 18 juin 2020 sur l'échange Bancor Network, où une fonction de transfert clé a été définie comme publique par erreur, mettant ainsi les actifs des utilisateurs en grave danger.
Dans les smart contracts Rust, la visibilité des fonctions se divise principalement en plusieurs types :
De plus, il est possible d'implémenter des méthodes internes en définissant un bloc impl sans #[near_bindgen].
Pour les fonctions de rappel, elles doivent être définies comme publiques mais nécessitent un contrôle d'accès supplémentaire :
rouille #[private] pub fn resolve_transfer(&mut self) { env::log_str("Ceci est un rappel"); }
2. Contrôle d'accès aux fonctions privilégiées
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. On peut personnaliser les Traits pour obtenir un effet similaire au modificateur onlyOwner dans Solidity :
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 peut limiter l'accès à certaines fonctions privilégiées uniquement au propriétaire. Sur cette base, il est possible de configurer des listes blanches multi-utilisateurs plus complexes ou plusieurs listes blanches, afin de réaliser un contrôle d'accès par groupes plus précis.
Dans les smart contracts Rust, il existe d'autres méthodes de contrôle d'accès, telles que le contrôle du timing des appels et le mécanisme de multi-signature, qui seront présentées dans des articles ultérieurs.