Contratos inteligentes autoauditados con ChatGPT

Al auditar contratos inteligentes, es necesario cubrir una amplia gama de cuestiones para garantizar que el código es seguro. Estas preguntas abarcan diversos aspectos, como el control de acceso, la gestión de activos, la gestión de datos, las suposiciones, las dependencias y las listas de comprobación de seguridad. A continuación proporcionamos una lista de comprobación detallada e instrucciones para las consultas de ChatGPT que le guiarán a través del proceso de auditoría de contratos inteligentes.

Si quieres investigar por ti mismo un contrato inteligente en busca de vulnerabilidades y técnicas de estafa ocultas, el primer paso es un prompt ChatGPT correctamente elaborado.

Una solicitud útil para ChatGPT sería el siguiente comando:

Proporcione una lista completa de todos los problemas y vulnerabilidades del siguiente contrato inteligente. Describa detalladamente los problemas y las posibles vulnerabilidades. Proporcione un escenario de explotación para cada vulnerabilidad. Salida como una tabla válida en formato markdown con una lista de objetos, cada uno con columnas 'descripción', 'acción', 'gravedad', 'actores', 'escenario', 'tipo' y 'línea'. Tipo" puede ser "usabilidad", "vulnerabilidad", "optimización" o "sugerencia". actores" es una lista de los actores implicados. gravedad" puede ser "baja", "media" o "alta". fila" es el número de fila del problema. Asegúrate de que todos los campos de la tabla están rellenados.

A continuación, utiliza las siguientes preguntas para profundizar en el contrato inteligente.

Escenarios de uso:

1. ¿Quiénes son los actores del sistema?


2. ¿Qué acciones tiene el sistema?


3. ¿Cuáles son las limitaciones del sistema?


4. ¿Cuáles son las posibles formas de romper el sistema?


5. ¿Qué defensas se utilizan para contrarrestar los ataques?


6. Describa, basándose en las restricciones, los cambios de estado de cada función.


7. Proporcione información sobre las plantillas Solidity y DeFi utilizadas.


8. Escribe axiomas positivos y negativos a partir de la información sobre el sistema.


9. Enumerar formas de optimizar y modificar el código para hacerlo más fiable (con fragmentos de código).


10. Enumere los métodos de estafa ocultos utilizados en el código (con fragmentos de código).

Consejo: La representación visual de los datos suele ofrecer una comprensión más clara del funcionamiento del sistema. Al trabajar con ChatGPT, se recomienda solicitar visualizaciones de los datos de salida, como las modificaciones de estado en forma de diagramas de caracteres ASCII. Aunque no todas las visualizaciones sean significativas, algunas pueden proporcionar una visión muy valiosa del funcionamiento de un contrato inteligente.

En esencia, aunque ChatGPT no puede sustituir a un auditor humano, complementa significativamente el proceso de auditoría al proporcionar una comprensión más clara de las transiciones de estado del protocolo, las restricciones, las invariantes y la compatibilidad. Esta herramienta es especialmente eficaz para comprender las transiciones de estado y las restricciones del protocolo.

Consejo: Antes de iniciar una auditoría, proporcionar al chatbot documentación sobre el protocolo que se está auditando puede mejorar enormemente la precisión y pertinencia de las respuestas. Basta con mencionar: "Esta es la documentación que proporciona el mejor contexto para el 'nombre_protocolo' que estoy auditando", e insertar el documento.

Se puede decir que ChatGPT es un potente asistente para los auditores, ya que proporciona un enfoque estructurado y en profundidad para auditar los contratos inteligentes. Sin embargo, hay que tener en cuenta que ChatGTP (y servicios similares) no son más que complejas interpretaciones de análisis de máquinas que trabajan con probabilidades, por lo que a menudo produce errores e imprecisiones. En consecuencia, no se debe confiar plenamente en el resultado de ChatGPT: es sólo una buena herramienta en las manos adecuadas y un "punto de partida" en la investigación de contratos inteligentes.

