Analise smart-contract
29.01.2024

使用 ChatGPT 自审计智能合约

在审计智能合约时,需要涵盖广泛的问题,以确保代码的安全性。这些问题涉及各个方面,包括访问控制、资产管理、数据管理、假设、依赖性和安全检查列表。

如果您想亲自调查智能合约中的漏洞和隐藏的欺诈技术,第一步就是正确编写 ChatGPT 提示。

ChatGPT 的有用查询命令如下:

提供以下智能合约中所有问题和漏洞的综合列表。详细描述问题和可能存在的漏洞。为每个漏洞提供一个利用场景。以标记符格式输出有效表格,其中包含对象列表,每个对象都有 "描述"、"操作"、"严重性"、"行为者"、"场景"、"类型 "和 "行 "列。类型 "可以是 "可用性"、"漏洞"、"优化 "或 "建议"。行为者 "是相关行为者的列表。严重性 "可以是 "低"、"中 "或 "高"。行 "是问题的行号。确保填写表格中的所有字段。

然后使用以下问题更深入地探索智能合约。

使用场景:

  1. 系统中的参与者是谁?

  2. 系统有哪些行动?

  3. 系统有哪些局限性?

  4. 破解系统的潜在方法有哪些?

  5. 使用哪些防御措施来抵御攻击?

  6. 根据限制条件描述每个功能的状态变化。

  7. 提供所使用的 Solidity 和 DeFi 模板的相关信息。

  8. 根据系统信息编写正反公理。

  9. 列出优化和修改代码使其更可靠的方法(附代码片段)

  10. 列出代码中使用的隐藏骗局方法(附代码片段)。

提示:数据的可视化表示通常能让人更清楚地了解系统的运行。在使用 ChatGPT 时,建议您要求输出数据可视化,例如以 ASCII 字符图的形式显示状态修改。

事实上,虽然 ChatGPT 无法取代人工审计员,但它可以提供对协议状态转换、约束、不变式和兼容性的更清晰的理解,从而极大地补充了审计流程。

提示:在开始审核之前,向聊天机器人提供有关被审核协议的文档可以大大提高回复的准确性和相关性。只需提及 "这是为我正在审计的'protocol_name'提供最佳上下文的文档",然后插入文档即可。

可以说,ChatGPT 是审计人员的强大助手,它为审计智能合约提供了一种结构化的深入方法。但是,我们应该牢记,ChatGPT(以及类似服务)只是对机器分析概率的复杂解释,因此它经常会产生错误和不准确的结果。因此,不能完全依赖 ChatGPT 的结果,它只是一个合适的工具和智能合约研究的 "起点"。

因此,为了保护自己免受可能的风险,应更仔细地检查智能合约是否存在可能的漏洞和欺诈计划。

common tips

如何进行深入的智能合约审计?向 ChatGPT 提出的前 100 个请求

以上我们考虑了向 ChatGPT 提出的一般查询(提示),您可以据此开始分析智能合约。

骗子们在不断改进他们的策略,因此您需要在许多方面保持知情和谨慎--这些都是保护您的代币投资的基本策略。

