Journal de développement de contrats intelligents en Rust (7) Sécurité des contrats : contrôle des accès
Cet article présentera le contrôle d'accès dans les smart contracts Rust sous deux angles :
Visibilité des méthodes (fonctions) d'accès/appel des contrats
Contrôle d'accès des fonctions privilégiées/Division des responsabilités
1. Visibilité des fonctions (méthodes) de contrat
Lors de la rédaction de smart contracts, en spécifiant la visibilité des fonctions du contrat, il est possible de contrôler les droits d'appel des fonctions, protégeant ainsi les parties clés du contrat contre un accès ou une manipulation non autorisés.
Prenons l'exemple de l'échange Bancor Network, le 18 juin 2020, cet échange a connu un événement de sécurité des actifs dû à une erreur de configuration des droits d'accès des fonctions clés du contrat. Ce contrat est écrit en langage Solidity, la visibilité des fonctions du contrat est divisée en deux types : public/external et private/internal. Le premier permet aux fonctions du contrat d'être appelées par des appelants externes.
Lors de la modification d'une vulnérabilité de sécurité, par négligence, certaines fonctions de transfert clés du contrat ont été définies comme des attributs publics, permettant à quiconque d'appeler ces fonctions depuis l'extérieur du contrat pour effectuer des opérations de transfert, mettant en grave danger les actifs de 590 000 $ des utilisateurs.
Dans les smart contracts Rust, il est également essentiel de prêter attention au contrôle de la visibilité des fonctions de contrat. Les fonctions de smart contract Rust annotées avec le macro #[near_bindgen] défini par le NEAR SDK possèdent les différentes propriétés de visibilité suivantes :
pub fn: indique que cette méthode est publique, fait partie de l'interface du contrat et peut être appelée depuis l'extérieur du contrat.
fn: Si pub n'est pas explicitement indiqué, cela signifie qu'il ne peut pas être appelé directement depuis l'extérieur du contrat, mais uniquement à l'intérieur du contrat par d'autres fonctions.
pub(crate) fn: équivalent à pub(dans crate), limite l'appel des méthodes à l'intérieur de la portée du crate.
Une autre façon de définir la méthode de contrat comme interne est de définir un bloc de code impl Contract indépendant dans le contrat, cette implémentation n'est pas annotée avec #[near_bindgen].
Pour la fonction de rappel (Callbacks), sa définition doit être définie comme une propriété publique, mais il est nécessaire de s'assurer qu'elle ne peut être appelée que par le contrat lui-même. Le SDK NEAR fournit le macro #[private] pour réaliser cette fonctionnalité.
Il est important de noter que dans le langage Rust, par défaut, tout est privé, à l'exception des sous-éléments dans pub Trait et des variables Enum dans pub Enum qui sont par défaut publiques.
2. Contrôle d'accès des fonctions privilégiées(Mécanisme de liste blanche)
En plus du contrôle 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 au niveau sémantique du contrat. Certaines fonctions privilégiées ( telles que l'initialisation du contrat, l'activation/désactivation, les transferts unifiés, etc. ) ne peuvent être appelées que par le propriétaire du contrat ( owner ), ces fonctions sont généralement appelées "only owner" fonctions.
Bien que ces fonctions clés doivent être définies comme des attributs publics, il est possible de définir des règles de contrôle d'accès, qui doivent être satisfaites pour qu'elles puissent être exécutées complètement. Dans les smart contracts Rust, il est possible de mettre en œuvre un Trait personnalisé similaire au modificateur onlyOwner dans Solidity:
L'utilisation de ce trait permet de mettre en œuvre un contrôle d'accès aux fonctions privilégiées dans le contrat, exigeant que l'appelant soit le propriétaire du contrat. Sur la base de ce principe, il est possible de définir des modificateurs ou des traits plus complexes personnalisés pour établir plusieurs utilisateurs dans une liste blanche, ou de définir plusieurs listes blanches afin de réaliser un contrôle d'accès en groupe plus 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-signature des fonctions de smart contracts
Gouvernance(DAO) de réalisation
Ces contenus seront présentés dans les articles suivants de ce journal de développement des smart contracts.
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.
10 J'aime
Récompense
10
6
Partager
Commentaire
0/400
CompoundPersonality
· Il y a 19h
Il faut encore jouer au chat et à la souris avec les permissions.
Voir l'originalRépondre0
MEVSupportGroup
· Il y a 19h
Erreur de permission, je suis dans le pétrin. On se regroupe pour se réchauffer.
Voir l'originalRépondre0
MetaMaximalist
· Il y a 19h
ugh, une autre erreur de rookie au niveau de bancor... c'est pourquoi nous avons besoin de vérification formelle pour tous les déploiements de protocole tbh
Voir l'originalRépondre0
TokenomicsTherapist
· Il y a 19h
Eh, ne me parle pas de Bancor, je m'en souviens, à l'époque c'était un vrai désastre.
Voir l'originalRépondre0
TokenEconomist
· Il y a 19h
laisse-moi expliquer - le contrôle d'accès est littéralement l'abc de la sécurité des contrats smh
Voir l'originalRépondre0
Layer2Arbitrageur
· Il y a 19h
mdr imaginez écrire des contrats rust sans contrôle d'accès approprié... ngmi pour de vrai
Sécurité des smart contracts Rust : Guide complet sur le contrôle des permissions
Journal de développement de contrats intelligents en Rust (7) Sécurité des contrats : contrôle des accès
Cet article présentera le contrôle d'accès dans les smart contracts Rust sous deux angles :
1. Visibilité des fonctions (méthodes) de contrat
Lors de la rédaction de smart contracts, en spécifiant la visibilité des fonctions du contrat, il est possible de contrôler les droits d'appel des fonctions, protégeant ainsi les parties clés du contrat contre un accès ou une manipulation non autorisés.
Prenons l'exemple de l'échange Bancor Network, le 18 juin 2020, cet échange a connu un événement de sécurité des actifs dû à une erreur de configuration des droits d'accès des fonctions clés du contrat. Ce contrat est écrit en langage Solidity, la visibilité des fonctions du contrat est divisée en deux types : public/external et private/internal. Le premier permet aux fonctions du contrat d'être appelées par des appelants externes.
Lors de la modification d'une vulnérabilité de sécurité, par négligence, certaines fonctions de transfert clés du contrat ont été définies comme des attributs publics, permettant à quiconque d'appeler ces fonctions depuis l'extérieur du contrat pour effectuer des opérations de transfert, mettant en grave danger les actifs de 590 000 $ des utilisateurs.
Dans les smart contracts Rust, il est également essentiel de prêter attention au contrôle de la visibilité des fonctions de contrat. Les fonctions de smart contract Rust annotées avec le macro #[near_bindgen] défini par le NEAR SDK possèdent les différentes propriétés de visibilité suivantes :
Une autre façon de définir la méthode de contrat comme interne est de définir un bloc de code impl Contract indépendant dans le contrat, cette implémentation n'est pas annotée avec #[near_bindgen].
Pour la fonction de rappel (Callbacks), sa définition doit être définie comme une propriété publique, mais il est nécessaire de s'assurer qu'elle ne peut être appelée que par le contrat lui-même. Le SDK NEAR fournit le macro #[private] pour réaliser cette fonctionnalité.
Il est important de noter que dans le langage Rust, par défaut, tout est privé, à l'exception des sous-éléments dans pub Trait et des variables Enum dans pub Enum qui sont par défaut publiques.
2. Contrôle d'accès des fonctions privilégiées(Mécanisme de liste blanche)
En plus du contrôle 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 au niveau sémantique du contrat. Certaines fonctions privilégiées ( telles que l'initialisation du contrat, l'activation/désactivation, les transferts unifiés, etc. ) ne peuvent être appelées que par le propriétaire du contrat ( owner ), ces fonctions sont généralement appelées "only owner" fonctions.
Bien que ces fonctions clés doivent être définies comme des attributs publics, il est possible de définir des règles de contrôle d'accès, qui doivent être satisfaites pour qu'elles puissent être exécutées complètement. Dans les smart contracts Rust, il est possible de mettre en œuvre un Trait personnalisé 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); }
L'utilisation de ce trait permet de mettre en œuvre un contrôle d'accès aux fonctions privilégiées dans le contrat, exigeant que l'appelant soit le propriétaire du contrat. Sur la base de ce principe, il est possible de définir des modificateurs ou des traits plus complexes personnalisés pour établir plusieurs utilisateurs dans une liste blanche, ou de définir plusieurs listes blanches afin de réaliser un contrôle d'accès en groupe plus 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 :
Ces contenus seront présentés dans les articles suivants de ce journal de développement des smart contracts.