Por lo tanto, con el fin de protegerse de posibles riesgos, los contratos inteligentes deben ser examinados más cuidadosamente en busca de posibles vulnerabilidades y esquemas fraudulentos.

¿Cómo realizar una auditoría en profundidad de un contrato inteligente? Top 100 peticiones a ChatGPT

Arriba hemos considerado una petición general (prompt) a ChatGPT, a partir de la cual se puede empezar a analizar un contrato inteligente. Pero, por supuesto, un análisis detallado no se limita a la solicitud introductoria.

Los estafadores mejoran constantemente sus tácticas, por lo que debe estar informado y ser precavido en muchos aspectos: estas son estrategias esenciales para proteger su inversión en tokens.

Echemos un vistazo a una lista de las 100 mejores consultas que le darán un enfoque profesional a una auditoría de contratos inteligentes:

1. ¿Compila correctamente el código?
2. ¿Qué versión de Solidity se utiliza en el código? ¿Es la versión estable actual?
3. ¿Hay comentarios claros que expliquen la finalidad de las funciones y variables?
4. ¿Utiliza el contrato el esquema "Ownable"? En caso afirmativo, ¿para qué funciones?
5. ¿Se asignan correctamente las variables de estado utilizando modificadores de visibilidad?
6. ¿Se utilizan los eventos para un registro adecuado?
7. ¿Se proporcionan mensajes de error fáciles de usar?
8. ¿Se comprueba el valor de retorno de las llamadas de bajo nivel?
9. ¿Existen situaciones en las que el propietario pueda autorizarse a sí mismo, lo que podría llevar a tirar de la manta?
10. ¿Quién controla las cuentas privilegiadas y cuáles son los mecanismos de control?
11. ¿Qué mecanismos de gobernanza existen en el contrato, y es la gobernanza totalmente abierta o limitada?
12. ¿Se utilizan otros contratos en el sistema y qué funciones desempeñan (por ejemplo, contrato de representación)?
13. ¿Existe un mecanismo de bloqueo de tiempo y puede eludirse?
14. ¿Se dispone de documentación adecuada?
15. ¿Existen en el código vulnerabilidades potenciales a ataques DoS o de reentrada?
16. ¿Son todas las funciones internas excepto las que se requiere explícitamente que sean públicas/externas?
17. ¿No hay desbordamientos/desbordamientos aritméticos en las operaciones matemáticas?
18. ¿Se utiliza la biblioteca segura OpenZeppelin?
19. ¿El éter o las fichas no pueden enviarse accidentalmente a una dirección nula (0x0)?
20. Las condiciones se comprueban con require antes de las operaciones y los cambios de estado?
21. ¿Se establece el estado antes y durante la ejecución de las acciones?
22. ¿Se utiliza protección contra ataques de reentrada (A llama a B llama a A)?
23. ¿Está correctamente implementada la interfaz ERC20?
24. ¿Se utiliza el modificador en varios lugares sólo si es realmente necesario?
25. ¿Se establecen explícitamente todos los tipos (por ejemplo, se utiliza uint256 en lugar de uint)?
26. ¿Están todos los métodos y ciclos dentro del límite máximo de gas permitido?
27. ¿No hay inicializaciones innecesarias en el constructor (recuerda que se establecen valores por defecto)?
28. La cobertura de las pruebas es total: se prueban todos los métodos de los contratos inteligentes y todos los tipos de datos de entrada posibles?
29. ¿Se han realizado pruebas fuzz utilizando entradas aleatorias?
30. ¿Se comprueban todos los posibles estados en los que puede estar un contrato?
31. Las cantidades por defecto de éter y fichas se especifican en unidades de wei?
32. ¿El bloque/hora de finalización de la venta colectiva es posterior al bloque/hora de inicio (inicio/activación de la negociación)?
33. ¿Se ha establecido correctamente el tipo de cambio/conversión de los tokens de crowdsale?
34. ¿Se ha fijado un límite suave/duro para la venta masiva?
35. ¿Se ha fijado y comprobado la contribución mínima/máxima permitida a la crowdsale?
36. ¿Se ha probado la funcionalidad de listas blancas de crowdsales?
37. ¿Se ha probado la lógica de reembolso de las ventas masivas?
38. ¿Reciben los participantes en la crowdsale un número proporcional de fichas o pueden reclamar su contribución?
39. ¿Está bien configurada la duración de cada etapa de la crowdsale (por ejemplo, preventa, venta pública)?
40. ¿Especifica qué funciones debe controlar únicamente el propietario (por ejemplo, pausar la crowdsale, pasar a otra fase de la crowdsale, permitir la distribución de tokens, etc.)?
41. ¿Se ha probado la lógica de adquisición de derechos (vesting) de la crowdsale?
42. Crowdsale dispone de un modo a prueba de fallos que, cuando lo activa el propietario, limita las llamadas de función e incluye una función de reembolso?
43. Crowdsale tiene una función de reserva si tiene un sentido razonable.
44. ¿Se han comprobado previamente las bibliotecas importadas y no contienen partes no deseadas que puedan sustituirse en futuras versiones y utilizarse con fines malintencionados?
45. Métodos de transferencia de fichas (transferencia) envueltos en require?
46. ¿Se utilizan correctamente require y assert? El método assert sólo se utiliza para cosas que nunca deberían ocurrir, normalmente se utiliza para comprobar el estado después de realizar un cambio.
47. ¿Existe alguna defensa contra los ataques de llamadas recursivas?
48. ¿Están limitadas las longitudes de las cadenas arbitrarias en la entrada?
49. En la medida de lo posible, evite las matrices y utilice asignaciones.
50. ¿No se utilizan los hash de bloque para manejar valores aleatorios (los mineros pueden afectar a esto)?
51. ¿No utiliza tx.origin en ningún sitio?
52. Los elementos de la matriz se desplazan hacia abajo cuando se elimina un elemento para no dejar huecos?
53. ¿Se utiliza revert en lugar de throw?
54. ¿Las funciones terminan inmediatamente si no se cumplen las condiciones?
55. ¿Se han resuelto las advertencias del compilador?
56. ¿Se utiliza la biblioteca SafeMath en los cálculos?
57. ¿Alguna ranura de memoria (ranura de almacenamiento) se lee más de una vez?
58. ¿Se están utilizando bucles/arrays sin restricciones que podrían causar DoS?
59. ¿Block.timestamp sólo se utiliza para intervalos largos?
60. ¿No utiliza block.number para calcular el tiempo transcurrido?
61. ¿Se evita la llamada delegatecall, especialmente para contratos externos (aunque sean de confianza)?
62. ¿No se actualiza la longitud del array al iterar sobre él?
63. ¿Están las firmas protegidas contra repetición con nonce y block.chainid?
64. Asegúrese de que todas las firmas utilizan el EIP-712?
65. La salida de abi.encodePacked() no debe ser hash si se utilizan más de 2 tipos dinámicos. En general, es preferible utilizar abi.encode().
66. Compruebe cuidadosamente las inserciones de código ensamblador.
67. Evitar el consumo insuficiente de gas (gas griefing).
68. ¿Todos los datos privados son realmente privados?
69. ¿Actualizar una estructura/array en memoria (memory) no la modificará en almacenamiento (stage)?
70. ¿Se eclipsan las variables escénicas?
71. ¿Calcular el valor de una variable sobre la marcha es más barato que almacenarlo?
72. ¿Se leen todas las variables de estado del contrato correcto (maestro frente a clon)?
73. ¿Se utilizan correctamente los operadores de comparación (>, <, >=, <=), especialmente para evitar errores de comparación?
74. ¿Se utilizan correctamente los operadores lógicos (==, !=, &&, ||, !), sobre todo para evitar errores de separación?
75. ¿Se realiza siempre la multiplicación antes que la división (a menos que la multiplicación pueda desbordarse)?
76. ¿Se sustituyen los números mágicos por una constante con un nombre intuitivo?
77. Si un destinatario de ETH tiene una función de retroceso (fallback ) que se puede cancelar (revertir), ¿podría esto provocar una DoS?
78. ¿Se utiliza el estándar SafeERC20 y se comprueban los valores de retorno de forma segura?
79. ¿Se supone que el remitente de msg.sender es siempre un usuario relevante?
80. ¿No se utiliza tx.origin para la autorización?
81. ¿No se utiliza address.transfer() o address.send() en lugar de .call.value()?
82. Cuando utilice llamadas de bajo nivel, asegúrese de que existe un contrato antes de realizar la llamada.
83. ¿Se utiliza código ensamblador para acceder a chainid o código de contrato/tamaño/hash en lugar de la sintaxis de Solidity?
84. ¿Se utiliza la palabra clave delete cuando se asigna a una variable un valor nulo (0, false, "", etc.)?
85. Las expresiones pasadas a operadores lógicos/comparaciones (&&/||/>=/==/etc) no deben tener efectos secundarios.
86. Cuando se trate de varias direcciones, pregúntese qué ocurre si son la misma.
87. ¿Está bien documentado el código? ¿Se proporcionan comentarios y ejemplos cuando se utiliza código no estándar?
88. Si se utiliza la Llamada externa, asegúrate de que una llamada externa por contrato es realmente necesaria?
89. ¿Se comprueba el resultado de la llamada externa y se gestionan los errores?
90. ¿Qué ocurre si la llamada externa utiliza todo el gas suministrado?
91. Si Llamada externa llama a una función específica, asegúrese de que la función existe realmente (funciones fantasma).
92. Asegúrese de que no se utilizan llamadas externas en los modificadores (modificadores)
93. ¿Se emiten eventos para cada función que modifica el almacenamiento?
94. Compruebe sus suposiciones sobre lo que hacen y devuelven los contratos externos utilizados en el principal.
95. Cuidado con los tokens que utilizan demasiados o muy pocos decimales. Asegúrate de que los valores máximos y mínimos admitidos están documentados.
96. ¿Está documentada la autoridad asociada a las funciones?
97. ¿Cuáles son los riesgos cuando se vulneran los derechos de acceso y cómo puede afectar esto a los distintos componentes del sistema?
98. ¿Puede el propietario manipular tokens y ETH dentro del contrato?
99. ¿Cómo se establece la dirección del oráculo (Oracle) y cuál es el proceso que hay detrás? ¿Existen oráculos de reserva?
100. ¿Cómo se aplican funciones similares en otros proyectos? ¿Se han tenido en cuenta las mejores prácticas?

Esta lista de comprobación le ayudará a asegurarse de que lleva a cabo una auditoría de seguridad exhaustiva de los contratos inteligentes de Solidity. Abarca una amplia gama de aspectos críticos para identificar y mitigar posibles vulnerabilidades y riesgos en el código y los sistemas relacionados.

 

Esperamos que estos ejemplos le hayan ayudado a comprender mejor la metodología de auditoría de contratos inteligentes.

Dado que toda la información de la cadena de bloques es abierta (siempre que, por supuesto, se verifique el código fuente del contrato), armado con este conocimiento puedes estudiar de forma independiente los contratos inteligentes e identificar diversas estafas.

Sin embargo, ¡ya lo hemos hecho todo por ti! Regístrate para obtener una suscripción Premium y accede a filtros exclusivos sobre las características de los contratos inteligentes y a nuevos análisis. Aumenta tus posibilidades de invertir con éxito en tokens rentables.

Saludos, equipo de Lotus Market.

All posts