应用于数字藏品的智能合约都有哪些安全风险？如何有效防范？

国内数字藏品在技术上与NFT并无太大差别，也是通过智能合约来实现业务逻辑，所以合约漏洞等安全问题在国内数字藏品上也会存在，我们需谨慎对待。下面我们就来看看数字藏品在智能合约实现中存在的安全问题和解决方案。

数字藏品与智能合约

什么是智能合约？  

为什么数字藏品的安全问题离不开对智能合约的讨论呢？因为，数字藏品在技术上是通过智能合约实现并运行的。在讨论数字藏品智能合约安全问题之前，我们先来看看什么是智能合约。

20世纪90年代，Nick Szabo首次提出智能合约的概念。当时，他把智能合约定义为通过结合协议与用户界面，规范和保障计算机网络安全的工具。

在区块链领域，智能合约可界定为运行在区块链中的应用或程序。简单来说，智能合约是一种确定性程序，会在满足某些条件时，强制执行特定规则来发挥作用。这些规则由计算机代码预定义，经所有网络节点复制和执行。

目前应用最广泛的基于以太坊的智能合约有着分布式、确定性、自主性、不变形、定制化、去信任化、透明性等特性。

为什么数字藏品会有智能合约安全风险？ 

因为，智能合约本身由人工编写的计算机代码组成，那么就不可避免的存在缺陷和漏洞风险。合约一旦部署不可修改、合约执行后不可逆、所有执行事务可追踪，而且区块链上的智能合约对所有用户可见，如果有漏洞被作恶者利用，将导致资产被盗且往往无法收回，给用户造成巨大损失。并且存在的安全问题可能无法迅速修复。

随着数字藏品等应用的爆火，区块链智能合约数量也与日俱增，随之暴露出来的安全问题也会越来越多。

为了避免安全事件的发生，保护用户的资产安全，就必须在最源头做好安全防范，提高数字藏品开发的安全意识。

接下来，就给大家介绍一些由智能合约特性导致的安全风险和对应的安全措施。

数字藏品智能合约主要安全问题有哪些？

经成都链安安全团队研究发现，数字藏品智能合约主要的安全问题有：重入漏洞安全问题 、随机数安全问题、整型溢出安全问题  、动态数组越界安全问题、函数权限配置错误安全问题、忽略返回值安全问题、空指针引用安全问题、访问外部资源安全问题、输入参数检查安全问题等，问题详细分析如下。

1、重入漏洞安全问题

数字藏品的业务场景中智能合约常常需要实现合约间的外部调用，这种方式主要的危险就是外部合约可以接管控制流，并调用函数对某些关键数据进行更改。尤其在solidity语言中，当用户直接向一个合约转账时会产生一个隐藏的fallback()外部调用，如果未对该调用进行限制则可能会产生重入漏洞。

重入攻击首次出现于以太坊，对应的真实攻击为 The DAO 攻击，该攻击还导致了原来的以太坊分叉成以太经典(ETC)和现在的以太坊(ETH)。

成都链安安全团队对此建议：

1、 更改状态变量时采用官方推荐的检查-生效-交互模式；

2、 使用互斥锁：添加一个在代码执行过程中锁定合约的状态变量，防止重入调用；

3、 对可能产生的外部调用操作本身进行限制；

2、随机数安全问题  

随机数在数字藏品中的应用十分广泛，如为艺术类数字藏品随机分配属性，为游戏类的藏品分配宝藏位置，以及保障限量版藏品空投的公平性等。

不同区块链开发语言中生成随机数的方式也多种多样，例如Go使用math/rand、Java使用java.util.Random类等。而在Solidity中由于没有原生的生成伪随机数的函数，所以部分开发者常采用区块参数替代。

但上述随机数的生成方式都存在安全缺陷，当开发者使用可被预测的随机数种子生成随机数时，攻击者就可以根据对应的算法获取到即将出现的随机数，实现随机数预测，达到攻击目的。

成都链安安全团队对此建议：

随机数的来源尽量来自于区块链之外，这可以在具有诸如commit-reveal之类的系统的对等体之间完成，或者通过将信任模型改变为一组参与者来完成。

3、整型溢出安全问题  

数据的存储是区块链上重要的一环，而执行合约的虚拟机（EVM）为各类整数都指定了固定大小的存储宽度。这意味着一个整型变量只能由一定范围的数字表示。

所以在代码实现时，如果没有检查用户输入就执行算术运算，可能会导致数值超出存储它们的数据类型允许的范围，产生数值溢出的问题。

具体的溢出类型包括乘法溢出、加法溢出、减法溢出、指数溢出等。例如，Solidity中 uint8 只能存储大小在[0,255] 的数值。当试图存储 256 到一个 uint8 时将溢出变成0。而Go语言中使用make()进行内存分配时，如果发生溢出使得该值为0或最大值时，将导致内存分配失败。攻击者常利用该漏洞达到绕过转账条件、操纵内存、破坏堆栈的目的。

成都链安安全团队对此建议：

在进行整数算术运算之前先进行校验，或者使用一些算术安全的第三方库。如：OpenZeppelin提供了一套很好的SafeMath库，使用SafeMath库函数能够有效避免四则运算溢出漏洞。

4、动态数组越界安全问题  

对于数组越界这种严重的内存错误，不同的区块链开发语言有各自的特点。

