Solcurity 安全标准

September 30th, 2022

翻译修改自 @transmission11 的 The Solcurity Standard

最近在学 Solidity 智能合约安全，发现中文缺少这方面的资料，就翻译了 @transmission11 写的 Solcurity - Solidity 智能合约的安全和代码质量标准。它基于 BoringCrypto, Mudit Gupta, Runtime Verification, 和 ConsenSys Diligence 的工作，总结了审查合约时要注意的安全事项。之后 WTF Academy 会基于它添加新的安全事项。

审查方法概览:

阅读项目的文档、规范和白皮书，了解智能合约的用途。
在查看代码之前，在脑海中构建一个期望中的合约架构模型。
快速浏览一遍合约，感受项目结构，可以利用Surya这类工具。
将项目架构与你脑海中的合约架构模型进行比较，检查不符合预期的部分。
创建威胁模型并列出理论上的高级攻击向量。
查看与价值交换相关的地方，尤其是transfer，transferFrom，send，call，delegatecall，和 selfdestruct。优先检查它们，确保安全。
查看与外部合约交互的区域，并确保所有关于它们的假设都是有效的，例如价格只会上涨等等。
对合约进行一般性的逐行审查。
从威胁模型中每个参与者的角度进行另一次审查。
快速浏览项目的测试 + 代码覆盖率，并深入了解缺乏覆盖率的区域。
运行 Slither/Solhint 等工具并审查其输出。
查看相关项目及其审计，以检查是否存在任何类似问题或疏忽。

变量

V1 - 它是否可以是 internal?
V2 - 它是否可以是 constant?
V3 - 它是否可以是 immutable?
V4 - 它是否设置了可见性? (SWC-108)
V5 - 变量的用途和其他重要信息是否使用 natspec 标准记录?
V6 - 它可以与相邻的存储变量一起打包吗?
V7 - 它是否可以和其他变量打包在一个struct中?
V8 - 使用完整的 256 位类型，除非与其他变量一起打包。
V9 - 如果它是一个公共array，是否提供了一个单独的函数来返回完整的数组？?
V10 - 如果不是有意阻止子合约访问变量，使用更加灵活的internal，而不是private。

结构体

S1 - 这里是否有必要用struct? 可以仅用原始变量吗?
S2 - 它的字段是否打包在了一起?
S3 - struct的用途和所有字段是否使用 natspec 标准记录？

函数

F1 - 它是否可以是 external?
F2 - 它是否应该是 internal?
F3 - 它是否应该是 payable?
F4 - 它是否可以与另一个类似的函数合并?
F5 - 验证所有参数都在安全范围内，即使该函数只能由受信任的用户调用。
F6 - 是否遵循 check-before-effect 模式的检查？ (SWC-107)
F7 - 检查抢跑的可能性，例如批准功能。(SWC-114)
F8 - 是否会遭受 insufficient gas griefing 攻击? (SWC-126)
F9 - 是否应用了正确的修饰符，例如 onlyOwner/requiresAuth?
F10 - 是否总是分配返回值？
F11 - 写下并测试使得函数不能正常运行的状态不变量。
F12 - 写下并测试返回值和改变状态的不变量
F13 - 命名函数时要小心，因为人们会根据名称来假设行为。
F14 - 如果一个函数是故意不安全的（出于节省gas等原因），使用一个特别的名字来引起人们对它的风险的注意。
F15 - 是否所有参数、返回值、side effect和其他信息都使用 natspec 标准记录?
F16 - 如果该功能允许对系统中的另一个用户进行操作，不要假定msg.sender是被操作的用户。
F17 - 如果函数要求合约处于未初始化状态，使用显式的 initialized 变量检查。不要使用 owner == address(0) 或其他类似的检查作为替代品。
F18 - 如果不是有意阻止子合约访问变量，使用更加灵活的internal，而不是private。
F19 - 仅在子合约希望合法（且安全）重写函数的行为时使用virtual。

修饰符

M1 - 是否没有进行存储更新（重入锁除外）?
M2 - 是否避免了外部调用?
M3 - 修饰符的用途和其他重要信息是否使用 natspec 标准记录?

代码

