Journal de développement de contrats intelligents Rust (7) Sécurité des contrats : contrôle des permissions
Cet article présentera le contrôle des accès dans les smart contracts Rust sous deux angles :
La visibilité des méthodes de contrat
Contrôle d'accès des fonctions privilèges
1. Visibilité des fonctions de contrat
Le contrôle de la visibilité des fonctions de contrat est essentiel pour protéger les fonctionnalités clés. Prenons l'exemple de l'incident de sécurité de l'échange Bancor Network en juin 2020, où la fonction de transfert critique a été incorrectement définie comme publique, mettant ainsi les actifs des utilisateurs en danger.
Dans les smart contracts Rust, il existe plusieurs types de visibilité des fonctions :
pub fn: fonction publique, pouvant être appelée de l'extérieur
fn: fonction interne, ne peut être appelée que dans le contrat
pub(crate) fn: restreindre l'appel à l'intérieur de crate
De plus, définir une fonction dans un bloc impl non annoté par #[near_bindgen] peut également en faire une fonction interne.
Pour la fonction de rappel, elle doit être définie comme publique mais en s'assurant qu'elle ne peut être appelée que par le contrat lui-même. Vous pouvez utiliser le macro #[private] pour réaliser cette fonctionnalité.
Il convient de noter que la visibilité par défaut dans Rust est privée, contrairement à la visibilité publique par défaut de certaines versions de Solidity. L'exception concerne les éléments dans les traits pub et les énumérations pub qui sont par défaut publics.
2. Contrôle d'accès des fonctions privilégiées
En plus de la visibilité des fonctions, un mécanisme de liste blanche doit être établi pour contrôler l'accès aux fonctions privilégiées. Similaire au modificateur onlyOwner dans Solidity, on peut réaliser un trait Ownable :
L'utilisation de ce trait peut restreindre l'accès à certaines fonctions privilégiées uniquement au propriétaire. Sur cette base, il est possible de mettre en place des listes blanches plus complexes pour réaliser un contrôle d'accès fin.
3. Autres méthodes de contrôle d'accès
Il est également possible de considérer des méthodes de contrôle d'accès supplémentaires telles que le contrôle du moment d'appel des contrats, le mécanisme d'appel multi-signatures et la gouvernance DAO, qui seront détaillées dans les articles suivants.
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.
10 J'aime
Récompense
10
10
Partager
Commentaire
0/400
Anon32942
· 07-14 23:24
Ce code est un peu difficile à mordre.
Voir l'originalRépondre0
GasFeeCrier
· 07-14 20:16
À quel point cette sécurité est-elle vraiment sécurisée ?
Voir l'originalRépondre0
MeaninglessApe
· 07-14 14:35
C'est aussi nécessaire de s'impliquer ? On a déjà écrit en Rust.
Voir l'originalRépondre0
LootboxPhobia
· 07-12 09:38
J'ai du mal à étudier les smart contracts.
Voir l'originalRépondre0
GasOptimizer
· 07-12 09:38
La visualisation de la consommation de gas pour les multisignatures est un autre grand sujet.
Voir l'originalRépondre0
BridgeJumper
· 07-12 09:37
Le code est-il sécurisé ? Il est toujours injecté.
Voir l'originalRépondre0
UncleLiquidation
· 07-12 09:37
La sécurité de la multi-signature est acceptable.
Voir l'originalRépondre0
UncleWhale
· 07-12 09:30
La sécurité doit être prise au sérieux.
Voir l'originalRépondre0
BankruptcyArtist
· 07-12 09:22
À quoi sert la multi-signature ? Il y a des failles et cela peut quand même être exploité.
Voir l'originalRépondre0
MEVSandwich
· 07-12 09:14
Bien joué ! Les signatures multiples semblent sécurisées ~
Rust smart contracts sécurité avancée : pratiques de contrôle des accès et de gestion des permissions
Journal de développement de contrats intelligents Rust (7) Sécurité des contrats : contrôle des permissions
Cet article présentera le contrôle des accès dans les smart contracts Rust sous deux angles :
1. Visibilité des fonctions de contrat
Le contrôle de la visibilité des fonctions de contrat est essentiel pour protéger les fonctionnalités clés. Prenons l'exemple de l'incident de sécurité de l'échange Bancor Network en juin 2020, où la fonction de transfert critique a été incorrectement définie comme publique, mettant ainsi les actifs des utilisateurs en danger.
Dans les smart contracts Rust, il existe plusieurs types de visibilité des fonctions :
De plus, définir une fonction dans un bloc impl non annoté par #[near_bindgen] peut également en faire une fonction interne.
Pour la fonction de rappel, elle doit être définie comme publique mais en s'assurant qu'elle ne peut être appelée que par le contrat lui-même. Vous pouvez utiliser le macro #[private] pour réaliser cette fonctionnalité.
Il convient de noter que la visibilité par défaut dans Rust est privée, contrairement à la visibilité publique par défaut de certaines versions de Solidity. L'exception concerne les éléments dans les traits pub et les énumérations pub qui sont par défaut publics.
2. Contrôle d'accès des fonctions privilégiées
En plus de la visibilité des fonctions, un mécanisme de liste blanche doit être établi pour contrôler l'accès aux fonctions privilégiées. Similaire au modificateur onlyOwner dans Solidity, on peut réaliser un trait Ownable :
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 peut restreindre l'accès à certaines fonctions privilégiées uniquement au propriétaire. Sur cette base, il est possible de mettre en place des listes blanches plus complexes pour réaliser un contrôle d'accès fin.
3. Autres méthodes de contrôle d'accès
Il est également possible de considérer des méthodes de contrôle d'accès supplémentaires telles que le contrôle du moment d'appel des contrats, le mécanisme d'appel multi-signatures et la gouvernance DAO, qui seront détaillées dans les articles suivants.