Análisis de las vulnerabilidades de seguridad comunes en Finanzas descentralizadas: prevención de Flash Loans, manipulación de precios y ataques de reentrada.
Finanzas descentralizadas Vulnerabilidades de seguridad comunes y medidas de prevención
Recientemente, un experto en seguridad compartió una clase de seguridad de Finanzas descentralizadas con los miembros de la comunidad. Revisó los importantes incidentes de seguridad que ha enfrentado la industria de Web3 en el último año y más, explorando las razones detrás de estos eventos y cómo evitarlos. Resumió las vulnerabilidades de seguridad comunes en los contratos inteligentes y las medidas de prevención, y también ofreció algunos consejos de seguridad para los equipos de proyectos y los usuarios comunes.
Los tipos comunes de vulnerabilidades en Finanzas descentralizadas incluyen préstamos relámpago, manipulación de precios, problemas de permisos de funciones, llamadas externas arbitrarias, problemas con la función fallback, vulnerabilidades de lógica de negocio, filtración de claves privadas, reentradas, entre otros. A continuación, se presentan en detalle los préstamos relámpago, la manipulación de precios y los ataques de reentrada.
Préstamo relámpago
El préstamo relámpago en sí es una innovación de las Finanzas descentralizadas, pero cuando es utilizado por hackers, pueden obtener grandes cantidades de dinero sin costo alguno, y tras ejecutar la arbitraje, solo necesitan devolverlo pagando una pequeña tarifa de Gas para obtener enormes beneficios.
En los últimos dos años, los problemas con los préstamos relámpago han sido frecuentes. Algunos proyectos parecen ofrecer altos rendimientos, pero en realidad la calidad de los desarrolladores varía. Incluso si el código en sí no tiene vulnerabilidades, puede haber problemas lógicos. Por ejemplo, hay proyectos que otorgan recompensas en momentos fijos según la cantidad de tokens que posee un tenedor, pero son aprovechados por atacantes que utilizan préstamos relámpago para comprar una gran cantidad de tokens y obtener la mayor parte de las recompensas cuando se distribuyen. También hay algunos proyectos que calculan precios a través de tokens, que pueden ser influenciados por préstamos relámpago. Los desarrolladores deberían estar más alerta ante estos problemas.
Manipulación de precios
El problema del control de precios está estrechamente relacionado con los préstamos relámpago, y hay principalmente dos tipos:
Se utilizan datos de terceros para calcular el precio, pero el uso incorrecto o la falta de verificación hacen que el precio sea manipulado maliciosamente.
Utilizar la cantidad de tokens de ciertas direcciones como variable de cálculo, y el saldo de tokens de estas direcciones puede ser temporalmente aumentado o disminuido.
Ataque de reentrada
Uno de los principales peligros de llamar a contratos externos es que pueden tomar el control del flujo de ejecución y realizar cambios inesperados en los datos al invocar funciones.
Existen muchas formas de reentrada para diferentes contratos, que pueden combinarse con diferentes funciones del contrato o funciones de varios contratos diferentes para llevar a cabo un ataque de reentrada, por lo que al abordar el problema de reentrada es necesario tener en cuenta:
No solo previene el problema de reentrada de una única función.
Seguir el patrón Checks-Effects-Interactions para codificación
Utilizar un modificador de protección contra reentradas que haya sido validado por el tiempo
Lo que más temo es reinventar la rueda, tener que escribir todo por mí mismo. En este ámbito hay muchas mejores prácticas de seguridad que podemos utilizar, no es necesario reinventar la rueda. Cuando inventas una rueda, no ha sido suficientemente validada, y en ese momento la probabilidad de que surjan problemas es claramente mucho mayor que la de usar una solución muy madura y probada.
Sugerencias de seguridad
Consejos de seguridad del proyecto
El desarrollo de contratos sigue las mejores prácticas de seguridad.
Contratos actualizables y pausables: muchos ataques no transfieren todos los tokens de una vez, sino que se ejecutan en múltiples transacciones. Si hay un mecanismo de monitoreo relativamente sólido, se puede detectar. Si se detecta y el contrato puede pausarse, se pueden reducir efectivamente las pérdidas.
Uso de bloqueos de tiempo: Si hay un bloqueo de tiempo, supongamos que es de 48 horas para completar, durante este período de bloqueo muchas personas pueden darse cuenta de que el creador ha actualizado un método de mint que todos pueden usar, las personas que monitorean sabrán que el proyecto puede haber sido hackeado, pueden notificar al equipo del proyecto para que lo cambie, incluso si se notifica, nadie hace caso, al menos se puede retirar su parte del dinero, asegurando que sus ganancias no se vean afectadas. Por lo tanto, se puede decir que si un proyecto no tiene bloqueo de tiempo, teóricamente se aumenta la probabilidad de que surjan problemas.
Aumentar la inversión en seguridad, establecer un sistema de seguridad completo: la seguridad no es un punto, ni una línea, la seguridad es un sistema. No debes pensar que como parte del proyecto, si el contrato ha sido auditado por varias compañías, todo está bien; hay que considerar varios riesgos que pueden llevar a pérdidas de fondos. Se debe hacer modelado de riesgos en la medida de lo posible, y luego ir eliminando gradualmente la mayor parte de los riesgos, el riesgo restante también es un riesgo aceptable, dentro de un rango tolerable. La seguridad y la eficiencia no se pueden obtener a la vez, se debe hacer ciertos sacrificios. Pero si no se hace nada por la seguridad, si no hay inversión en seguridad, ser atacado es algo muy normal.
Aumentar la conciencia de seguridad de todos los empleados: aumentar la conciencia de seguridad no requiere mucha tecnología. En este gran entorno, solo se necesita preguntar un poco más el porqué y pensar un poco más para evitar muchos problemas.
Prevenir el mal uso interno, mejorando la eficiencia al mismo tiempo que se refuerza el control de riesgos: por ejemplo, si el propietario del contrato es de firma única o múltiple, si se utiliza un bloqueo temporal, etc., todo esto debe ser considerado.
Seguridad de la introducción de terceros: como parte del ecosistema, los proyectos tienen sus propios proveedores y clientes. Existe un principio de "default de que los proveedores y clientes son inseguros". Se debe realizar una verificación tanto para los proveedores como para los clientes. Es muy difícil controlar a los terceros, por lo que la exposición al riesgo de seguridad es particularmente alta, así que hay que tener mucho cuidado con la introducción de terceros. Los contratos son de código abierto, se pueden introducir y llamar; si el contrato no es de código abierto, no se puede hacer referencia a él.
¿Cómo pueden los usuarios/LP determinar si un contrato inteligente es seguro?
Para los usuarios comunes, la evaluación de la seguridad de un proyecto se basa principalmente en los siguientes seis puntos:
¿El contrato es de código abierto?: En cualquier proyecto cuyo contrato no sea de código abierto, no lo tocaremos, porque no podemos saber qué es lo que está escrito en el contrato.
¿El propietario utiliza múltiples firmas? ¿Las múltiples firmas son descentralizadas? Si no se utilizan múltiples firmas, no podemos juzgar la lógica y el contenido del negocio del proyecto; si ocurre un evento de seguridad, no podemos determinar si fue causado por un hacker. Incluso si se utilizan múltiples firmas, también es necesario juzgar si estas múltiples firmas son descentralizadas.
Situación de las transacciones del contrato existente: especialmente hay muchos proyectos de phishing y estafas en el mercado, que pueden crear un contrato bastante similar. En este momento, debemos observar el tiempo de despliegue del contrato, el número de interacciones, etc. Estos son criterios para evaluar si el contrato es seguro.
¿Es el contrato un contrato de agencia, es actualizable, tiene bloqueo de tiempo? Si el contrato no se puede actualizar en absoluto, sería demasiado rígido; aún así, se recomienda que el contrato del proyecto sea actualizable. Sin embargo, la actualización debe hacerse de manera adecuada; cuando haya contenido de actualización y cambios en parámetros importantes, debe haber un bloqueo de tiempo, y se debe proporcionar a todos una ventana de tiempo para juzgar si la actualización real es perjudicial o beneficiosa para los usuarios, esta también es una forma de ser público y transparente.
¿El contrato ha sido auditado por varias instituciones? ( No confíes ciegamente en las empresas de auditoría ), ¿Los permisos del Owner son demasiado amplios? Primero, no confíes solo en una empresa de auditoría, porque diferentes empresas de auditoría y diferentes auditores tienen distintas perspectivas sobre los problemas. En segundo lugar, debes verificar si los permisos del Owner son demasiado amplios. Los permisos de un Owner en un proyecto normal deben ser controlables, de esta manera no habrá demasiadas operaciones de alto riesgo, y las operaciones también se realizarán de manera temporal, para que los usuarios sepan qué operaciones se están realizando.
Atención a los oráculos: Si el proyecto utiliza un oráculo líder en el mercado, básicamente no habrá grandes problemas, pero si utiliza un oráculo construido por ellos mismos, o un oráculo donde se pueden alimentar precios con solo hipotecar algunos tokens al azar, entonces hay que tener cuidado. Cuando se descubra que el oráculo puede tener algunos problemas, o que existe la posibilidad de ser manipulado, incluso si el rendimiento del proyecto es muy alto, no se debe participar.
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
5
Compartir
Comentar
0/400
BrokeBeans
· 07-22 12:06
Vaya, estos Flash Loans son muy rentables, lamentablemente no sé cómo...
Ver originalesResponder0
LayerZeroHero
· 07-22 06:59
¿Otra vez los Flash Loans están en la mira? No es sorprendente.
Ver originalesResponder0
P2ENotWorking
· 07-19 19:46
Si quieres ganar dinero, debes saber cómo prevenir las vulnerabilidades.
Ver originalesResponder0
ConsensusBot
· 07-19 19:42
Billetera primero, luego Comercio de criptomonedas.
Ver originalesResponder0
LiquidityWizard
· 07-19 19:27
Perro viejo de la industria, profesional de sombrero blanco
Análisis de las vulnerabilidades de seguridad comunes en Finanzas descentralizadas: prevención de Flash Loans, manipulación de precios y ataques de reentrada.
Finanzas descentralizadas Vulnerabilidades de seguridad comunes y medidas de prevención
Recientemente, un experto en seguridad compartió una clase de seguridad de Finanzas descentralizadas con los miembros de la comunidad. Revisó los importantes incidentes de seguridad que ha enfrentado la industria de Web3 en el último año y más, explorando las razones detrás de estos eventos y cómo evitarlos. Resumió las vulnerabilidades de seguridad comunes en los contratos inteligentes y las medidas de prevención, y también ofreció algunos consejos de seguridad para los equipos de proyectos y los usuarios comunes.
Los tipos comunes de vulnerabilidades en Finanzas descentralizadas incluyen préstamos relámpago, manipulación de precios, problemas de permisos de funciones, llamadas externas arbitrarias, problemas con la función fallback, vulnerabilidades de lógica de negocio, filtración de claves privadas, reentradas, entre otros. A continuación, se presentan en detalle los préstamos relámpago, la manipulación de precios y los ataques de reentrada.
Préstamo relámpago
El préstamo relámpago en sí es una innovación de las Finanzas descentralizadas, pero cuando es utilizado por hackers, pueden obtener grandes cantidades de dinero sin costo alguno, y tras ejecutar la arbitraje, solo necesitan devolverlo pagando una pequeña tarifa de Gas para obtener enormes beneficios.
En los últimos dos años, los problemas con los préstamos relámpago han sido frecuentes. Algunos proyectos parecen ofrecer altos rendimientos, pero en realidad la calidad de los desarrolladores varía. Incluso si el código en sí no tiene vulnerabilidades, puede haber problemas lógicos. Por ejemplo, hay proyectos que otorgan recompensas en momentos fijos según la cantidad de tokens que posee un tenedor, pero son aprovechados por atacantes que utilizan préstamos relámpago para comprar una gran cantidad de tokens y obtener la mayor parte de las recompensas cuando se distribuyen. También hay algunos proyectos que calculan precios a través de tokens, que pueden ser influenciados por préstamos relámpago. Los desarrolladores deberían estar más alerta ante estos problemas.
Manipulación de precios
El problema del control de precios está estrechamente relacionado con los préstamos relámpago, y hay principalmente dos tipos:
Se utilizan datos de terceros para calcular el precio, pero el uso incorrecto o la falta de verificación hacen que el precio sea manipulado maliciosamente.
Utilizar la cantidad de tokens de ciertas direcciones como variable de cálculo, y el saldo de tokens de estas direcciones puede ser temporalmente aumentado o disminuido.
Ataque de reentrada
Uno de los principales peligros de llamar a contratos externos es que pueden tomar el control del flujo de ejecución y realizar cambios inesperados en los datos al invocar funciones.
Existen muchas formas de reentrada para diferentes contratos, que pueden combinarse con diferentes funciones del contrato o funciones de varios contratos diferentes para llevar a cabo un ataque de reentrada, por lo que al abordar el problema de reentrada es necesario tener en cuenta:
No solo previene el problema de reentrada de una única función.
Seguir el patrón Checks-Effects-Interactions para codificación
Utilizar un modificador de protección contra reentradas que haya sido validado por el tiempo
Lo que más temo es reinventar la rueda, tener que escribir todo por mí mismo. En este ámbito hay muchas mejores prácticas de seguridad que podemos utilizar, no es necesario reinventar la rueda. Cuando inventas una rueda, no ha sido suficientemente validada, y en ese momento la probabilidad de que surjan problemas es claramente mucho mayor que la de usar una solución muy madura y probada.
Sugerencias de seguridad
Consejos de seguridad del proyecto
El desarrollo de contratos sigue las mejores prácticas de seguridad.
Contratos actualizables y pausables: muchos ataques no transfieren todos los tokens de una vez, sino que se ejecutan en múltiples transacciones. Si hay un mecanismo de monitoreo relativamente sólido, se puede detectar. Si se detecta y el contrato puede pausarse, se pueden reducir efectivamente las pérdidas.
Uso de bloqueos de tiempo: Si hay un bloqueo de tiempo, supongamos que es de 48 horas para completar, durante este período de bloqueo muchas personas pueden darse cuenta de que el creador ha actualizado un método de mint que todos pueden usar, las personas que monitorean sabrán que el proyecto puede haber sido hackeado, pueden notificar al equipo del proyecto para que lo cambie, incluso si se notifica, nadie hace caso, al menos se puede retirar su parte del dinero, asegurando que sus ganancias no se vean afectadas. Por lo tanto, se puede decir que si un proyecto no tiene bloqueo de tiempo, teóricamente se aumenta la probabilidad de que surjan problemas.
Aumentar la inversión en seguridad, establecer un sistema de seguridad completo: la seguridad no es un punto, ni una línea, la seguridad es un sistema. No debes pensar que como parte del proyecto, si el contrato ha sido auditado por varias compañías, todo está bien; hay que considerar varios riesgos que pueden llevar a pérdidas de fondos. Se debe hacer modelado de riesgos en la medida de lo posible, y luego ir eliminando gradualmente la mayor parte de los riesgos, el riesgo restante también es un riesgo aceptable, dentro de un rango tolerable. La seguridad y la eficiencia no se pueden obtener a la vez, se debe hacer ciertos sacrificios. Pero si no se hace nada por la seguridad, si no hay inversión en seguridad, ser atacado es algo muy normal.
Aumentar la conciencia de seguridad de todos los empleados: aumentar la conciencia de seguridad no requiere mucha tecnología. En este gran entorno, solo se necesita preguntar un poco más el porqué y pensar un poco más para evitar muchos problemas.
Prevenir el mal uso interno, mejorando la eficiencia al mismo tiempo que se refuerza el control de riesgos: por ejemplo, si el propietario del contrato es de firma única o múltiple, si se utiliza un bloqueo temporal, etc., todo esto debe ser considerado.
Seguridad de la introducción de terceros: como parte del ecosistema, los proyectos tienen sus propios proveedores y clientes. Existe un principio de "default de que los proveedores y clientes son inseguros". Se debe realizar una verificación tanto para los proveedores como para los clientes. Es muy difícil controlar a los terceros, por lo que la exposición al riesgo de seguridad es particularmente alta, así que hay que tener mucho cuidado con la introducción de terceros. Los contratos son de código abierto, se pueden introducir y llamar; si el contrato no es de código abierto, no se puede hacer referencia a él.
¿Cómo pueden los usuarios/LP determinar si un contrato inteligente es seguro?
Para los usuarios comunes, la evaluación de la seguridad de un proyecto se basa principalmente en los siguientes seis puntos:
¿El contrato es de código abierto?: En cualquier proyecto cuyo contrato no sea de código abierto, no lo tocaremos, porque no podemos saber qué es lo que está escrito en el contrato.
¿El propietario utiliza múltiples firmas? ¿Las múltiples firmas son descentralizadas? Si no se utilizan múltiples firmas, no podemos juzgar la lógica y el contenido del negocio del proyecto; si ocurre un evento de seguridad, no podemos determinar si fue causado por un hacker. Incluso si se utilizan múltiples firmas, también es necesario juzgar si estas múltiples firmas son descentralizadas.
Situación de las transacciones del contrato existente: especialmente hay muchos proyectos de phishing y estafas en el mercado, que pueden crear un contrato bastante similar. En este momento, debemos observar el tiempo de despliegue del contrato, el número de interacciones, etc. Estos son criterios para evaluar si el contrato es seguro.
¿Es el contrato un contrato de agencia, es actualizable, tiene bloqueo de tiempo? Si el contrato no se puede actualizar en absoluto, sería demasiado rígido; aún así, se recomienda que el contrato del proyecto sea actualizable. Sin embargo, la actualización debe hacerse de manera adecuada; cuando haya contenido de actualización y cambios en parámetros importantes, debe haber un bloqueo de tiempo, y se debe proporcionar a todos una ventana de tiempo para juzgar si la actualización real es perjudicial o beneficiosa para los usuarios, esta también es una forma de ser público y transparente.
¿El contrato ha sido auditado por varias instituciones? ( No confíes ciegamente en las empresas de auditoría ), ¿Los permisos del Owner son demasiado amplios? Primero, no confíes solo en una empresa de auditoría, porque diferentes empresas de auditoría y diferentes auditores tienen distintas perspectivas sobre los problemas. En segundo lugar, debes verificar si los permisos del Owner son demasiado amplios. Los permisos de un Owner en un proyecto normal deben ser controlables, de esta manera no habrá demasiadas operaciones de alto riesgo, y las operaciones también se realizarán de manera temporal, para que los usuarios sepan qué operaciones se están realizando.
Atención a los oráculos: Si el proyecto utiliza un oráculo líder en el mercado, básicamente no habrá grandes problemas, pero si utiliza un oráculo construido por ellos mismos, o un oráculo donde se pueden alimentar precios con solo hipotecar algunos tokens al azar, entonces hay que tener cuidado. Cuando se descubra que el oráculo puede tener algunos problemas, o que existe la posibilidad de ser manipulado, incluso si el rendimiento del proyecto es muy alto, no se debe participar.