Transfer(msg.sender,_to,_value);
returntrue;
}else{returnfalse;}
}
上述代码可能会导致假充值。
正确代码如下:
functiontransfer(address_to,uint256_amount)publicreturns(boolsuccess){
require(_to!=address(0));
require(_amount<=balances[msg.sender]);
balances[msg.sender]=balances[msg.sender].sub(_amount);
balances[_to]=balances[_to].add(_amount);
emitTransfer(msg.sender,_to,_amount);
returntrue;
}
2、设计缺陷问题
(1)approve授权函数条件竞争
approve函数中应避免条件竞争。在修改allowance前,应先修改为0,再修改为_value。
这个漏洞的起因是由于底层矿工协议中为了鼓励矿工挖矿,矿工可以自己决定打包什么交易,为了收益更大,矿工一般会选择打包
gasprice更大的交易,而不会依赖交易顺序的前后。
通过置0的方式,可以在一定程度上缓解条件竞争中产生的危害,合约管理人可以通过检查日志来判断是否有条件竞争情况的发
生,这种修复方式更大的意义在于,提醒使用approve函数的用户,该函数的操作在一定程度上是不可逆的。
functionapprove(address_spender,uint256_value)publicreturns(boolsuccess){
allowance[msg.sender][_spender]=_value;
returntrue
上述代码就有可能导致条件竞争。
应在approve中加入
require((_value==0)||(allowance[msg.sender][_spender]==0));
将allowance先改为0再改为对应数字
(2)循环Dos问题
[1]循环消耗问题
在合约中,不推荐使用太大次的循环