Cet article présentera le contrôle des permissions dans les smart contracts Rust sous deux angles :
La visibilité des méthodes de contrat
Contrôle d'accès des fonctions privilégiées
1. Visibilité des fonctions de contrat
Dans le développement de smart contracts, il est crucial de définir correctement la visibilité des fonctions. Prenons l'exemple de l'incident de sécurité de l'échange Bancor Network du 18 juin 2020, où le fait de définir incorrectement une fonction de transfert clé comme publique a exposé les actifs des utilisateurs à des risques.
Dans les smart contracts Rust, le contrôle de la visibilité des fonctions est tout aussi important. Le macro #[near_bindgen] dans le SDK NEAR définit les différentes visibilités suivantes :
pub fn: fonction publique, appelable depuis l'extérieur du contrat
fn: ne peut être appelé que dans le contrat
pub(crate) fn: limiter les appels à l'intérieur de crate
Une autre façon de définir la méthode interne est de définir un bloc de code impl Contract séparé, sans utiliser le modificateur #[near_bindgen].
Pour les fonctions de rappel, elles doivent être définies comme publiques tout en étant limitées à des appels uniquement par le contrat lui-même. Vous pouvez utiliser le macro #[private] pour atteindre cet objectif.
Il est important de noter que, par défaut, tout dans Rust est privé, à l'exception des éléments dans pub Trait et pub Enum.
2. Contrôle d'accès des fonctions privilégiées
En plus de la visibilité des fonctions, il est également nécessaire d'établir un mécanisme complet de liste blanche de contrôle d'accès. Tout comme le modificateur onlyOwner dans Solidity, les contrats Rust peuvent également implémenter des Traits personnalisés pour contrôler l'accès aux fonctions privilégiées :
Cela peut limiter l'accès à certaines fonctions privilégiées uniquement au propriétaire. Sur la base de ce principe, il est possible de définir des listes blanches et des contrôles d'accès par groupe plus complexes.
3. Autres méthodes de contrôle d'accès
Il existe également d'autres méthodes de contrôle d'accès, telles que le contrôle du moment de l'appel de contrat, le mécanisme d'appel multi-signatures, la mise en œuvre de DAO, etc., qui seront détaillées dans les prochains articles.
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.
17 J'aime
Récompense
17
4
Reposter
Partager
Commentaire
0/400
MetaNomad
· 08-04 05:07
rust débutant demande lequel est le plus sûr ?
Voir l'originalRépondre0
NftPhilanthropist
· 08-04 05:02
*sigh* encore un autre problème de sécurité parce que quelqu'un a oublié les permissions de base... quand les développeurs apprendront-ils à mint de manière réfléchie smh
Voir l'originalRépondre0
BearMarketGardener
· 08-04 04:57
La gestion des autorisations va mal et ce sera la fin.
Voir l'originalRépondre0
RuntimeError
· 08-04 04:45
Contrôle des autorisations non conforme, venez déboguer à genoux.
Contrôle d'accès des smart contracts Rust : visibilité des fonctions et gestion des accès privilégiés
Contrôle d'accès dans les smart contracts Rust
Cet article présentera le contrôle des permissions dans les smart contracts Rust sous deux angles :
1. Visibilité des fonctions de contrat
Dans le développement de smart contracts, il est crucial de définir correctement la visibilité des fonctions. Prenons l'exemple de l'incident de sécurité de l'échange Bancor Network du 18 juin 2020, où le fait de définir incorrectement une fonction de transfert clé comme publique a exposé les actifs des utilisateurs à des risques.
Dans les smart contracts Rust, le contrôle de la visibilité des fonctions est tout aussi important. Le macro #[near_bindgen] dans le SDK NEAR définit les différentes visibilités suivantes :
Une autre façon de définir la méthode interne est de définir un bloc de code impl Contract séparé, sans utiliser le modificateur #[near_bindgen].
Pour les fonctions de rappel, elles doivent être définies comme publiques tout en étant limitées à des appels uniquement par le contrat lui-même. Vous pouvez utiliser le macro #[private] pour atteindre cet objectif.
Il est important de noter que, par défaut, tout dans Rust est privé, à l'exception des éléments dans pub Trait et pub Enum.
2. Contrôle d'accès des fonctions privilégiées
En plus de la visibilité des fonctions, il est également nécessaire d'établir un mécanisme complet de liste blanche de contrôle d'accès. Tout comme le modificateur onlyOwner dans Solidity, les contrats Rust peuvent également implémenter des Traits personnalisés pour contrôler l'accès aux fonctions privilégiées :
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 la base de ce principe, il est possible de définir des listes blanches et des contrôles d'accès par groupe plus complexes.
3. Autres méthodes de contrôle d'accès
Il existe également d'autres méthodes de contrôle d'accès, telles que le contrôle du moment de l'appel de contrat, le mécanisme d'appel multi-signatures, la mise en œuvre de DAO, etc., qui seront détaillées dans les prochains articles.