Diario de desarrollo de contratos inteligentes en Rust (7) Control de acceso en la seguridad de contratos
Este artículo presentará el control de permisos en los contratos inteligentes de Rust desde dos perspectivas:
Visibilidad de acceso/llamada a los métodos (funciones) de contratos inteligentes
Control de acceso a funciones privilegiadas / División de responsabilidades
1. Visibilidad de las funciones (métodos) de los contratos
Al escribir contratos inteligentes, se puede controlar el acceso a las funciones del contrato especificando la visibilidad de las funciones, protegiendo así las partes clave del contrato de accesos o manipulaciones accidentales.
Tomando como ejemplo el intercambio Bancor Network, este intercambio sufrió un incidente de seguridad de activos el 18 de junio de 2020 debido a un error en la configuración de los permisos de acceso a las funciones clave del contrato. Este contrato fue escrito en el lenguaje Solidity, y la visibilidad de las funciones del contrato se divide en dos tipos: public/external y private/internal. El primero permite que las funciones del contrato sean llamadas por llamadores externos, y se puede considerar como parte de la interfaz del contrato.
Durante la modificación de una vulnerabilidad de seguridad, Bancor Network configuró por error algunas funciones clave de transferencia en el contrato como públicas, lo que permitió a cualquier persona llamar a estas funciones desde el exterior del contrato para realizar operaciones de transferencia. Esta vulnerabilidad crítica puso en grave riesgo los activos de 590,000 dólares de sus usuarios.
En los contratos inteligentes de Rust, también es importante prestar atención al control de visibilidad de las funciones del contrato. El macro #[near_bindgen] definido por NEAR SDK se puede usar para modificar las funciones de los contratos inteligentes de Rust, y existen las siguientes diferentes propiedades de visibilidad:
pub fn: indica que este método es público, forma parte de la interfaz del contrato y puede ser llamado externamente.
fn: No se indica explícitamente pub, lo que significa que no se puede llamar directamente desde fuera del contrato, solo se puede llamar desde dentro del contrato.
pub(crate) fn: Restringir el método para que se llame dentro del ámbito del crate.
Otra forma de establecer el método del contrato como interno es definir un bloque de código impl Contract independiente que no esté decorado con #[near_bindgen] en el contrato.
Para la función de devolución de llamada (Callbacks), debe definirse como una propiedad pública para poder ser llamada a través de function call. Al mismo tiempo, debe asegurarse de que la función de devolución de llamada no pueda ser llamada libremente por otros, es decir, el llamador debe ser el propio contrato. NEAR SDK proporciona el macro #[private] para implementar esta funcionalidad.
Es importante tener en cuenta que en el lenguaje Rust, por defecto, todo es privado, excepto los subelementos en pub Trait y las variables Enum en pub Enum que son públicas por defecto.
2. Control de acceso a las funciones privilegiadas ( mecanismo de lista blanca )
Además de la visibilidad de las funciones, también es necesario establecer un mecanismo completo de lista blanca de control de acceso desde el nivel semántico del contrato. Algunas funciones privilegiadas (, como la inicialización del contrato, activar/desactivar, transferencias unificadas, etc., ) solo pueden ser llamadas por el propietario del contrato ( owner ), y estas funciones suelen conocerse como funciones "solo propietario".
Aunque estas funciones clave deben configurarse como propiedades públicas para ser llamadas externamente, se pueden definir reglas de control de acceso para que solo se completen si se cumplen las reglas correspondientes. Por ejemplo, se puede implementar el siguiente Trait personalizado:
El uso de este trait permite implementar el control de acceso a las funciones privilegiadas en el contrato, exigiendo que el llamador sea el propietario del contrato. Basado en este principio, se pueden personalizar modificadores o traits más complejos para establecer múltiples usuarios o múltiples listas blancas, logrando un control de acceso grupal más detallado.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
9 me gusta
Recompensa
9
6
Compartir
Comentar
0/400
ContractTester
· hace7h
Otra vez se estrelló Solidity, Rust es el número uno en el mundo
Ver originalesResponder0
ApeEscapeArtist
· hace8h
Rust, una lección de dolor y lágrimas
Ver originalesResponder0
AllTalkLongTrader
· hace8h
¿Por qué la gestión de permisos sigue siendo tan complicada?
Ver originalesResponder0
defi_detective
· hace8h
Este bug de Bancor es realmente bastante básico, ni siquiera quiero hablar de ello.
Ver originalesResponder0
GasWastingMaximalist
· hace8h
He pisado esta trampa de permisos, me ha dejado completamente destrozado.
Ver originalesResponder0
CryptoAdventurer
· hace9h
¿Otra vez hay un intercambio que se va a la quiebra? El control de riesgos siempre es una máquina de tomar a la gente por tonta~
Seguridad de contratos inteligentes en Rust: explicación detallada sobre el control de permisos y la gestión de accesos
Diario de desarrollo de contratos inteligentes en Rust (7) Control de acceso en la seguridad de contratos
Este artículo presentará el control de permisos en los contratos inteligentes de Rust desde dos perspectivas:
1. Visibilidad de las funciones (métodos) de los contratos
Al escribir contratos inteligentes, se puede controlar el acceso a las funciones del contrato especificando la visibilidad de las funciones, protegiendo así las partes clave del contrato de accesos o manipulaciones accidentales.
Tomando como ejemplo el intercambio Bancor Network, este intercambio sufrió un incidente de seguridad de activos el 18 de junio de 2020 debido a un error en la configuración de los permisos de acceso a las funciones clave del contrato. Este contrato fue escrito en el lenguaje Solidity, y la visibilidad de las funciones del contrato se divide en dos tipos: public/external y private/internal. El primero permite que las funciones del contrato sean llamadas por llamadores externos, y se puede considerar como parte de la interfaz del contrato.
Durante la modificación de una vulnerabilidad de seguridad, Bancor Network configuró por error algunas funciones clave de transferencia en el contrato como públicas, lo que permitió a cualquier persona llamar a estas funciones desde el exterior del contrato para realizar operaciones de transferencia. Esta vulnerabilidad crítica puso en grave riesgo los activos de 590,000 dólares de sus usuarios.
En los contratos inteligentes de Rust, también es importante prestar atención al control de visibilidad de las funciones del contrato. El macro #[near_bindgen] definido por NEAR SDK se puede usar para modificar las funciones de los contratos inteligentes de Rust, y existen las siguientes diferentes propiedades de visibilidad:
Otra forma de establecer el método del contrato como interno es definir un bloque de código impl Contract independiente que no esté decorado con #[near_bindgen] en el contrato.
Para la función de devolución de llamada (Callbacks), debe definirse como una propiedad pública para poder ser llamada a través de function call. Al mismo tiempo, debe asegurarse de que la función de devolución de llamada no pueda ser llamada libremente por otros, es decir, el llamador debe ser el propio contrato. NEAR SDK proporciona el macro #[private] para implementar esta funcionalidad.
Es importante tener en cuenta que en el lenguaje Rust, por defecto, todo es privado, excepto los subelementos en pub Trait y las variables Enum en pub Enum que son públicas por defecto.
2. Control de acceso a las funciones privilegiadas ( mecanismo de lista blanca )
Además de la visibilidad de las funciones, también es necesario establecer un mecanismo completo de lista blanca de control de acceso desde el nivel semántico del contrato. Algunas funciones privilegiadas (, como la inicialización del contrato, activar/desactivar, transferencias unificadas, etc., ) solo pueden ser llamadas por el propietario del contrato ( owner ), y estas funciones suelen conocerse como funciones "solo propietario".
Aunque estas funciones clave deben configurarse como propiedades públicas para ser llamadas externamente, se pueden definir reglas de control de acceso para que solo se completen si se cumplen las reglas correspondientes. Por ejemplo, se puede implementar el siguiente Trait personalizado:
óxido pub trait Ownable { fn assert_owner(&self) { assert_eq!(env::predecessor_account_id(), self.get_owner()); } AccountId; fn set_owner(&mut self, owner: AccountId); }
El uso de este trait permite implementar el control de acceso a las funciones privilegiadas en el contrato, exigiendo que el llamador sea el propietario del contrato. Basado en este principio, se pueden personalizar modificadores o traits más complejos para establecer múltiples usuarios o múltiples listas blancas, logrando un control de acceso grupal más detallado.