让我们来看看前 100 个查询列表,它们将为您提供专业的智能合约审计方法:

  1. 代码编译成功了吗?
  2. 代码中使用的是哪个版本的 Solidity?是当前的稳定版本吗?
  3. 是否有清晰的注释解释函数和变量的目的?
  4. 合同是否使用 "可拥有 "方案?如果是,用于哪些功能?
  5. 是否使用可见性修改器正确分配了状态变量?
  6. 事件是否用于正确记录?
  7. 是否提供了方便用户的错误信息?
  8. 是否检查了低级调用的返回值?
  9. 在哪些情况下,业主可以自行授权,从而导致地毯拉扯?
  10. 谁有权控制特权账户,控制机制是什么?
  11. 合同中有哪些治理机制,治理是完全开放的还是有限的?
  12. 系统中是否使用了其他合同,它们发挥什么作用(如代理合同)?
  13. 是否有时间锁定机制,能否绕过?
  14. 是否有足够的文件?
  15. 代码中是否存在 DoS 或重入攻击的潜在漏洞?
  16. 除了明确要求公开/外部的功能外,所有功能都是内部功能吗?
  17. 数学运算中没有算术溢出/下溢?
  18. 是否正在使用安全的 OpenZeppelin 库?
  19. 以太币或代币无法意外发送到空地址(0x0)?
  20. 在操作和状态更改之前,是否用 require 检查条件?
  21. 是否在执行操作前和执行操作过程中设置了状态?
  22. 是否使用了防止再进入(再进入)攻击(A 呼叫 B 呼叫 A)的保护措施?
  23. ERC20 接口是否已正确实施?
  24. 是否只有在确实必要的情况下才在多处使用修饰语?
  25. 是否明确设置了所有类型(例如使用 uint256 代替 uint)?
  26. 所有方法和循环是否都在最大允许气体限值范围内?
  27. 构造函数中没有不必要的初始化(记住已设置默认值)?
  28. 测试覆盖面完整:每个智能合约方法和所有可能的输入数据类型都经过测试?
  29. 是否使用随机输入进行了模糊测试?
  30. 是否所有可能的合同状态都经过了测试?
  31. 以太币和代币的默认数量是以魏为单位指定的。
  32. 众筹结束区块/时间是否在开始区块/时间(开始/启用交易)之后?
  33. 众筹代币的兑换/换算率设置是否正确?
  34. 是否设置了软/硬众筹限额?
  35. 是否设定并测试了众筹的最低/最高允许捐款额?
  36. 是否测试过众筹白名单功能?
  37. 众筹退款逻辑是否已得到验证?
  38. 众筹参与者是按比例获得代币,还是可以申报自己的贡献?
  39. 众筹每个阶段(如预售、公开销售)的持续时间是否配置得当?
  40. 是否规定哪些功能只能由所有者控制(如暂停众筹、转入众筹的另一阶段、启用代币分配等)?
  41. 众筹归属(归属)逻辑是否已检查完毕?
  42. Crowdsale 具有故障安全模式,当所有者启用该模式时,会限制功能调用并包含退款功能?
  43. 如果有合理的理由,众筹还有后备功能。
  44. 导入的库是否经过预先检查,是否包含可能在未来版本中被替换并可能被用于恶意目的的不需要的部分?
  45. 代币转让方法(转让)中是否包含 require?
  46. require 和 assert 的使用是否正确?assert 方法只用于不应该发生的事情,通常用于检查更改后的状态。
  47. 有办法抵御递归调用攻击吗?
  48. 输入中任意字符串的长度是否有限制?
  49. 尽可能避免使用数组,而使用映射?
  50. 区块哈希值是否不用于处理随机值(矿工会影响这一点)?
  51. 没有在任何地方使用 tx.origin?
  52. 删除元素时,数组元素会向下移动,以避免留下间隙?
  53. 是否用 revert 代替 throw?
  54. 如果不满足条件,功能是否会立即终止?
  55. 编译器警告解决了吗?
  56. 计算中是否使用了 SafeMath 库?
  57. 是否有内存插槽(存储插槽)被多次读取?
  58. 是否使用了可能导致 DoS 的无限制循环/数组?
  59. block.timestamp 是否只用于长间隔?
  60. 没有使用 block.number 计算经过时间?
  61. 是否避免了 委托调用 调用,尤其是外部(即使是受信任的)合同?
  62. 迭代数组时,数组的长度不会更新吗?
  63. 签名是否可通过 nonce 和 block.chainid 免受重放?
  64. 确保所有签名都使用 EIP-712?
  65. 如果使用了两个以上的动态类型,则不应散列 abi.encodePacked() 的输出结果。一般来说,最好使用 abi.encode()。
  66. 仔细检查插入的汇编代码。
  67. 避免耗气量不足(耗气过多)。
  68. 所有私人数据真的都是私人的吗?
  69. 更新内存(memory)中的结构/数组不会改变存储(stage)中的结构/数组?
  70. 阶段变量是否被掩盖了?
  71. 即时计算变量值比存储变量值更省钱吗?
  72. 所有状态变量都是从正确的合约(主合约与克隆合约)中读取的吗?
  73. 是否正确使用了比较运算符 (>、<、>=、<=),尤其是防止出现偏一错误?
  74. 逻辑运算符 (==、!=、&&、||、!) 的使用是否正确,尤其是在防止逐一偏移错误时?
  75. 乘法是否总是在除法之前执行(除非乘法会溢出)?
  76. 魔术数字是否被一个具有直观名称的常数所取代?
  77. 如果 ETH 接收者有一个可以还原的回退(fallback )功能,这会导致 DoS 吗?
  78. 是否使用 SafeERC20 标准,是否以安全方式检查返回值?
  79. 是否假定 msg.sender 始终是相关用户?
  80. origin 不是用来授权的吗?
  81. 难道不是用 address.transfer() 或 address.send() 代替 .call.value() 吗?
  82. 在使用低级调用时,请确保在调用之前存在合同。
  83. 是否使用汇编代码访问 chainid 或合同代码/大小/哈希,而不是 Solidity 语法?
  84. 将变量设置为空值(0、false、"", 等等)时,是否使用删除关键字?
  85. 传递给逻辑运算符/比较(&&/||/>=/==/等等)的表达式不得有副作用。
  86. 在处理多个地址时,问问自己如果地址相同会怎样?
  87. 代码的文档化程度如何?是否在使用非标准代码的地方提供了注释和示例?
  88. 如果使用外部呼叫,请确保外部合同呼叫真的有必要吗?
  89. 是否检查外部调用的结果并处理错误?
  90. 如果 "外部呼叫 "使用了所有提供的气体,会发生什么情况?
  91. 如果外部调用调用特定函数,请确保该函数确实存在(幽灵函数)。
  92. 确保修改器中没有使用外部调用(修改器)
  93. 是否对每个修改存储的功能都发布事件?
  94. 检查您对主要使用的外部合同的作用和回报的假设。
  95. 注意使用过多或过少小数的令牌。确保记录支持的最大值和最小值。
  96. 是否记录了与角色相关的权限?
  97. 当访问权限受到侵犯时会有哪些风险?
  98. 所有者能否在合约内操纵代币和 ETH?
  99. 甲骨文(Oracle)地址是如何设置的?是否有备用甲骨文用于备份?
  100. 其他项目是如何实施类似功能的,是否考虑了最佳做法?

common tips

这份清单将帮助您确保对 Solidity 智能合约进行彻底的安全审计。它涵盖了广泛的关键方面,可用于识别和减轻代码及相关系统中的潜在漏洞和风险。

 

我们希望这些示例能帮助您更好地理解智能合约审计方法。

 

由于区块链中的所有信息都是公开的(当然,前提是要验证合约的源代码),因此,有了这些知识,您就可以独立研究智能合约,识别各种骗局。

由于区块链中的所有信息都是公开的(当然,前提是要验证合约的源代码),因此,有了这些知识,您就可以独立研究智能合约,识别各种骗局。 不过,我们已经为你做好了这一切!注册高级订阅,获取有关智能合约功能和最新分析的独家过滤器。增加您成功投资可盈利代币的机会。

Regards, Lotus Market team.

All posts

Connect to a wallet

Metamask