Solidity进阶之静态分析

## 简介</p> <p>合约的<span class='wp_keywordlink_affiliate'><a href="http://www.bwbbw.com/archives/tag/%e5%ae%89%e5%85%a8" title="View all posts in 安全" target="_blank">安全</a></span>性自动化检测有<span class='wp_keywordlink_affiliate'><a href="http://www.bwbbw.com/archives/tag/%e9%9d%99%e6%80%81%e5%88%86%e6%9e%90" title="View all posts in 静态分析" target="_blank">静态分析</a></span>、动态分析和形式化验证。静态分析不执行合约代码，通过对合约代码做模式匹配或者语义分析来检测漏洞。动态分析需要执行合约，通过大量的模糊测试来观察合约的状态是否会出现问题。形式化验证是将合约的业务逻辑用数学表达式来描述，只要证明数学表达式是正确的，则合约的业务逻辑也是正确的（不代表合约的实现没有问题）。</p> <p>静态分析的优点是使用简单，速度快，但只能检测已知的[<span class='wp_keywordlink_affiliate'><a href="http://www.bwbbw.com/archives/tag/%e5%ae%89%e5%85%a8" title="View all posts in 安全" target="_blank">安全</a></span>漏洞](https://learnblockchain.cn/article/3625)。动态分析能检测出未知的<span class='wp_keywordlink_affiliate'><a href="http://www.bwbbw.com/archives/tag/%e5%ae%89%e5%85%a8" title="View all posts in 安全" target="_blank">安全</a></span>问题，但是成本高、速度慢。形式化验证的使用范围窄，比较适用于一些公共库合约。</p> <p>开发者对合约做静态分析是最基本的要求，使用静态分析工具可以快速检测是否存在一些常见的漏洞，比如：</p> <p>* 权限缺失，比如Oracle的更新没有设置权限<br /> * 重入，这个出的问题最多<br /> * 整数溢出<br /> * DDOS，攻击或者缺陷会导致合约无法执行正常的业务逻辑<br /> * 价格操纵</p> <p>但静态分析工具不能检测出跟业务逻辑特定相关的问题，还需要开发人员通过自检去做人工静态分析。</p> <p>## Solhint</p> <p>[Solhint](https://github.com/protofire/solhint)能提供一些代码规范和安全检查，一些推荐的代码规范比如：</p> <p>* 对字符串使用双引号<br /> * 使用驼峰命名规则<br /> * 明确指定状态变量的可见性<br /> * 避免使用`call`,`delegatecall`等底层操作码<br /> * 避免使用`tx.origin`<br /> * 同一个方法中避免多次使用`msg.value`<br /> * 避免使用`block.number`和`block.timestamp`</p> <p>Solhint的能力较弱，只能做到语法层面的一些检查，但对规范代码比较有用。</p> <p>## Semgrep</p> <p>[Semgrep](https://semgrep.dev/)是一个通用型的静态分析工具，支持多种语言，对solidity的支持目前还较弱。Semgrep跟Solhint一样也是采用模式匹配来进行检测，Solhint的规则是内置的，Semgrep能自定义规则。比如下面这个规则[compound-sweeptoken-not-restricted](https://github.com/Raz0r/semgrep-smart-contracts/blob/master/solidity/compound-sweeptoken-not-restricted.yaml)</p> <p>“`yaml<br /> rules:<br /> –<br /> id: compound-sweeptoken-not-restricted<br /> message: function sweepToken is allowed to be called by anyone<br /> metadata:<br /> references:<br /> – https://medium.com/chainsecurity/trueusd-compound-vulnerability-bc5b696d29e2<br /> – https://chainsecurity.com/security-audit/compound-ctoken/<br /> – https://blog.openzeppelin.com/compound-comprehensive-protocol-audit/<br /> – https://etherscan.io/address/0xa035b9e130f2b1aedc733eefb1c67ba4c503491f # Compound<br /> category: access-control<br /> tags:<br /> – compound<br /> – tusd<br /> patterns:<br /> – pattern-inside: |<br /> function sweepToken(…) {<br /> …<br /> }<br /> – pattern: token.transfer(…);<br /> – pattern-not-inside: |<br /> require(msg.sender == admin, “…”);<br /> …<br /> languages:<br /> – solidity<br /> severity: WARNING<br /> “`</p> <p>这个规则专门针对的Compound曾经出现过的TUSD漏洞，由于有很多其它链的项目fork了Compound，因此这个规则可以快速检测出这些项目是否有类似的问题。</p> <p>## Slither</p> <p>[Slither](https://github.com/crytic/slither)的功能包括：</p> <p>* 漏洞自动检测<br /> * 提供代码优化建议<br /> * 展现代码的拓扑结构<br /> * 通过API能自定义漏洞检测规则</p> <p>Slither的原理是将Solidty抽象语法树（AST）作为输入：</p> <p>* 第一步，先解析出合约间的继承图、控制循环图（CFG）和表达式。<br /> * 第二步，将合约代码转换成SlitherIR（一种内部表达码）。<br /> * 第三步，对SlitherIR执行一系列单一静态分析（SSA）来完成漏洞检测。</p> <p></p> <p>Solhint和Semgrep都是在语法级别进行规则匹配，相比而言Slither能在语义级别进行分析。Slither也可以通过[插件](https://github.com/crytic/slither/tree/ae7c410938b616d993e6c27678f6e48d9a4d7dd6/plugin_example)来实现自定义的漏洞检测规则，实现上要比Semgrep这种配置文件的方式复杂点。</p> <p>## 自检</p> <p>相对于自动检测工具而言，开发者的自检能完成更复杂的静态分析。比如</p> <p>“`solidity<br /> address[] public minters;<br /> function setMinter() external {<br /> minters.push(msg.sender);<br /> }<br /> “`</p> <p>静态分析工具没法知道修改`minters`这个状态变量需要什么权限，因为这属于业务逻辑的范围。再比如</p> <p>“`solidity<br /> if (a > 100) {<br /> b++;<br /> }<br /> “`</p> <p>如果开发者误将`a >= 100`写成了`a > 100`，这种业务逻辑错误静态分析工具也没法处理。</p> <p>合约的业务逻辑都是主要在接口中实现的，因此接口检查就很重要：</p> <p>* 参数是否有校验，尤其是需要注意是否有任意输入。<br /> * 接口必须是external或者public吗？如果把一个internal或者private接口暴露出去会非常危险。<br /> * 需要加payable吗？不加的话没法接收eth，但是若无必要则一定不要加。<br /> * 接口会修改状态变量吗？修改这些变量需要权限吗？这一点往往是静态分析工具无法检测到的漏洞。<br /> * 通过call或者delegatecall的调用对象是可信的吗？<br /> * 外部调用需要设置gasLimit吗？外表调用的返回结果需要处理吗？<br /> * 在有外部调用的代码前后遵守了Checks-Effects-Interactions规范吗？<br /> * 外部调用能重入到合约中的其它接口然后通过旁路回到本接口吗？</p> <p>如果接口涉及到Token的转移，则需要的检查有：</p> <p>* 如果Token转移过程中内部扣费会影响业务逻辑吗？<br /> * Token转移过程中会有钩子函数回调发送者或者接收者吗？<br /> * Token如果是可升级合约，对业务逻辑有影响吗？<br /> * 有使用地址的eth余额参与控制逻辑吗？eth的余额是可以通过挖矿或者selfdestruct强制增加的。</p> <p>对于借贷相关的合约，一般需要使用价格，则需要的检查有：</p> <p>* Offchain oracle是可靠的吗？<br /> * Onchain oracle的价格容易被操纵吗？<br /> * LP token的价格计算算法是正确的吗？</p> <p>总之，所有的检查都围绕几个核心：</p> <p>* 敏感的权限是否能被转移到任意地址<br /> * 资产是否有可能被较小的代价转走<br /> * 资产是否有可能无法取出</p> <p>## 结束语</p> <p>静态分析是相对容易掌握的工具，对开发复杂的Defi应用非常有帮助。不同的静态分析工具可以结合使用，可以先使用Solhint来规范代码，然后使用Semgrep来识别已知的漏洞，接着使用Slither来识别一些语义级别的问题。</p> <p>开发者更需要自己检查代码，最好是邀请同行互审。最后还是需要审计机构审计代码，不过也不要迷信审计机构，尤其是当Defi的业务逻辑比较复杂的时候，审计机构不一定能精确地理解每一个业务逻辑。

rules:
 -
    id: compound-sweeptoken-not-restricted
    message: function sweepToken is allowed to be called by anyone
    metadata:
        references:
        - https://medium.com/chainsecurity/trueusd-compound-vulnerability-bc5b696d29e2
        - https://chainsecurity.com/security-audit/compound-ctoken/
        - https://blog.openzeppelin.com/compound-comprehensive-protocol-audit/
        - https://etherscan.io/address/0xa035b9e130f2b1aedc733eefb1c67ba4c503491f # Compound
        category: access-control
        tags:
        - compound
        - tusd
    patterns:
    - pattern-inside: |
        function sweepToken(...) {
        ...
        }
    - pattern: token.transfer(...);
    - pattern-not-inside: |
        require(msg.sender == admin, "...");
        ...
    languages: 
    - solidity
    severity: WARNING

address[] public minters;
function setMinter() external {
    minters.push(msg.sender);
}

if (a > 100) {
    b++;
}

本文参与区块链开发网写作激励计划 ，好文好收益，欢迎正在阅读的你也加入。