智能合约的安全隐患有哪些（智能合约的安全隐患）

文章前言

本篇文章将对Lightcoin合约内transfeFrom授权转账函数的allowance不一致性问题和CountryCoin合约内transfeFrom的balance不一致性问题进行简单的分析介绍~

漏洞原理

Allowance不一致

合约地址：

https://cn.etherscan.com/address/0xd97579Cea3fE2473682a4C42648134BB982433B9#code

漏洞介绍：如下面代码所示，条件语句\\”require(_value <= allowed[_from][msg.sender]);\\”与后期更新语句\\”allowed[_from][_to] -= _value;\\”存在不一致问题，导致这里如果用户A给用户B授权转账后，用户B可以无限制的转走用户A的资产，直到转完账户的所有余额

balances不一致性

合约地址：

https://cn.etherscan.com/address/0x3b912fb1b5b9e07e50e43f0404fee038f9a0353c#code

漏洞介绍：如下面的代码所示，条件检测语句\\”require(balances[msg.sender] >= _value);\\”与\\”balances[_from] -= _value;\\”更新语句存在不一致性，攻击者能够通过溢出，让`_from`账户余额获得极大的token数量

漏洞复现

allowed 不一致性

首先，下载Lightcoin合约代码之后在本地Remix中进行部署调试(这里需要改一下合约中owner地址便于调试)，相关账户地址信息如下所示：

• 管理者：0x5B38Da6a701c568545dCfcB03FcB875f56beddC4

• 攻击者1：0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2

• 攻击者2：0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db

Step 1：以管理者身份调用approve函数给予攻击者1一定的转账额度

approve:\\\"0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2\\\",10000

交易记录信息：

Step :2：使用allowance 查看转账额度：

\\\"0x5B38Da6a701c568545dCfcB03FcB875f56beddC4\\\",\\\"0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2\\\"

此时此时攻击者2的余额为 0：

Step 3：:之后切换为攻击者1身份，并通过攻击者1使用transferFrom向攻击者2进行转账操作

transferFrom：\\\"0x5B38Da6a701c568545dCfcB03FcB875f56beddC4\\\",\\\"0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db\\\",10000

交易记录信息如下：

Step 3：攻击者1继续使用:transferFrom向攻击者2进行转账操作，仍然能转账成功，因为 allowed[_from][msg.sender]没有发生变化

transferFrom：\\\"0x5B38Da6a701c568545dCfcB03FcB875f56beddC4\\\",\\\"0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db\\\",10000

交易日志记录：

之后发现攻击者2的余额依然增加了:

通过此攻击，攻击者能够将 _from 账户里的所有余额转移到其它用户余额中，并且`allowed[_from][_to]`是溢出了的

allowance : \\\"0x5B38Da6a701c568545dCfcB03FcB875f56beddC4\\\",\\\"0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db\\\"

balances不一致性

首先，下载CountryCoin合约然后在Remix中进行部署分析调试(在构造函数中给msg.sender赋一些token)，相关地址如下：

• 管理者：0x5B38Da6a701c568545dCfcB03FcB875f56beddC4

• 攻击者1：0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2

• 攻击者2：0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db

Step 1：在这里我们首先通过管理者地址给攻击者1地址打一定数量的代币进去，来模拟攻击者1充值token：

0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2,100000000000000

交易日志信息：

之后攻击者1的地址所拥有的token数量为：

另一个攻击者2地址账户余额为0

Step 2：接下来我们的攻击就是让第二个账户溢出，之后使用攻击者2给予攻击者1一定的转账额度权限

approve: \\\"0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2\\\",10000

Step 3：切换回攻击者1，然后使用transferFrom向自己进行转账操作

transferFrom：\\\"0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db\\\",\\\"0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2\\\",10000

交易日志如下：

此时攻击者2地址上余额本来为0，但经过 “ 的减法计算下溢变为了一个极大值

修复方案

修复方法如下：

1、使用safeMath方法进行计算

2、使用balances[_from] >= _value作为条件判断而非 balances[msg.sender]

3、检查allowed[_from][msg.sender]并对allowed[_from][msg.sender]进行操作不要与allowed[_from][_to]混用