Journal de développement de contrats intelligents Rust (7) Contrôle des permissions en matière de sécurité des contrats
Cet article présentera les aspects du contrôle des permissions dans les smart contracts Rust sous deux angles :
Visibilité d'accès/appel des méthodes (fonctions) de contrat
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, la visibilité des fonctions de contrat peut être spécifiée pour contrôler les autorisations d'appel des fonctions, protégeant ainsi les parties clés du contrat contre tout accès ou manipulation accidentelle.
Prenons l'exemple de l'échange Bancor Network, qui a connu un incident de sécurité des actifs 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 se divise en deux types : public/external et private/internal. Le premier permet aux fonctions du contrat d'être appelées par des appelants externes, ce qui peut être considéré 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 erreur 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é critique a mis en grand danger les actifs de 590 000 $ de ses utilisateurs.
Dans les smart contracts Rust, il est également important 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 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 de l'extérieur.
fn : non spécifié explicitement pub, ce qui signifie qu'il ne peut pas être appelé directement depuis l'extérieur du contrat, mais uniquement à l'intérieur du contrat.
pub(crate) fn: limiter la méthode à être appelée dans l'espace interne de crate.
Une autre façon de définir la méthode du contrat comme interne est de définir un bloc de code impl Contract indépendant qui n'est pas annoté par #[near_bindgen] dans le contrat.
Pour le retour (Callbacks) fonction, il doit être défini comme une propriété publique pour pouvoir être appelé par function call. Il est également nécessaire de s'assurer que la fonction de rappel ne peut pas être appelée arbitrairement par d'autres, c'est-à-dire que l'appelant doit être 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, tout est par défaut privé, à l'exception des sous-projets dans les Traits publics et des variables Enum dans les Enum publics qui sont par défaut publics.
2. Contrôle d'accès des fonctions privilégiées( Mécanisme de liste blanche)
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 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 ), et ces fonctions sont généralement appelées fonctions "only owner".
Bien que ces fonctions clés doivent être définies comme des propriétés publiques pour être appelées de l'extérieur, il est possible de définir des règles de contrôle d'accès, qui doivent être respectées pour être exécutées complètement. Par exemple, il est possible de réaliser le Trait personnalisé suivant :
L'utilisation de ce trait permet de réaliser 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 pour établir plusieurs utilisateurs ou plusieurs listes blanches, permettant ainsi un contrôle d'accès granulaire.
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.
9 J'aime
Récompense
9
6
Partager
Commentaire
0/400
ContractTester
· Il y a 20h
Encore une fois, Solidity se plante, Rust est le meilleur au monde.
Voir l'originalRépondre0
ApeEscapeArtist
· Il y a 21h
Rust, quelle leçon de sang et de larmes.
Voir l'originalRépondre0
AllTalkLongTrader
· Il y a 21h
Pourquoi la gestion des permissions est-elle encore si complexe ?
Voir l'originalRépondre0
defi_detective
· Il y a 21h
Ce bug de Bancor est vraiment basique, je n'ai même pas envie d'en parler.
Voir l'originalRépondre0
GasWastingMaximalist
· Il y a 21h
J'ai déjà expérimenté ce piège de permission, ça m'a directement fissuré.
Voir l'originalRépondre0
CryptoAdventurer
· Il y a 22h
Encore un crash de plateforme d'échange ? La gestion des risques est toujours une machine à prendre les gens pour des idiots ~
Sécurité des smart contracts Rust : explication détaillée du contrôle des accès et de la gestion des permissions
Journal de développement de contrats intelligents Rust (7) Contrôle des permissions en matière de sécurité des contrats
Cet article présentera les aspects du contrôle des permissions dans les smart contracts Rust sous deux angles :
1. Visibilité des fonctions (méthodes) de contrat
Lors de la rédaction de smart contracts, la visibilité des fonctions de contrat peut être spécifiée pour contrôler les autorisations d'appel des fonctions, protégeant ainsi les parties clés du contrat contre tout accès ou manipulation accidentelle.
Prenons l'exemple de l'échange Bancor Network, qui a connu un incident de sécurité des actifs 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 se divise en deux types : public/external et private/internal. Le premier permet aux fonctions du contrat d'être appelées par des appelants externes, ce qui peut être considéré 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 erreur 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é critique a mis en grand danger les actifs de 590 000 $ de ses utilisateurs.
Dans les smart contracts Rust, il est également important 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 propriétés de visibilité suivantes :
Une autre façon de définir la méthode du contrat comme interne est de définir un bloc de code impl Contract indépendant qui n'est pas annoté par #[near_bindgen] dans le contrat.
Pour le retour (Callbacks) fonction, il doit être défini comme une propriété publique pour pouvoir être appelé par function call. Il est également nécessaire de s'assurer que la fonction de rappel ne peut pas être appelée arbitrairement par d'autres, c'est-à-dire que l'appelant doit être 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, tout est par défaut privé, à l'exception des sous-projets dans les Traits publics et des variables Enum dans les Enum publics qui sont par défaut publics.
2. Contrôle d'accès des fonctions privilégiées( Mécanisme de liste blanche)
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 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 ), et ces fonctions sont généralement appelées fonctions "only owner".
Bien que ces fonctions clés doivent être définies comme des propriétés publiques pour être appelées de l'extérieur, il est possible de définir des règles de contrôle d'accès, qui doivent être respectées pour être exécutées complètement. Par exemple, il est possible de réaliser le Trait personnalisé suivant :
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 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 pour établir plusieurs utilisateurs ou plusieurs listes blanches, permettant ainsi un contrôle d'accès granulaire.