Java、Solidity、Go语言等跟其他大部分编程语言类似，在编译期间会进行数组越界检查。特别的是，在Solidity语言中动态数组将首先在变量定义处的虚拟机插槽位置存储数组元素数量，之后根据该插槽位置的Keccak256值和下标位置计算特定元素值的存储位置。

所以当动态数组下标是用户可控的且数组长度不受限的情况下，攻击者可以根据虚拟机的插槽深度构造对应的参数，使得参数指向虚拟机中的任意内存位置，从而修改对应插槽的状态变量。

成都链安安全团队对此建议：

在合约中访问数组时，应当校验参数合法性，即是否超过数组长度。

5、函数权限配置错误安全问题  

函数是区块链智能合约中的一个重要组成部分，而函数的权限控制决定了其是否可以被用户或其他派生合约在外部调用，或仅在内部调用。

不同的语言同样拥有不同的函数权限声明方式，如：Solidity中可以使用四种可见性修饰符public 、private 、internal、external直接规定调用权限，同时也可以采用modifier实现对某些特权函数的严格权限控制。而go语言则采用函数首字母的大小写声明权限。

如果这些函数权限修饰符被开发者误用，则会导致一些特殊功能的函数被攻击者调用，造成诸如随意更改藏品数量等严重后果。

成都链安安全团队对此建议：

区块链上涉及到合约中修改状态变量的操作，必须对函数的调用权限进行严格控制。尤其涉及到一些重要属性修改时，应当配置仅合约拥有者可以调用的权限。

6、忽略返回值安全问题  

合约中的重要函数通常都有返回值，该值用于判断函数操作是否执行成功，并对执行失败的情况做出错误处理。

区块链上合约的调用是通过交易实现的，交易产生的回执中status字段有两种结果：0x1(true)、0x0(false)。但是交易是否成功仅取决于交易事务执行过程中是否抛出了异常，所以可能会出现函数执行失败返回false，但是交易仍然是成功执行的情况。

因此如果区块链开发人员采用链上交易回执替代函数返回值，并将其作为业务逻辑是否执行成功的判断依据，就可能造成意想不到的安全问题。

成都链安安全团队对此建议：

区块链上涉及到函数返回值的判断，除了判断交易事务回执外，还应该再次判断涉及到的状态变量是否更改。

7、空指针引用安全问题  

指针是区块链开发中一种重要数据类型，用于表示复杂的数据结构、动态分配内存等。其中空指针是一个已经声明但未指向任何一个有效对象的指针。

所以在Go、Java等语言中，当试图对空指针进行解引用操作时，可能会导致拒绝服务攻击或者程序异常中断。特别的是，在Solidity中EVM存在两种数据存储的位置，分别是Storage和Memory。而未初始化的Storage类型局部变量默认值为0x0，所以这可能指向合约中的其他状态变量。

如果该未初始化的变量可控，攻击者可以利用该变量修改合约中对用插槽的状态变量，从而造成严重后果。

成都链安安全团队对此建议：

Remix-ide等编译器会对未初始化的存储器局部变量进行告警，在声明变量时应对这些存储器局部变量进行初始化，避免安全漏洞。

8、访问外部资源安全问题  

区块链开发人员为了提升开发效率和保障安全性，同样会引入第三方库等外部资源，这些第三方库代码可能会存在安全缺陷，导致合约出现意想不到的问题。即使第三方库本身不存在安全问题，也可能造成安全隐患。

如在solidity中，如果引入的合约代码中包含状态变量，而调用者又采取delegatecall的方式调用则会因为参数存储位置的不一致而导致变量覆盖或者异常终止的问题，影响正常的业务逻辑。同时无漏洞合约在某些情况下也可以以恶意行为的方式进行部署，造成严重的安全问题。

成都链安安全团队对此建议：

1、开发人员应该谨慎使用第三方库代码。同时使用无状态的库代码，并且避免使用代理调用的方式。

2、如果引用的外部合约地址已知的话，可以对引用合约的地址进行硬编码。

9、输入参数检查安全问题  

虽然区块链开发中编译器会对参数的合法性进行检查，但是开发者同样需要对每个函数的输入参数进行预期检查，使其符合业务逻辑。尤其涉及到一些包含特权操作的函数时，如：solidity中的call()函数，当该函数参数中的方法选择器用户可控，而EVM具有不校验参数个数的特性，所以就可能造成代码执行漏洞等严重后果。

成都链安安全团队对此建议：

开发人员应对特函数作进行权限校验，包括函数调用者的身份验证，或者使用诸如private、internal等函数修饰符对函数本身进行权限控制。

数字藏品智能合约安全如何防护？

以上，只列出了基于区块链的数字藏品智能合约，在开发过程中存在的主要问题和成都链安安全团队的建议，数字藏品开发者在开发过程中需注意上述问题。

但是为了确保数字藏品的安全，在进行数字藏品智能合约部署前，最好是寻求第三方专业的安全公司进行合约安全审计，由专业的人做专业的事。

为了护航Web3.0安全生态，最近我们使用链必验—智能合约形式化验证平台对上千个NFT项目进行漏洞扫描，发现不少的NFT项目都存在安全漏洞风险，如：业务逻辑相关问题、代码规范相关问题等。而且大多数NFT项目都没有进行安全审计，这就存在很大的安全隐患，容易导致攻击事件的发生，造成资产的损失。

本文链接：应用于数字藏品的智能合约都有哪些安全风险？如何有效防范？ | 巴比特