¿El robo de Lendf.Me es culpa de ERC-777? Pensando desde protocolo, estándar y compatibilidad

"Este ataque de piratas informáticos utilizó principalmente las lagunas en el estándar ERC777 de activos imBTC para llevar a cabo ataques de reingreso. El mecanismo de devolución de llamada permite a los piratas informáticos prestar dinero repetidamente con imBTC falso como garantía".

——Anuncio de dForce

Los incidentes de seguridad mencionados anteriormente se han resuelto inicialmente y las víctimas (como los dos días en que el hermano del libro naranja perdió dinero en DeFi y recuperó su dinero) están felices. También se han dado a conocer los detalles del ataque, pero todavía hay diferentes voces sobre qué causó la vulnerabilidad.

Algunos piensan que es una deficiencia de ERC777; algunos piensan que es un problema de compatibilidad; algunos piensan que es un problema con la implementación de imBTC. Aquí, siento que se deben aclarar algunos conceptos para facilitar nuestra discusión de los hechos.

Acuerdo: La palabra "acuerdo" en chino es ambigua. El acuerdo al que nos referimos aquí no es un "contrato" en el sentido legal, ni una "licencia de software (Licencia)", sino un "protocolo" en la comunicación. En telecomunicaciones, un protocolo es un sistema de reglas para intercambiar información entre dos o más entidades en un sistema de comunicación.

Norma: Una norma es "un documento normativo que se usa y reutiliza conjuntamente para obtener el mejor orden dentro de un rango determinado, formulado por consenso y aprobado por instituciones reconocidas".

Los estándares no son necesariamente protocolos, porque los estándares no son solo para comunicaciones. Y el acuerdo no es necesariamente un estándar, porque el estándar debe ser confirmado por la especificación. Pero el estándar de comunicación debe ser el protocolo de comunicación. Por lo tanto, las normas deben ser promulgadas por alguna organización designada. Las organizaciones de estándares más conocidas incluyen ISO, ITU, IETF, etc. Por ejemplo, TCP como estándar de transmisión está determinado por RFC-793 emitido por IETF.

¿Es ERC777 un protocolo?

Sí.

Por supuesto, personalmente prefiero otra expresión, ERC777 contiene el acuerdo. ERC777 define un tipo de token, especifica los atributos del contrato de token, la interfaz abierta y las funciones implementadas, y se utiliza para regular la comunicación entre la dirección de Ethereum y el contrato de token ERC777, que se realiza a través de la interfaz. Pero ERC777 también incluye otras cosas además del protocolo de comunicación. Por ejemplo, la función decimales () se usa para consultar la precisión del token. Obviamente, este es un protocolo de comunicación, pero debe devolver 18 de acuerdo con los requisitos de ERC777, que no no pertenecen al ámbito del protocolo de comunicación.

¿Es ERC777 un estándar?

Sí. Se puede decir por el nombre.

BCH cayó por debajo de la marca de $ 490 con una caída intradiaria del 6,48 %: según datos de Huobi Global, BCH cayó a corto plazo y cayó por debajo de la marca de $ 490. Ahora está en $ 489,68, con una caída intradiaria del 6,48 %. en gran medida, por favor haga un buen trabajo de control de riesgos. [2021/3/25 19:15:34]

EIP 777: Estándar de token ERC777 (Estándar de token ERC).

Lo que está implícito aquí es que si emite un token que dice que es un token ERC777, debe implementar todas las interfaces definidas por este estándar. Al mismo tiempo, este token debe ser retroactivamente compatible con el estándar ERC20. ¿Qué significa?

¿Qué es la compatibilidad?

La compatibilidad se refiere al grado de coordinación mutua entre hardware, software o sistemas combinados de software y hardware.

De acuerdo con el documento estándar, ERC777 es retrocompatible con ERC20, ¿qué significa esto?

La retrocompatibilidad (compatibilidad con versiones anteriores), también conocida como compatibilidad con versiones anteriores (downward support), retrocompatibilidad, en computadoras, significa que después de que un programa, biblioteca o hardware se actualiza a una versión más nueva, los documentos o sistemas creados con la versión anterior de el programa aún se puede usar Operación o uso normal (incluidos los datos de entrada), los programas desarrollados sobre la base de versiones anteriores de bibliotecas aún se pueden compilar y ejecutar normalmente, o las versiones anteriores de hardware aún se pueden usar en versiones más nuevas.

¿Qué quiere decir si vemos ERC20 como la versión anterior y ERC777 como la nueva versión? La compatibilidad con retroceso significa que cualquier interfaz de ERC20 se ha implementado en ERC777. En otras palabras, suponiendo que un token se actualice directamente de ERC20 a ERC777 (realmente imposible, pero podemos hacer tal suposición), el método de comunicación original sigue siendo válido, pero esto no significa que el resultado final sea consistente. ¡Este punto es muy importante! Veamos primero un ejemplo.

Ejemplos sobre compatibilidad

Inyección SQL

"La inyección de SQL es un método de ataque que agrega código SQL a los parámetros de entrada y lo pasa al servidor para su análisis y ejecución".

En pocas palabras, los usuarios pueden atacar la base de datos a través de la interfaz pública. Por ejemplo:

Cuando iniciemos sesión en el sitio web, ingresaremos el nombre de usuario y la contraseña, y el fondo del servidor juzgará si el nombre de usuario y la contraseña coinciden para decidir si permitir que el usuario inicie sesión.

Supongamos que ingresamos el nombre de usuario: usuario'-- (nota: hay un espacio detrás y las comillas simples cierran las comillas simples a la izquierda de usuario), e ingresamos la contraseña a voluntad, como: 111, y luego haga clic en el botón enviar. Equivalente a la sentencia SQL:

