Journal de développement de smart contracts Rust (7) Contrôle d'accès pour la sécurité des contrats
Cet article présentera le contrôle d'accès dans les smart contracts Rust sous deux aspects :
Visibilité des méthodes (fonctions) d'accès/appel des contrats
Contrôle d'accès des fonctions privilégiées / Répartition des droits et 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, on peut contrôler les droits d'appel des fonctions, protégeant ainsi les parties clés du contrat contre un accès ou une manipulation accidentels.
Prenons l'exemple de l'échange Bancor Network, un incident de sécurité a eu lieu le 18 juin 2020 en raison d'une mauvaise configuration des droits d'accès aux fonctions clés du contrat. Ce contrat a été écrit en langage Solidity, et la visibilité des fonctions du contrat est divisée en public/external et private/internal. La première permet aux fonctions du contrat d'être appelées par des appelants externes, et peut être considérée comme une partie de l'interface du contrat.
Lors de la correction d'une vulnérabilité de sécurité, le réseau Bancor a par inadvertance défini certaines fonctions de transfert clés dans le contrat comme étant publiques, permettant ainsi à quiconque d'appeler ces fonctions depuis l'extérieur du contrat pour effectuer des opérations de transfert. Cette vulnérabilité expose les actifs de 590 000 $ des utilisateurs à un risque grave.
Dans les smart contracts Rust, il est également essentiel de prêter attention au contrôle de la visibilité des fonctions du contrat. Le macro #[near_bindgen] défini par le NEAR SDK peut être utilisé pour modifier les fonctions des smart contracts Rust, et il existe les différentes propriétés de visibilité suivantes :
pub fn: indique que cette méthode de contrat est publique, faisant partie de l'interface du contrat, et que tout le monde peut l'appeler depuis l'extérieur du contrat.
fn : Si pub n'est pas explicitement indiqué, cela signifie qu'il n'est pas possible d'appeler cette fonction directement depuis l'extérieur du contrat, elle ne peut être appelée que par d'autres fonctions à l'intérieur du contrat.
pub(crate) fn: équivalent à pub(dans crate), similaire à fn, limite l'appel des méthodes de contrat à l'intérieur de l'intervalle de 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'étant pas annotée avec #[near_bindgen].
Pour les fonctions de rappel (Callbacks), leur définition doit être définie comme une propriété publique, mais il faut également s'assurer qu'elles ne peuvent être appelées que par le contrat lui-même. Le SDK NEAR fournit le macro #[private] pour réaliser cette fonctionnalité.
Il convient de noter que dans le langage Rust, par défaut, tout est privé, sauf les sous-projets dans les traits pub et les variables Enum dans les énumérations pub qui sont par défaut publiques.
2. Contrôle d'accès aux fonctions privilégiées (mécanisme de liste blanche)
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 au niveau sémantique des contrats. Certaines fonctions privilégiées, telles que l'initialisation du contrat, l'activation/désactivation, les transferts unifiés, ne peuvent généralement être appelées que par le propriétaire du contrat (owner).
Ces fonctions privilégiées doivent être définies comme des attributs publics pour pouvoir être appelées de l'extérieur, mais il est également nécessaire de définir des règles de contrôle d'accès pour s'assurer que seuls les utilisateurs remplissant les conditions peuvent les exécuter complètement.
Dans les smart contracts Rust, il est possible de réaliser une fonctionnalité similaire aux modifiers de Solidity en utilisant des Traits personnalisés pour contrôler l'accès aux fonctions privilégiées :
L'utilisation de ce trait permet de réaliser un contrôle d'accès aux fonctions priviligiées dans le contrat, exigeant que l'appelant de la transaction soit le propriétaire du contrat. Sur cette base, il est possible de créer des modificateurs ou des traits plus complexes pour configurer plusieurs utilisateurs ou plusieurs listes blanches, permettant ainsi un contrôle d'accès en groupe plus précis.
3. Méthodes de contrôle d'accès supplémentaires
En plus des méthodes mentionnées ci-dessus, il existe d'autres méthodes de contrôle d'accès dans les smart contracts Rust, telles que le contrôle du moment d'appel des contrats, le mécanisme d'appel mult-signature des fonctions de contrat, et la mise en œuvre de la gouvernance (DAO), etc. Ces sujets seront traités en détail dans les prochains articles de ce journal de formation aux 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.
14 J'aime
Récompense
14
3
Partager
Commentaire
0/400
Rugpull幸存者
· Il y a 12h
Cette vague est encore un nouvel eyewash de l'Allowlist, n'est-ce pas ?
Voir l'originalRépondre0
RektHunter
· Il y a 12h
Débutant rust à ne pas manquer ! Fiable ~
Voir l'originalRépondre0
MetaLord420
· Il y a 12h
Salut, même l'Allowlist peut être piratée, d'accord~
Sécurité des smart contracts Rust : meilleures pratiques pour la visibilité des fonctions et le contrôle des permissions
Journal de développement de smart contracts Rust (7) Contrôle d'accès pour la sécurité des contrats
Cet article présentera le contrôle d'accès dans les smart contracts Rust sous deux aspects :
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, on peut contrôler les droits d'appel des fonctions, protégeant ainsi les parties clés du contrat contre un accès ou une manipulation accidentels.
Prenons l'exemple de l'échange Bancor Network, un incident de sécurité a eu lieu le 18 juin 2020 en raison d'une mauvaise configuration des droits d'accès aux fonctions clés du contrat. Ce contrat a été écrit en langage Solidity, et la visibilité des fonctions du contrat est divisée en public/external et private/internal. La première permet aux fonctions du contrat d'être appelées par des appelants externes, et peut être considérée comme une partie de l'interface du contrat.
Lors de la correction d'une vulnérabilité de sécurité, le réseau Bancor a par inadvertance défini certaines fonctions de transfert clés dans le contrat comme étant publiques, permettant ainsi à quiconque d'appeler ces fonctions depuis l'extérieur du contrat pour effectuer des opérations de transfert. Cette vulnérabilité expose les actifs de 590 000 $ des utilisateurs à un risque grave.
Dans les smart contracts Rust, il est également essentiel de prêter attention au contrôle de la visibilité des fonctions du contrat. Le macro #[near_bindgen] défini par le NEAR SDK peut être utilisé pour modifier les fonctions des smart contracts Rust, et il existe 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'étant pas annotée avec #[near_bindgen].
Pour les fonctions de rappel (Callbacks), leur définition doit être définie comme une propriété publique, mais il faut également s'assurer qu'elles ne peuvent être appelées que par le contrat lui-même. Le SDK NEAR fournit le macro #[private] pour réaliser cette fonctionnalité.
Il convient de noter que dans le langage Rust, par défaut, tout est privé, sauf les sous-projets dans les traits pub et les variables Enum dans les énumérations pub qui sont par défaut publiques.
2. Contrôle d'accès aux fonctions privilégiées (mécanisme de liste blanche)
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 au niveau sémantique des contrats. Certaines fonctions privilégiées, telles que l'initialisation du contrat, l'activation/désactivation, les transferts unifiés, ne peuvent généralement être appelées que par le propriétaire du contrat (owner).
Ces fonctions privilégiées doivent être définies comme des attributs publics pour pouvoir être appelées de l'extérieur, mais il est également nécessaire de définir des règles de contrôle d'accès pour s'assurer que seuls les utilisateurs remplissant les conditions peuvent les exécuter complètement.
Dans les smart contracts Rust, il est possible de réaliser une fonctionnalité similaire aux modifiers de Solidity en utilisant 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); }
L'utilisation de ce trait permet de réaliser un contrôle d'accès aux fonctions priviligiées dans le contrat, exigeant que l'appelant de la transaction soit le propriétaire du contrat. Sur cette base, il est possible de créer des modificateurs ou des traits plus complexes pour configurer plusieurs utilisateurs ou plusieurs listes blanches, permettant ainsi un contrôle d'accès en groupe plus précis.
3. Méthodes de contrôle d'accès supplémentaires
En plus des méthodes mentionnées ci-dessus, il existe d'autres méthodes de contrôle d'accès dans les smart contracts Rust, telles que le contrôle du moment d'appel des contrats, le mécanisme d'appel mult-signature des fonctions de contrat, et la mise en œuvre de la gouvernance (DAO), etc. Ces sujets seront traités en détail dans les prochains articles de ce journal de formation aux smart contracts.