Journal de développement des contrats intelligents Rust (7) Sécurité des contrats : contrôle d'accès
Cet article présentera le contrôle des autorisations dans les contrats intelligents Rust sous deux aspects :
Visibilité des méthodes contractuelles
Contrôle d'accès des fonctions privilèges
1. Visibilité de la fonction de contrat
Il est essentiel de configurer correctement la visibilité des fonctions des contrats pour protéger la sécurité des contrats. Prenons l'exemple de l'incident de la bourse Bancor Network en juin 2020, où la définition erronée de la fonction de transfert clé en tant que publique a mis en péril les actifs des utilisateurs.
Dans les smart contracts Rust, la visibilité des fonctions se décline principalement en plusieurs types :
pub fn: fonction publique, peut être appelée depuis l'extérieur du contrat
fn: fonction interne par défaut, ne peut être appelée que à l'intérieur du contrat
pub(crate) fn: limiter les appels à l'intérieur de crate
De plus, les méthodes définies dans les blocs impl qui ne sont pas décorés avec #[near_bindgen] sont internes.
Pour les fonctions de rappel, elles doivent être définies comme publiques mais doivent également faire l'objet d'une vérification de l'appelant, ce qui peut être réalisé en utilisant le macro #[private].
Il convient de noter que tout dans Rust est privé par défaut, à l’exception des éléments dans pub trait et pub enum.
2. Contrôle d'accès des fonctions privilèges
En plus de définir la visibilité des fonctions, il est nécessaire de mettre en place un mécanisme de liste blanche de contrôle d'accès. Semblable au modificateur onlyOwner dans Solidity, il est possible de définir des fonctions privilégiées qui ne peuvent être appelées que par le propriétaire.
Dans Rust, cela peut être réalisé en définissant des traits personnalisés:
Cela permet de réaliser un contrôle d'accès de base pour le propriétaire. Cela peut être étendu à une liste blanche multi-utilisateurs ou à plusieurs listes blanches, permettant un contrôle d'accès plus précis.
!
!
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.
17 J'aime
Récompense
17
6
Partager
Commentaire
0/400
ser_we_are_ngmi
· Il y a 2h
C'est difficile à comprendre, je m'en vais.
Voir l'originalRépondre0
NFT_Therapy
· 07-17 01:06
Le contrôle d'accès est nécessaire ! Sinon, le contrat pourrait être exploité et ce serait la fin.
Voir l'originalRépondre0
PonziDetector
· 07-17 01:05
Rust yyds le plus dur
Voir l'originalRépondre0
MetaMuskRat
· 07-17 01:02
Encore un avec des droits d'administration, je me sauve, je me sauve.
Voir l'originalRépondre0
ser_we_are_early
· 07-17 00:46
Simple et brutal, c'est juste ajouter un contrôle d'accès.
Voir l'originalRépondre0
MemeEchoer
· 07-17 00:40
En regardant, on devient fatigué. Est-ce que quelqu'un a vraiment étudié ?
Sécurité des smart contracts Rust : explication du contrôle d'accès et de la visibilité des fonctions
Journal de développement des contrats intelligents Rust (7) Sécurité des contrats : contrôle d'accès
Cet article présentera le contrôle des autorisations dans les contrats intelligents Rust sous deux aspects :
1. Visibilité de la fonction de contrat
Il est essentiel de configurer correctement la visibilité des fonctions des contrats pour protéger la sécurité des contrats. Prenons l'exemple de l'incident de la bourse Bancor Network en juin 2020, où la définition erronée de la fonction de transfert clé en tant que publique a mis en péril les actifs des utilisateurs.
Dans les smart contracts Rust, la visibilité des fonctions se décline principalement en plusieurs types :
De plus, les méthodes définies dans les blocs impl qui ne sont pas décorés avec #[near_bindgen] sont internes.
Pour les fonctions de rappel, elles doivent être définies comme publiques mais doivent également faire l'objet d'une vérification de l'appelant, ce qui peut être réalisé en utilisant le macro #[private].
Il convient de noter que tout dans Rust est privé par défaut, à l’exception des éléments dans pub trait et pub enum.
2. Contrôle d'accès des fonctions privilèges
En plus de définir la visibilité des fonctions, il est nécessaire de mettre en place un mécanisme de liste blanche de contrôle d'accès. Semblable au modificateur onlyOwner dans Solidity, il est possible de définir des fonctions privilégiées qui ne peuvent être appelées que par le propriétaire.
Dans Rust, cela peut être réalisé en définissant des traits personnalisés:
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 réaliser un contrôle d'accès de base pour le propriétaire. Cela peut être étendu à une liste blanche multi-utilisateurs ou à plusieurs listes blanches, permettant un contrôle d'accès plus précis.
!
!