区块链里的智能合约安全

Posted 2020-11-10

写在开头

    在我写这遍文章的时候，距离EOS曝出漏洞已经有三天时间，区块链行业热点来的快去的也快，每每出现安全相关问题，都会给整个行业带来震荡。自从我开始关注区块链行业以来，安全事故有增无减，交易平台、智能合约、共识机制等等都成了安全事故的中心。

    但是近年来，智能合约明显已经被×××死死盯上了。从前年的THE DAO再到今年的BEC。与此同时网上也出现了很多不同的声音，有人为智能合约的巧妙性叫好，有人也为智能合约的安全性唱衰。本文不会对智能合约本身优劣进行探讨，只针对如何保证智能合约安全来进行深入，欢迎留言讨论。

第一部分：智能合约基本原理

    智能合约本质是一段运行在区块链网络中的代码，它完成用户所赋予的业务逻辑。通俗的来说，相当于是一个“不可改变”且“公正”的“中间人”。举一个例子，我跟你打一个赌，如果明天下雨，算我赢，如果明天没下雨，就是你赢了。然后我们在打赌的时候就把钱放进一个智能合约控制的账户内，第二天过去了，×××的结果出来了以后，智能合约就可以根据收到的指令自动判断输赢，并进行转账。这个过程是高效，透明的执行过程，不需要公正等第三方介入。

    比如我们熟悉的以太坊，它的智能合约业务逻辑就是代币发币和交易。以太坊在设计之初，将智能合约设计成了一旦部署就不能修改的模式。这种设计是为了提高智能合约的可信性。但是只要是人编写的程序，不可避免的就会产生漏洞。所以，当有漏洞出现时，想要再挽回损失就很大了。

第二部分：智能合约安全

    前面讲到，智能合约本质就是一段代码，并且发布之后不可修改。若在发布之后发现了严重的漏洞，就只能重新部署新的合约，这对厂商来说代价太大了。那么要想这段保证代码的安全，就一定要在发布之前对智能合约进行代码审计。除开需要第三方的代码审计之外，团队在开发的过程中，也是有方法可以用来提高智能合约的安全。

1.  代码一定要测试！

2.  代码一定要review！

    不要看小看这简单的两点，绝大多数的代码问题都能在这个过程中发现。下面我将白帽安全研究院给出的如何避免开发业务层代码安全问题放在下面。有需要的可以一一对应对自己的代码做一个审核。

1.   尽量避免外部调用?

2.   仔细权衡再发生重要操作时的代码逻辑，避免逻辑陷阱

3.   处理外部调用错误?

4.   不要假设你知道外部调用的控制流程?

5.   标记不受信任的业务内容?

6.   正确的使用断言?

7.   小心整数除法的四舍五入?

8.   不要假设业务创建时余额为零

9.   记住链上的数据是公开的?

10.  在双方或多方参与的业务应用中，参与者可能会“脱机离线”后不再返回

11.  明确标明函数和状态变量的可见性

12.  将程序锁定到特定的编译器版本

13.  小心分母为零?

14.  区分函数和事件?

15.  避免死循环?

16.  升级有问题的业务层代码

    除了自己对代码的审核外，请第三方安全机构进行审核也是很必要的。智能合约审计严格意义上上来说，是应该有个非常规范的流程。一半情况至少会对以下四点进行审核：

1. 函数可见性审核

2. 合约限制绕过审核

3. 调用栈耗尽审核

4. 拒绝服务审核

    通过这四点的审核，至少能把隐私泄露、交易溢出与异常、合约故障和拒绝服务的问题解决。大大减少智能合约带来的安全风险。

第三部分：第三方智能合约审计

    目前有提供智能合约审计和代码审计的安全公司还不太多，我从平时看的一些快讯里收集到，列出目前比较出名的几家在做智能合约审计的安全厂商，供大家参考。

• 知道创宇：为火币、Bit-Z提供了合约代码复查服务和云防御服务。

• 慢雾科技：为EOS提供节点安全部署和安全审计。

• 360:据悉曝出EOS漏洞后开始参与代码审计。

• 白帽汇：目前暂不知晓与谁合作。

写在最后

本文只是对智能合约和智能合约审计做了一个非常浅薄的分析。并且区块链行业安全问题牵扯到了方方面面。智能合约只是里面的一小部分，后续会继续写一些区块链行业其他的安全问题，欢迎一起探讨。