区块链安全相关的名词介绍

随着越来越的人参与到区块链这个行业中来，为行业注入新活力的同时也由于相关知识的薄弱以及安全意识的匮乏，给了攻击者更多的可乘之机。面对频频爆发的安全事件，慢雾特推出区块链安全入门笔记系列，向大家介绍区块链安全相关名词，让新手们更快适应区块链危机四伏的安全攻防世界。

短地址攻击（Short Address Attack）是针对以太坊上ERC20智能合约的一种攻击形式，利用的是EVM中的对于输入字节码的自动补全机制进行攻击。

一般而言，针对 ERC20 合约中的 transfer 函数的调用，输入的字节码位数都是 136 字节的。当调用 ERC20 中的 transfer 函数进行 ERC20 Token 转账时，如果攻击者提供的地址后有一个或多个 0，那么攻击者就可以把地址后的零省去，提供一个缺位的地址。当对这个地址转账的时候，比方说转账 100 的 A Token，然后输入的地址是攻击者提供的缺位地址，这时候，经过编码输入的数据是 134 字节，比正常的数据少了 2 字节，在这种情况下，EVM 就会对缺失的字节位在编码数据的末尾进行补 0 凑成 136 字节，这样本来地址段缺失的 0 被数据段的 0 补齐了，而由于给地址段补 0，数据段会少 0，而数据段缺失的 0 由 EVM 自动补齐，这就像数据段向地址段移动补齐地址段缺失字节位，然后数据段缺失的字节位由 EVM 用 0 补齐。这种情况下，转账金额就会由 100 变成 100 * 16 的 n 次方，n 是地址缺失的 0 的个数。通过这种方式，攻击者就能对交易所或钱包进行攻击，盗窃交易所和钱包的资产。

慢雾安全团队建议交易所和钱包在处理转账的时候，要对转账地址进行严格的校验，防止短地址攻击的发生。详情可参考：遗忘的亚特兰蒂斯：以太坊短地址攻击详解

假币攻击（Fake Token Attack），是针对那些在创建官方 Token 时采用通用创建模版创建出来的代币，每个 Token 的识别仅根据特定的标记进行识别，如 EOS 官方 Token 的识别标记是 “eosio.token”合约，波场的 TRC10 的识别标记是 tokenid，以太坊的 ERC20 是用合约地址作为识别标记。那么这样就会出现一个问题，如果收款方在对这些 Token 进行收款的时候没有严格校验这些 Token 特有的标记，攻击就会发生，以 EOS 为例子，由于 EOS 官方 Token 采用的是合约来发行一个名为 EOS 的 Token，标记 EOS 本身的标识是 “eosio.token” 这个发行帐号，如果在接受转账的时候没有校验这个标识，攻击者就能用其他的帐号同样发行一个名为 EOS 的 Token，对交易所或钱包进行假币充值，换取真的代币。

2019 年 4 月 11 日，波场 Dapp TronBank 1 小时内被盗走约 1.7 亿枚 BTT（价值约 85 万元）。监测显示，黑客创建了名为 BTTx 的假币向合约发起“ invest ”函数，而合约并没有判定发送者的代币 id 是否与 BTT 真币的 id 1002000 一致。因此黑客拿到真币 BTT 的投资回报和推荐奖励，以此方式迅速掏空资金池。对此，交易所和钱包在处理转账的时候，切记要严格检验各种代币各种标识，防止假币攻击。

数据的存储是区块链上重要的一环。但是每个数据类型本身是存在边界的，例如以太坊中 uint8 类型的变量就只能存储 0～255 大小的数据，超过了就存不下了。那么如果要放一个超过数据类型大小的数字会怎样呢？例如把 256 存进 uint8 的数据类型中，数据显示出来会变成 1，而不是其他数值，也不会报错，因为 uint8 本身能存一个 8 位二进制数字，最大值为 11111111，如果这个时候加 1，这个二进制数就变成了 100000001，而因为数据边界的关系，只能拿到后 8 位，也就是 00000001，那么数字的大小就变成 1 了，这种情况我们称为上溢。有上就有下，下溢的意思就是一个值为 0 的 uint8 数据，如果这个时候对它进行减 1 操作，结果会变成该数据类型所能存储的最大值加 1 减去被减数，在这个例子中是 255，也就是该数据类型所能存储的最大值。那么如果上述两种情况发生在智能合约当中的话，恶意用户通过下溢的操作，操纵自己的帐号向其他帐号发送超过自己余额数量的代币，如果合约内没有对余额进行检查，恶意用户的余额就会下溢出变成一个超大的值，这个时候攻击者如果大量抛售这些代币，就能瞬间破坏整个代币的价值系统。

慢雾安全团队建议所有的智能合约开发者在智能合约中对数据进行操作的时候，要严格校验数据边界，防止整形溢出攻击的发生。详情可参考：BEC 智能合约无限转币漏洞分析及预警。

条件竞争（Race CondiTIon）攻击的方式很多样，但是核心的本质无非是对某个条件的状态修改的竞争，如上期介绍的重入漏洞，也是条件竞争的一种，针对的是用户余额这个条件进行竞争，只要用户的余额没有归零，用户就能一直提走智能合约的钱。这次介绍的条件竞争的例子是最近发生的著名的 Edgeware 锁仓合约的拒绝服务漏洞，详情可参考：关于 Edgeware 锁仓合约的拒绝服务漏洞。这个漏洞问题的本质在于对新建的锁仓合约的余额的这个条件进行竞争。攻击者可以监控所有链上的锁仓请求，提前计算出锁仓合约的地址，然后向合约地址转账，造成锁仓失败。在官方没有修复之前，要防止这种攻击，只能使用比攻击者更高的手续费让自己的锁仓交易先行打包，从而与攻击者形成竞争避免攻击。最后，官方修复方案为不对锁仓合约的余额进行强制性的相等检查，而是采用大于等于的形式，避免了攻击的发生。

慢雾安全团队建议智能合约的开发者在智能合约中对某些状态进行修改的时候，要根据实际情况充分考虑条件竞争的风险，防止遭受条件竞争攻击。