C1 - 是否使用了 SafeMath 或 solidity 0.8 检查数学运算? (SWC-101)
C2 - 是否有存储槽被多次读取?
C3 - 是否使用了任何可能导致 DoS 的无界循环/数组? (SWC-128)
C4 - 仅在长间隔的用途上使用 block.timestamp。 (SWC-116)
C5 - 不要在使用 block.number 进行时间估计。 (SWC-116)
C7 - 尽可能避免使用delegatecall，尤其是对外部（即使是受信任的）合约。 (SWC-112)
C8 - 迭代时不要更新数组的长度。
C9 - 不要使用 blockhash()等全局变量获取随机数。 (SWC-120)
C10 - 是否保护了签名不被 nonce 和 block.chainid 重放。 (SWC-121)
C11 - 确保所有签名使用了 EIP-712。 (SWC-117 SWC-122)
C12 - 如果计算 >2 个动态类型的哈希时，应该使用 abi.encode()，而不是 abi.encodePacked()。 (SWC-133)
C13 - 谨慎对待内联汇编。 (SWC-127)
C14 - 不要假设特定的 ETH 余额。 (SWC-132)
C15 - 避免 insufficient gas griefing攻击。 (SWC-126)
C16 - private 数据不是隐私的。 (SWC-136)
C17 - 更新 memory 中的 struct/array 不会在 storage 中修改它。
C18 - 永远不要隐藏状态变量。 (SWC-119)
C19 - 不要在函数中改变入参的值。
C20 - 即时计算数值是否比存储它更便宜?
C21 - 所有状态变量是否都从正确的合约中读取（主合约与克隆合约）?
C22 - 是否正确使用了比较运算符 (>, <, >=, <=)，特别是防止差一错误（off-by-one error）?
C23 - 是否正确使用了逻辑运算符 (==, !=, &&, ||, !)，特别是防止差一错误（off-by-one error）?
C24 - 在除法前使用乘法，除非乘法将导致溢出。
C25 - 魔术数字是否被具有直观名称的常数所取代？
C26 - 如果 ETH 的接收者有一个 fallback 函数，它会导致 DoS 吗? (SWC-113)
C27 - 使用 SafeERC20 或安全检查返回值。
C28 - 不要在循环中使用 msg.value。
C29 - 如果可能出现循环 delegatecall，则不要使用 msg.value（比如合约继承了 Multicall/Batchable）。
C30 - 不要假设 msg.sender 是相关交易的用户.
C31 - 除非用于模糊测试或形式验证，否则请勿使用 assert()。 (SWC-110)
C32 - 不要将 tx.origin 用于授权检查。 (SWC-115)
C33 - 不要使用 address.transfer() 或 address.send()，使用 .call.value(...)("")。 (SWC-134)
C34 - 使用低级调用（low-level call）时确保合约存在。
C35 - 调用具有多个参数的函数时，使用命名参数语法。
C36 - 不要使用内联汇编调用 create2，使用新式的 salt 合约创建语法。
C37 - 不要使用内联汇编获取chainid或者合约的代码/长度/，使用新式Solidity语法。
C38 - 将变量设置为零值（0, false, ""）时使用delete关键字 .
C39 - 尽可能注释代码来解释 “为什么” 要这么做。
C40 - 在使用晦涩的语法或编写非常规代码时，尽可能注释代码在做 “什么”。
C41 - 在复杂的数学过程旁注释上解释和输入输出例子。
C42 - 在优化gas的地方注释说明，并估计节省的gas。
C43 - 在有意避免优化的地方注释说明，并估计多花费的gas。
C44 - 在不可能上溢/下溢的代码块，或者上溢/下溢在人类时间尺度上不现实的代码块（计数器等）使用 unchecked。注释中写清楚哪里用了 unchecked，并估计节省的gas。
C45 - 不要依赖 Solidity 的算术运算符优先规则。括号不仅用来覆盖默认运算符优先级，而且可以用于强调它。
C46 - 传递给逻辑/比较运算符 (&&/||/>=/==) 的表达式不应有 side effects。
C47 - 如果执行了可能导致精度损失的算术运算，确保它有利于系统中的正确参与者，并在注释中记录它。
C48 - 在注释中写下函数需要重入锁的原因。
C49 - 如果模糊函数仅支持特定范围的参数，使用取模操作限制参数输入范围（例如 x = x % 10000 + 1 将范围限制在从 1 到 10,000）。
C50 - 尽可能使用三元表达式来简化逻辑。
C51 - 当对多个地址进行操作时，问问自己如果它们相同的话会发生什么。