SELECCIONE * FROM usuario WHERE nombre de usuario = 'usuario'-- 'Y contraseña = '111'

Dado que la parte posterior a "--" está comentada, el usuario puede iniciar sesión sin importar si la contraseña es correcta o incorrecta.

Por supuesto, el código real no es tan simple. Si lee este pasaje e intenta atacar el sitio web, no tendrá éxito.

¿Qué tiene que ver esto con la compatibilidad? explique.

Suponga que un sitio web sigue el acuerdo de usuario U20, que solo permite que el nombre de usuario sea letras, por lo que el usuario no puede ingresar los dos símbolos ' y -. Por supuesto, no solo el cuadro de entrada del front-end está limitado, sino que el back-end también verificará si cada carácter cumple con las condiciones. En otras palabras, cuando la interfaz pasa parámetros, estos dos símbolos no pueden aparecer y esta interfaz cumple con U20. En este momento, no se produce el problema de inyección SQL del ejemplo. (Pero no estoy seguro si otras inyecciones son posibles).

Un día, el acuerdo de usuario del sitio web se actualizó a U777, los nuevos usuarios pueden usar ' y - como nombres de usuario, y la interfaz también debe actualizarse. El U777 es, por supuesto, retrocompatible con el U20, ya que los usuarios antiguos aún pueden iniciar sesión con nombres de usuario y con la interfaz y las interfaces antiguas. Los nuevos usuarios deben actualizar los códigos de front-end y back-end antes de poder iniciar sesión.

Si el front-end y el back-end simplemente no imponen restricciones a los dos caracteres anteriores, inevitablemente conducirá al problema de inyección de SQL mencionado anteriormente. ¿Pero es la actualización de la interfaz la culpable de esto?

Obviamente no. El protocolo solo garantiza que la entrada del usuario se transmita al backend de manera compatible y, después de la actualización del protocolo, esto aún se realiza correctamente. Los riesgos que presentan los nuevos caracteres requieren una reevaluación del código de back-end, y también se puede considerar que el código de back-end no es compatible con el nuevo protocolo.

¿Es esto un problema con el código de fondo? ¿Es este un problema de actualización de protocolo? ninguno de los dos. Es porque después de que se actualizó el protocolo, los usuarios tenían superpoderes que podían destruir el sistema.

Llevando el tema un poco más allá, la velocidad máxima del tren se ha elevado de 20 km/h a 100 km/h, y los raíles siguen siendo compatibles con el tren. Pero, ¿afectará el ruido a los residentes en el camino?, ¿el cruce necesita aumentar el nivel de seguridad? Obviamente, esto debe ser revisado.

¿Qué debo hacer?

La compatibilidad retroactiva no significa seguridad, porque las nuevas características deben tener externalidades, y esta externalidad es difícil de predecir para otras entidades, la llamada "seguridad es dinámica". Volviendo al ejemplo de ahora, hay dos enfoques.

Una es juzgar varias externalidades por adelantado. El código de back-end es muy cauteloso, finge no saber que la entrada del usuario está restringida y lo procesa de acuerdo con el juego de caracteres completo, de modo que no importa cómo se actualice el protocolo, el back-end es seguro.

La segunda es una estrategia flexible pero prudente. Antes de actualizar el protocolo, vuelva a evaluar la seguridad y vuelva a implementar después de la modificación y las pruebas.

Dependiendo de la complejidad del ejemplo, cualquier enfoque es posible. Más importante aún, para evitar la duplicación del trabajo, mejorar la eficiencia y reducir la posibilidad de problemas de seguridad, se deben realizar intentos de estandarizar los problemas comunes.

Por ejemplo, el inicio de sesión de un usuario es un escenario lógicamente simple y muy común. Para evitar la inyección de código SQL, existen prácticas estandarizadas, como la declaración preparada, que no es necesario que se realice a puerta cerrada. Y volviendo a la pregunta del principio, me gustaría citar un pasaje de SlowMist: “Al acceder a plataformas DeFi de terceros, deben considerar completamente la compatibilidad entre la lógica comercial de la plataforma en sí y los tokens de acceso para evitar seguridad innecesaria. problemas debido a la compatibilidad En lugar de simplemente culpar al protocolo y al proveedor del token por el problema ".

Por qué ERC777 es difícil de promocionar

¿Por qué ERC777 es compatible con ERC20 y proporciona funciones más potentes que ERC20, pero aún así no se puede utilizar ampliamente? Además del hecho de que los tokens ERC20 se han usado ampliamente, todos preferirían soportar sus deficiencias, usar aprobar y transferirDesde, que no es tan seguro, y no quieren o no pueden actualizar, hay otra razón importante: la compatibilidad ligera con ERC20 es no es suficiente, también debe ser compatible con otros protocolos existentes. Si cada protocolo tiene que evaluar el riesgo de aplicar ERC777 por separado, el costo es demasiado alto y es fácil causar malentendidos, lo que obviamente no es propicio para su promoción.

¿Podemos abstraer funciones comunes comunes para formar una implementación estándar? Por ejemplo, la operación de "depósito", si tiene una implementación de referencia estándar para diferentes estándares de token, entonces la probabilidad de muchos problemas se reducirá a un nivel muy bajo.

Como mínimo, también debemos tener cuidado con todas las personas con las que tratamos, y cada contrato debe tener cuidado con todos los contratos con los que trata para evitar problemas de seguridad innecesarios. Porque "él sigue agregando otro tú y yo / nos hace ricos y peligrosos" (Mu Dan, "Ocho poemas", 1942).

Tags：

Ripple