最近，我们在审计客户合约时发现：EOS代币合约存在整型溢出等问题，部分合约实现不够严谨。

具体包括：

整型溢出错误；

权限检查不严谨；

API函数的不规范使用；

常规代码错误。

为了使开发者在合约开发中不掉进坑里，我们接下来就一一对上述问题进行分析。并且给出合理的解决办法，让开发者不至被黑客利用。

让我们直奔主题。

问题出在EOS的代币合约

这次漏洞的主要原因，在于EOS的代币合约有不严谨之处，主要体现在以下4个方面：

1.整型溢出错误

使用自己的数据结构描述代币，对代币数值进行算数运算时未进行安全检查。在误操作时容易产生整型溢出错误，可能导致代币量归零甚至变成负数的严重后果！

2.权限检查不严谨

权限检查不严谨，造成逻辑漏洞。部分代币合约设置了「冻结账户和代币」的功能，然而用户们却将检查「冻结」的代码放在transfer（转账）函数中，从而导致执行issue（发行代币）的时候不受「冻结」状态影响，可以任意增发代币。

3.API函数的不规范使用

这里指的是开发者要注意EOS API函数的参数类型。

例如：string_to_symbol（uint8_t,const char*），

第一个参数传入的整型变量需要小于256，若使用该API前未对输入进行检查，则可能导致整型溢出，从而导致操作了错误类型的代币，带来严重后果。

4.常见代码错误

数据库API使用不严谨，如multi_index中提供的get和find。其中get会检查数据是否查询成功，数据未找到则断言退出，而find不会检查数据查询情况，需要用户自行判断，如果缺少判断直接使用将会导致指针使用问题。

不要慌！关键时刻拿走这三根救命稻草

既然EOS代币合约存在不严谨之处，那么作为项目方应该如何去防范后期可能造成的风险呢？我们给出下面三种建议方法。

第一，合约中使用官方提供的asset数据结构描述代币，对代币的算数运算同样利用asset完成。

第二，在使用multi_index的find函数时，一定要进行返回值的检查。

第三，对所有输入都通过断言检查有效性，调用API函数前，检查参数类型和大小。

最后，建议代币合约参照EOS官方给出的eosio.token示例进行实现，避免疏忽而导致的安全检查不完备。

此漏洞应引起开发者重视

虽然目前EOS代币合约还没有上线，但是项目方一定不能掉以轻心，反而应该时刻记住BEC这类事件的惨痛教训，避免重蹈覆辙，以及整型溢出问题引发的代币被盗事件的发生。

总体而言，我认为从目前审计EOS代币合约所遇到的问题来看，开发者在合约敏感代码（如操作代币数额）前后，一定要做好参数限制和权限检查，使用EOS API时一定要搞清楚该函数的输入限制和返回值形式，同时多多参考官方的示例实现。

另一方面，智能合约安全是整个区块链行业的基础设施最底层的保障，项目方合约开发完成后进行安全审计也是很有必要的，从多角度分析合约代码，找出那些容易忽略的问题，并且做到防患于未然。