Journal de développement de contrats intelligents en Rust (7) Sécurité des contrats : précision des calculs
Cet article présentera le contrôle d'accès dans les smart contracts Rust sous deux aspects :
Visibilité d'accès/appel des méthodes de contrat
Contrôle d'accès des fonctions privilégiées / Répartition des responsabilités
1. Visibilité des fonctions des contrats
La visibilité des fonctions de contrat peut contrôler les droits d'appel des fonctions, protégeant ainsi les parties critiques contre les accès non autorisés. Prenons l'exemple de l'échange Bancor Network, où un événement de sécurité des actifs a eu lieu en juin 2020 en raison d'une mauvaise configuration de la visibilité des fonctions clés.
Dans les smart contracts Rust, la visibilité des fonctions est contrôlée de la manière suivante :
pub fn : fonction publique, pouvant être appelée depuis l'extérieur du contrat
fn: fonction interne, ne peut être appelée que dans le contrat
pub(crate) fn: limiter les appels à l'intérieur de crate
Une autre façon de définir des méthodes internes est de définir des blocs de code impl Contract indépendants, sans utiliser le modificateur #[near_bindgen].
La fonction de rappel doit être définie comme publique, mais il faut s'assurer qu'elle ne peut être appelée que par le contrat lui-même. Vous pouvez utiliser la macro #[private] pour cela.
Rust par défaut rend tout privé, mais les éléments dans les traits et les énumérations sont publics par défaut.
2. Contrôle d'accès des fonctions privilégiées
En plus de définir la visibilité des fonctions, il est également nécessaire d'établir un mécanisme de liste blanche de contrôle d'accès. Semblable au modificateur onlyOwner dans Solidity, on peut définir des fonctions privilèges qui ne peuvent être appelées que par le propriétaire.
Dans Rust, il est possible d'implémenter un trait Ownable similaire:
Cela permet de mettre en place un contrôle d'accès aux fonctions privilégiées. Il est possible d'étendre davantage en configurant plusieurs listes blanches d'utilisateurs ou plusieurs groupes de listes blanches.
3. Autres méthodes de contrôle d'accès
Il est également possible de réaliser :
Contrôle du timing des appels de smart contracts
Mécanisme d'appel multi-signatures des fonctions de contrat
Gouvernance ( DAO ) mécanisme
Veuillez suivre les prochaines publications pour plus de détails.
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.
20 J'aime
Récompense
20
4
Reposter
Partager
Commentaire
0/400
EthMaximalist
· 08-14 01:11
Ah ah, n'est-ce pas le bug qui a fait chavirer Bancor à l'époque ?
Voir l'originalRépondre0
HalfBuddhaMoney
· 08-12 19:17
Wuhu, c'est encore l'heure d'écrire des bugs.
Voir l'originalRépondre0
GhostAddressMiner
· 08-12 19:17
Cette faille de contrat est vraiment trop basique, j'ai suivi 276 Portefeuilles de Hacker sans y penser, j'avais déjà remarqué que le flux de fonds de bancor avait quelque chose de suspect.
Voir l'originalRépondre0
CoconutWaterBoy
· 08-12 18:50
J'ai travaillé sur des contrats depuis des années, et j'ai aussi échoué de nombreuses fois avec pub fn.
Pratiques de sécurité des smart contracts en Rust : explication détaillée de la visibilité des fonctions et du contrôle des accès
Journal de développement de contrats intelligents en Rust (7) Sécurité des contrats : précision des calculs
Cet article présentera le contrôle d'accès dans les smart contracts Rust sous deux aspects :
1. Visibilité des fonctions des contrats
La visibilité des fonctions de contrat peut contrôler les droits d'appel des fonctions, protégeant ainsi les parties critiques contre les accès non autorisés. Prenons l'exemple de l'échange Bancor Network, où un événement de sécurité des actifs a eu lieu en juin 2020 en raison d'une mauvaise configuration de la visibilité des fonctions clés.
Dans les smart contracts Rust, la visibilité des fonctions est contrôlée de la manière suivante :
Une autre façon de définir des méthodes internes est de définir des blocs de code impl Contract indépendants, sans utiliser le modificateur #[near_bindgen].
La fonction de rappel doit être définie comme publique, mais il faut s'assurer qu'elle ne peut être appelée que par le contrat lui-même. Vous pouvez utiliser la macro #[private] pour cela.
Rust par défaut rend tout privé, mais les éléments dans les traits et les énumérations sont publics par défaut.
2. Contrôle d'accès des fonctions privilégiées
En plus de définir la visibilité des fonctions, il est également nécessaire d'établir un mécanisme de liste blanche de contrôle d'accès. Semblable au modificateur onlyOwner dans Solidity, on peut définir des fonctions privilèges qui ne peuvent être appelées que par le propriétaire.
Dans Rust, il est possible d'implémenter un trait Ownable similaire:
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 mettre en place un contrôle d'accès aux fonctions privilégiées. Il est possible d'étendre davantage en configurant plusieurs listes blanches d'utilisateurs ou plusieurs groupes de listes blanches.
3. Autres méthodes de contrôle d'accès
Il est également possible de réaliser :
Veuillez suivre les prochaines publications pour plus de détails.