原文pdf:http://www.owasp.org.cn/owasp-project/copy_of_TOP102019_V1.0.pdf

1、前言

近几年，区块链技术的发展非常迅猛，安全形势也越来越严峻，仅安全事件导致的直接经济损失就高达35亿美元，很多公司甚至因此倒闭，给行业带来了巨额的经济损失和惨痛的教训。基于此，OWASP中国成立专门研究小组，收集、整理和分析了2011年至2019年间共160 个典型区块链安全事件，并在本文档中给出了排列和描述，希望能帮助到广大的区块链从业者和关注区块链安全的人们。 在参考了类似CVSS（Common Vulnerability Scoring System）等安全威胁评估方法之后，本文以每类威胁历史安全事件所导致的直接经济损失总额为依据，通过客观数据评估威胁大小。直接经济损失总额包含了威胁评估的两个重要因素，一是威胁发生的数量（即威胁发生的次数）；二是威胁发生导致的影响（即直接经济损失）。使用直接经济损失表示威胁的大小的好处是， 数据相对客观，避免了主观数据导致评估结果误差较大问题，同时，这种评估方式更具有良好的解释性。 阅读本文档时需注意以下三点：（1）安全事件导致的经济损失以案件发生时的虚拟币价格计算；（2）统计分析过程中只计算了直接经济损失，未计算间接经济损失；（3）24.3%的安全事件（39个）未公布经济损失，因而未计入损失统计。 

 

2、高级可持续威胁

2.1 风险描述

高级可持续威胁类问题往往出现在区块链领域的中心化团队上，比如：交易所、钱包、矿池等。由于这些区块链团队在基础设施安全建设和安全运营上的欠缺，导致基础设施存在安全漏洞，从而被攻击者利用，实施数字货币的盗窃或者破坏。 

2.2 危害描述

高级可持续威胁会导致区块链系统被入侵，权限被控制，最终导致资金被盗取，敏感数据被泄露等系列严重问题。在2008-2018年间，就共有 37起高级可持续威胁类安全事件，导致的直接经济损失高达16亿美元，是区块链领域的第一大威胁。 

2.3 实际案例 

案例1-1： 
Mt.Gox 是区块链领域最著名的入侵事件之一。早在 2011年6月，Mt. Gox 交易所就遭到黑客攻击。据称，该公司的一名审计人员的电脑受到了攻击，黑客利用这台电脑访问比特币交易所的内网，人为的将比特币的名义价值修改为1美分，然后从该交易
所的客户账户转移了大约2000枚比特币。2014年，Mt.Gox遭受了更严重的黑客攻击，近85万的比特币被盗窃，攻击手法并没有被披露，但据Mt.Gox内部人员透露，其存在内部组织不一致、程序安全性不佳、网站源代码泄露等严重的问题。甚至有黑客怀疑他们是监守自盗，事后又渗透进去，可见安全性很差。这次的事件导致它们近4.6亿美元的损失，并最终走向破产，CEO也受到法律的制裁。 

案例1-2： 
Coincheck是另一起著名的区块链领域入侵事件。Coincheck将钱存入热钱包，而且不实行多重签名系统，最终导致了黑客有机可乘，该平台全部5.26亿NEM币（新经币）被非法转移。根据估算，这批丢失的新经币价值高达5.23亿美金，这是目前历史上最大规模的数字货币盗窃案。 

案例1-3： 
Fomo3D 以及类似的游戏（Lastwiner, FomoGame 等）遭受到的攻击是另一类基于以太坊合约的 APT，可以称之为BAPT (区块链高级持续威胁)。 BAPT 的概念于 2018年提出，区别于传统网络安全的 APT 在于，其攻击目标是区块链的基础设施，智能合约等。值得一提的是，很多加密货币交易所遭受的攻击，属于传统 APT 范畴。BAPT 攻击是需要长时间的，使用特定的合约不停的跟受害合约进行交易（内部交易），对受害合约进行扫描，发现其漏洞。然后改进针对其漏洞的攻击合约。 下图中显示的多笔失败交易就是攻击者的攻击合约漏洞产生的： 

等到受害合约开始拥有一定数量的用户，同时奖励和资金池开始增长以后，便开始大规模的部署和运行攻击合约，利用用受害合约的漏洞获得高概率的回报。 

更多信息请参考此链接：https://www.chaindd.com/3107866.html 

 

2.4 修复方案

不管是交易所、钱包，还是矿池等团队，都需要高度重视产品安全、办*全和内部风险管理等安全方面的建设。产品安全可以参考OWASP S-SDLC项目提出的最佳安全实践；而办*全侧重入侵检测和数据防泄漏，市场上Top 5的安全供应商都可以给出较好的方案；另外，内部的风险管理也都要尽快的建立和完善。 另外游戏开发者需要对玩家进行评估，区别机器玩家，合约玩家等非正常类型的玩家，这些非正常类型的玩家有很大的概率是用来对一个合约进行漏洞扫描和分析的，游戏开发者应该持续分析数据，评估可能存在的风险，及时作出防护，以降低安全风险。
 

3、失控的币值通胀 

3.1 风险描述

比特币及其他区块链虚拟货币吸引大家的一个主要原因是其限定了铸币总数，从而避免了法币通胀和持币者长期承受经济损失。但若铸币总数限制部分的程序设计和实现有漏洞，则可能导致铸币总数失控，甚至超出设定发币总数多倍，致使币值失控通胀。

3.2 危害描述

比特币及其他区块链虚拟货币吸引大家的一个主要原因是其限定了铸币总数，从而避免了法币通胀和持币者长期承受经济损失。但若铸币总数限制部分的程序设计和实现有漏洞，则可能导致铸币总数失控，甚至超出设定发币总数多倍，致使币值失控通胀。 
 

3.3 实际案例

案例2-1： 
币值通胀类最典型的案例就是BEC 安全事件。BEC 主要由于币值控制部分的代码出现了整数溢出漏洞，导致出现无限铸币的情况。出现问题的代码如下图所示，红色框中的_fee与_value参数分别代表转账费用和转账金额，这两个参数都可以由攻击者控制。作者的本意是希望通过这行代码检查账户的余额是否足够支付转账金额和转账费用，如果不够支付则退出函数不进行支付操作。但当_value 的值足够大（比如_value=2^256-1），以至于_value+_fee会产生上溢，_value+_fee的值等于0，这样绕过了代码的检查，仍然会实施支付操作。而实际转账的Transfer函数不再检查余额是否足够，以至于value=2^256-1时，Transfer(_from,_to,_value)也可以转账成功，攻击者凭空获得大量的数字货币。

3.4 修复方案

对整数溢出漏洞导致的币值通胀问题，建议使用安全的算术函数做加减乘除处理。对币值控制的代码应该谨慎安全的处理。  https://ethereumdev.io/safemath-protect-overflows/ 

 

4、失效的权限控制 

4.1 风险描述

由于权限控制在设计或编码过程中的疏忽和缺陷，导致本来应该限制使用范围的重要函数或权限没有控制好范围，从而被攻击者调用这些重要函数或者使用权限实施攻击。  
 

4.2 危害描述

过去7年时间里，权限控制失效类问题导致的区块链安全事件共有6起，但导致的直接经济损失达2.02亿美元。其中，最著名就是以太坊钱包Parity的库权限没有控制好，被越权调用初始化函数，重置了钱包的所有者，导致了1.68亿美元的直接经济损失。  

 

4.3 实际案例

案例3-1： 
导致Parity钱包用户损失 1.68亿美元的就是下面这几行代码，开发者不应该把初始化函数设置为public，让其它合约也可以调用。攻击者利用了这个漏洞将钱包的所有者修改，以致用户损失巨大。 
function initContract() public {     owner = msg.sender; }  
更多详细的介绍可以参考下面的链接： 
https://www.parity.io/the-multi-sig-hack-a-postmortem/ 

案例3-2： 
另一种情况是编译器漏洞，如果在编写构造函数过程中不注意也会导致越权调用。在小于0.4.22版本的solidify编译器语法要求中，合约构造函数必须和合约名字相等，名字受到大小写影响。如： 
contract Owned {     function Owned() public{     } 
 

而在0.4.22版本以后，引入了constructor关键字作为构造函数声明，但不需要

function 
contract Owned {     constructor() public {     } 
 
如果没有按照对应的写法，构造函数就会被编译成一个普通函数，可以被任意人调用，会导致owner权限被窃取等更严重的后果。更多详细的介绍可以参考链接：https://paper.seebug.org/741/ 。

 

案例3-3： 
Call是最常用的调用方式，调用后内置变量 msg 的值会修改为调用者，但执行环境为被调用者的运行环境，如果合约中有函数以 msg.sender 作为关键变量的代码逻辑，比如向msg.sender 转账，那么就会导致越权操作，引发安全问题。如下代码所示，withdraw() 函数设计的初衷为只能有合约拥有者和合约本身可以发起取款的操作；但由于call 的问题，只要用户精心拼接字符序列调用 call，从而调用 withdraw() 函数，就可以绕过 isAuth() 并取款。 
function callFunc(bytes data) public {     this.call(data); 
    //this.call(bytes4(keccak256("withdraw(address)")), target); //利用代码示意 } 
 function withdraw(address addr) public {     require(isAuth(msg.sender));       addr.transfer(this.balance); } 
 function isAuth(address src) internal view returns (bool) {     if (src == address(this)) {        //检查是否合约拥有者或合约本身 
        return true;     }     else if (src == owner) {         return true;     }     else {         return false;     } } 

4.4 修复方案

1、对初始化等重要函数不要设置为pubic权限，以致可以被外部调用。 
2、要注意构造函数编写方式，以免被编译成普通函数，可以被任意调用。 
3、注意call等的调用对msg 的改变，以免导致绕过验证环节，被越权执行函数。 
4、参考OWASP ProActive Controls 项目中有关访问控制的内容。 
5、参考OWASP ASVS项目中有关访问控制的内容。 
6、参考OWASP 测试指南项目中有关认证测试和授权测试的内容。 

 

5、不安全的共识协议 
 

5.1  风险描述 

共识协议由于存在某些设计之初未考虑到的漏洞，导致 漏洞可能被攻击者识别和利用，从而损害链上参与者的利益。 

 

5.2 危害描述 

在总共160 个安全案例中，有15%（24个）是共识机制漏洞导致的安全事件，远高于本Top 10中其它类型的安全事件，可见这类漏洞是攻击者最为关注的。导致的直接经济损失为3823万美元，与被攻击的区块链规模较小，使用范围较窄有关，往往处于在虚拟或还没发展壮大的时候（比如：Krypton）或者是衰落的时候（比如：ETC）。共识机制本身的健壮性受到了很大的影响，容易被攻击。 在共识类案例中，以51%共识攻击最为常见。而不同类型的共识协议在面对 51%攻击的抵抗力又有所差别，虽然POW 和POS 两共识协议在规模较小时都容易被攻击，但是POW 类共识协议比POS类更容易被攻击，从攻击的角度来看，租用51%算力的成本往往比控制51%权益的成本更低，更可控.

5.3  实际案例 

案例4-1： 
Krypton是一个基于以太坊的区块链，2016年8月的时候被51%攻击了，这次的攻击分为两部分，一部分用至少51%的算力回滚交易，以实现同一个币支付两次；另一部分是用DDOS攻击网络中的多个节点。这次攻击者从Nicehash 租用额外的哈希能量，并且至少租用了4个矿池来实施攻击。我们由此可以看到，矿池的出现让算力实现了中心化，同时这些算力资源还是可以被任意租用的，这也使得攻击门槛大为降低。因此相比POW类共识协议，一般来说POS类共识协议更为安全。 更多详细的介绍可以参考链接：
https://cryptohustle.com/krypton-recovers-from-a-new-type-of-51-network-attack .

 

案例4-2： 
2019年1月，ETC遭到 51% 算力攻击。各大交易所（Coinbase，Gate.io，Bitrue 等）都报导出现双花的交易。（在51% 算力攻击中还有一个关键概念是所谓的网络重组（Block Reorganization），就是网络中六到八个块甚至更长的块都已经被矿工挖出
来了，但是这些块突然全部被移除，产生了一些新的块去代替这些已经被确认过的块。）黑客在一个网站上租用到一定规模的算力（超过51%），然后向 ETC 网络发起攻击，利用网络重组之前的块往交易所进行两笔数额较大的充值，赶在网络重组之前把币兑现，然后使用自身超过51%的算力算出新的块来代替已确认的块以及块中的交易，使得那些被替换的块里的交易无法追溯。 
 
 

更详细的内容请参考以下链接： https://medium.com/@AnChain.AI/anchain-ai-partners-with-bitrue-exchange-to-secure -blockchain-ecosystem-945580d1dd3f https://www.bishijie.com/shendu_16552 .

 

5.4 修复方案

51%的攻击会让交易所等参与交易的对手方损失惨重。针对交易所，建议提升提款前的确认次数，比如：Krypton就将他们的提款时间增加到了1000次确认。 对共识协议来说，小规模的POW类数字货币，以及权益集中度高的POS类数字货币容易更容易受攻击，总体来说POW比POS更容易被攻击，建议根据具体的业务场景，谨慎选择共识协议。

 

6、考虑不充分的程序逻辑 

6.1 风险描述 

由于软件设计和编码的错误原因，存在没有考虑到的异常分支，导致程序逻辑可以被攻击者利用，以至于陷入设计者未预期的流程，造成重大损失。 

6.2 危害描述 

很多区块链安全研究者都把这类会导致重入的程序逻辑问题列为头号风险，主要还是因为当年的The DAO事件（损失 6000万美元）影响太大。不过，除了 2016年的The DAO 事件外，此后并没有发生其它有比较严重损失的案例，其它的4个案件总共也只损失不到7.14 万美元，这就是我们把这类事件只排在第 5的原因。 

6.3 实际案例

案例5-1： 
以The DAO事件为案例，首先要介绍两个背景知识，ETH智能合约的发送过程和fallback函数。ETH智能合约发送过程，在智能合约中用代码向某个地址（这个地址可以是人，也可以是智能合约）发送以太币，比较常见的两个方式是：一是调用 send函数，比如msg.sender.send(100)；二是使用 message call，msg.sender.call.value(100)。这两个方式不同的是发送的gas 数量。当调用send方法时，只会发送一部分gas，一般是2300gas，一旦 gas 耗尽就可能抛出异常。而使用message call的时候，则是发送全部的gas，执行完之后剩余的gas 会退还给发起调用的合约。fallback函数，智能合约中可以有唯一的一个未命名函数，称为fallback函数。该函数不能有实参，不能返回任何值。如果其他函数都不能匹配给定的函数标识符，则执行fallback函数。当合约接收到以太币但是不调用任何函数的时候，就会执行fallback函数。 
如下两段代码是有重入漏洞的合约Bank和攻击合约 Attack，攻击实施的基本流程
如下： 
（1）假设 Bank合约中有 100wei，攻击者Attack合约中有10wei； 
（2）Attack合约先调用deposit方法向 Bank合约发送10wei； 
（3）之后 Attack合约调用withdraw方法，从而调用Bank的withdrawBalance； 
（4）Bank的withdrawBalance方法发送给了Attack合约10wei； 
（5）Attack收到10wei之后，又会触发调用fallback函数； 
（6）这时，fallback函数又调用了两次Bank的withdrawBalance，从而转走了
20wei； 
（7）之后 Bank合约才修改 Attack合约的 balance，将其置为0。 
 
从这个攻击流程中，我们可以看出，出问题的地方在4-7这几个步骤，开发者原本预期步骤4完成后就会到步骤7，没有预料到中间还有5-6的fallback处理这个流程，以至于攻击者可以构造编写 fallback代码，让处理流程走入异常分支，实现递归调用，直到gas 耗尽。

 

6.4 修复方案

注意代码中像fallback一类的隐含分支，避免处理逻辑出现异常。在编写智能合约进行以太币发送的时候，使用send或者transfer，不要使用message call的方式。更多详细的信息可以参考如下链接： 
https://blog.csdn.net/u011721501/article/details/79450122 

 

7、不严谨的业务策略 

7.1  风险描述 

目前比较突出的一种业务策略类问题是利用高额的以太费用和技术手段让以太坊堵塞，从而获得游戏中的大奖。但根据场景不一样，会有许多不一样的业务问题，这些也都会对产品的公平性，乃至产品的生存造成重大影响，需要特别注意！ 

7.2 危害描述

目前各类区块链游戏是人气比较高的，因为区块链的去中心，更有利的确保了游戏规则公正公平，吸引了不少玩家。但如果业务策略设计有漏洞，就容易导致公平性丧失，游戏奖励被特定的人利用漏洞来获得。2018年共发生了 2起业务策略漏洞类的安全事件，共导致了359 万美元的直接经济损失，都发生在 FOMO3D上。 

7.3 实际案例

案例6-1： 以FOMO3D为例，其游戏规则如下： 
（1）规则 1：最后一个购买KEY 的人获得奖池中的大奖； 
（2）规则 2：每有人购买一个KEY，倒计时时间会增加30 秒； 
（3）规则 3：游戏启动后从24小时开始倒计时。 
曾经，大部分人都认为这是一个不可能结束的游戏，因为一旦快到倒计时结束的时候就会很多人蜂拥而至去购买KEY。但是 2018年8月22日下午14点48分，这个游戏终止了，一个地址获得了共291 万美元的奖励。那么他是怎么获得的呢？是因为运气好，刚好在他购买之后没有其他人购买了，还是其它原因？分析认为这位获奖者是一位黑客，他在自己购买KEY 后，使用高额的以太费用和技术手段让以太坊堵塞了3分钟，进而使得其他玩家无法打包购买KEY 的交易，最终等到了倒计时结束，获得了最后的大奖！所以当业策略设计时不考虑到以太坊网络是有可能被人为的拥堵住的话，你就可能付出和这个案例一样的代价。同时也让这个游戏没落和失败。更多详细的介绍可以参考如下链接： 
https://mp.weixin.qq.com/s/s_RCF_EDlptQpm3d7mzApA 
https://www.bcsec.org/index/detail/id/285 

7.4 修复方案

由于目前的几个主要公链的性能都比较差，使用很少的成本就能让交易网络阻塞，所以在设计业务策略的时候一定要考虑这些因素，攻击可能让交易出现阻塞和回滚，以至于影响游戏公平性。
 

 

8、校验不严格的交易逻辑 

8.1 风险描述 

交易的校验逻辑不够严密，以致攻击者可以构造假的交易行为，但却被校验方验证通过，误认为真的交易行为。或者提交了真的交易操作，但是通过时间差，黑名单等因素，让交易操作产生回滚来实现，实际上的交易动作并没有完成，而商家仅验证是否有交易行为的话，就可能导致资金上的损失。 

8.2 危害描述

这里问题通常包含两大类——假转账类问题和回滚类问题，截止2019年1月共发生了26起，损失金额233.72万美元，大多数在于校验方的校验逻辑存在问题，从而可以被攻击者绕过校验，以假的充值行为却获得真实的数字货币入账；或者通过时间差，黑名单等因素让之前的交易操作回滚，从而欺骗商户获得商品。从古典互联网的安全案例来看，这类漏洞很常见，也是容易造成大额经济损失的漏洞，预计在区块链领域也不例外。 
 

8.3 实际案例

案例7-1： 
EOSBET 案例是假转账攻击案例的典型代表，账号A和账号B都是由攻击者控制的账号，攻击者使用账号A给帐号B转账，正常的转账只有账号A和帐号 B能收到转账通知。然而攻击者在账号B上部署了合约，并将这个转账消息转发给EOSBet 合约，这样EOSBet 也会收到A给B的转账通知。关键的问题是，EOSBet合约。 

 

在收到转账通知后，并没有校验transfer中的to是否为_self，就将其错误判断为一笔正常转账，然后根据平台游戏规则给了账号A发送相应的EOS奖励，但实际上，账号A和账号B都是黑客的账号，黑客正是通过控制两个不同账号互相转账，就这样以“零成本”骗取了平台巨额奖励。 https://www.chaindd.com/3135554.html 

 

案例7-2： 
回滚类攻击是利用交易广播的时间差来实施攻击，达到后提交的交易先被打包的效果。区块链的底层网络基于P2P网络，正常情况下P2P网络的交易广播涉及到节点发现和路由，速度比较慢，而攻击者可以对它的交易广播路径进行优化，对当前的出块节点实现直连，不再经过节点发现和P2P 路由阶段，那么它的网络速度就会快很多，很可能比先提交的但通过正常网络通信的交易更快到达出块节点，实现后发先至，从而提前被打包。从攻击场景来说，攻击可以先通过正常网络成功发起一个交易，然后再通过优化后的网络发起一个将当前余额清零或者其他可以让上一个交易不成功的攻击交易，当攻击交易比正常交易先被打包后，正常的交易条件不再满足，交易被回滚，攻击者没有任何的支出。但很多DAPP 的处理只会判断交易是否被成功发起，不判断后面是否出现了回滚，这样它们仍会认为交易已成功，而给攻击者发放对应的数字商品。 
 

案例7-3： 
BetDice是所有案件中损失最大的一个，攻击手法分为两种，一种是利用时间差来实现如上节所述的回滚攻击，另一种是利用黑名单功能，提交不可能被打包的交易。利用时间差的手法：如上文所述交易广播是通过P2P网络一个节点一个节点广播的，扩散是比较慢的，路径并不一定是最优的，存在通过最优路径后发先至的可能，也就是说即使节点 A 发送交易 a 比 节点 B 发送交易 b 要早那么一点点，但是节点 B 跟当前出块节点直连，那么交易 b 会比交易 a 先被广播到出块BP并且被打包。具体的
攻击流程如下所示： 
（1）攻击者往游戏开奖节点下注，发起下注交易； 
（2）然后立刻往当前出块节点的 seed 发送转账清空账号余额的交易，以便于比下注交易更快被打包； 
（3）此时，开奖节点不知道攻击者的账号已经清空了( 因为该节点还不知道有情况账号余额的交易 )，所以下注交易在开奖节点成功了（而当下注交易广播到出块 BP 时，因为攻击者账号余额为空，所以下注交易失败，所以攻击者无成本）； 
（4）当游戏方直接根据节点的 state 获取开奖数据，但经过上面的分析我们知道，这个 state 其实是需要被回滚的，所以该数据不能为准。但游戏方还是根据这个数据进行开奖了，而开奖交易发送到 BP， 因为 DAPP 的合约里没有对下注单是否存在进行判断，所以打包成功，游戏方转账给攻击者。 
利用黑名单的手法：ECAF是EOS的一个仲裁组织，对一些恶意事件发起仲裁，对一些恶意账号会列入黑名单，并下发给各打包节点，恶意账号就不能进行交易，攻击者利用了ECAF的这个特性实施了攻击，具体攻击流程如下所示： 
（1）attack 合约部署攻击合约； 
（2）用 blacklist 发起转账请求，推送下注交易； 
（3）此时游戏节点执行成功并开奖但 出块节点 BP 发现黑名单不予打包； 
（4）则下注交易回滚，但开奖交易依旧打包成功。 
更多详细的介绍，可以参考如下两个链接的文章： 
https://eos.live/detail/19215 
https://eos.live/detail/19255 

 

案例7-4： 
北京时间 2018 年 12 月 19 日凌晨，EOS 网络中，包括BetDice，Royal Online Vegas 在内的数个游戏 DApp 遭受黑客攻击，损失数十万枚 EOS 通证。 本次事件是由于部分游戏 DApp 为增强游戏体验，自建节点运行 DApp，游戏的奖励结算完全基于本地 EOS 节点的交易记录。由于自建节点的交易存在回滚的可能，黑客就利用了BP与自建节点的交易时间差完成了回滚攻击，无成本赢得奖励。此部分的具体攻击如下图所示： 

 修复方案 
1、 关键逻辑不仅要校验是否真实的转账消息，还需要校验转账的目标账户是否正
确。 
2、不仅要确认支付是否成功提交，还需要等待一定时间，看支付是否回滚，再确
认支付是否成功。 
3、游戏的奖励机制应该同下注机制紧密相关。一旦发现下注交易产生问题发生回
滚，则奖励交易也应该一起回滚。 

 

9、脆弱的随机数机制 
 

9.1 风险描述 

这里指的不仅仅是伪随机函数的问题，而是整个随机数生成机制不够安全，导致可以被攻击者提前获取或猜测到随机数的结果，以实施攻击。 

9.2 危害描述 

随机数问题也是近期比较常发的安全事件，特别是随着一些智能合约类游戏的爆发。随机数作为游戏公平性的保证，一旦有漏洞就会导致游戏机制被破坏，就可以从中获利，所以常常被各种攻击者盯上，以至于2018-2019年就发生了至少15起案件，包括2018年非常火热的Last Winner 和 Fomo3D项目，部分 DAPP还因为安全事件而关闭。虽然总的损失金额不大，只有194 万美金，但跟这些游戏的规模都还不大有关系，黑客在这些游戏早期就开始关注并开始攻击窃夺资金，以至于他们没有机会长大。另外，攻击数量多也说明弱随机数攻击的门槛不高，以至于很多黑客都可以发起攻击，所以区块链开发者需要特别注意弱随机数带来的安全风险。

9.3 实际案例

案例8-1： 
如下是Fomo3D判断是否空投奖励的代码，像last winner这类山寨Fomo3D的游戏基本也都是类似的代码： 

随机数seed由timestamp、difficulty、coinbase、gaslimit、msg、sender、number构成。因此，只要知道这几个数据，我们就可以预测出是否可以获得空投奖励。其中msg.sender是可以由用户或攻击者控制，因此攻击者可以不断尝试构造出满足空投奖励条件的msg.sender以获得比正常用户高很多的空投奖励。其中在last winner中，攻击者在6天内就获得了170 万美金的空投奖励。更多详细的内容可以参考如下
链接： 
https://www.reddit.com/r/ethereum/comments/916xni/how_to_pwn_fomo3d_a_beginners_guide/ 
https://paper.seebug.org/672/ 

9.4  修复方案 
1) 一般来说随机数的构成元素不应该可以被用户控制； 
2) 不应该在开奖前让用户可以预测到开奖结果。 

 

10、存在缺陷的激励机制      
 

10.1  风险描述 

激励机制是区块链的重要环节，但若开发者设计的激励机制存在可以被利用的漏洞，就可能会给开发者或用户带来损失。 

10.2  危害描述 
激励机制跟报酬的多少直接相关，因此会被很多的攻击者盯上，带来不少的安全风险，有漏洞的激励机制将会给团队带来巨大的经济损失。Eligius 矿池遭受的“块代扣攻击”就让他损失了 120 万美元。攻击方利用了矿池激励机制的漏洞，参与分红，但是不做贡献，挖到了矿就自己藏起来，给一起挖矿的矿工和矿池都带来了损害，长期来看矿池的吸引力也会受到影响。 

 

10.3 实际案例

案例9-1： 
2014年的时候，Eligius矿池遭受“块代扣攻击”，损失了120 万美元。块代扣攻击是指，一个恶意的矿工可以运行一个自己开发的挖矿软件，该怎么挖怎么挖，但是碰到真正解的话就扣下不提交给矿池，因为从矿池方看来，他们似乎正在为矿池工作，并继续得到分的报酬，而实际上，并不是真正的为矿池做有益的贡献。对矿池和矿工来说，在不同的激励机制下，他们受到的危害也不一样。如果矿池是按照工作量给钱的，那么这种攻击不会伤害其他矿工，却会从矿池老板那里白领报酬。如果矿池是按比例分账的，那么块代扣攻击就危害其他矿工的利益，因为他分酬劳而不做贡献。 由于BTC挖矿机制的设置，这种攻击并没有办法让攻击者独吞扣下的挖矿奖励，因为他挖的是矿池指定的块，而这些块的奖励只能指向矿池。所以这类的攻击还不算多，
但我们在设计其它激励机制的时候一定好仔细考虑，以防出现可以被利用的漏洞，造成重大损失。 
 https://www.8btc.com/article/20341 
 

10.4 修复方案

从上面的案例来看，我们在设计激励机制时千万不要假设所有的参与者都是诚实的，一定要防范恶意者的攻击，以保护大家的利益。 

 

11 日志记录和监控不足 

11.1  风险描述 

日志记录和监控的问题对区块链团队和公司来说非常很重要。如果没有足够的日志记录和监控，被攻击的过程中，你会不知道，不能及时止损。发生安全事件后，你没有办法调查，也没有办法改进以避免再犯同样的错误。所以日志记录和监控不足的问题也很严重！ 

11.2 危害描述

缺少日志和监控会让黑客攻击变得更肆无忌惮，因为你无法发现攻击行为，无法知道是哪里存在安全漏洞，也就没有办法找到修复的方案，整体的安全风险处于失控的状态。 

11.3 实际案例

比如前文提到的Mt.Gox（案例1-1）等安全事件，黑客的攻击路径和手法并没有清晰的披露出来，若排除交易所本身不愿意披露这个因素外，更大的可能是交易所本身并没有完善的日志记录和监控，以至于无法复盘整个攻击流程，无法确切的知道黑客攻击行为的细节。 

11.4 修复方案

要确保所有登录、访问控制失败、输入验证失败都能够被记录到日志中去，并保留足够的用户上下文信息，以识别可疑或恶意帐户，并为后期取证预留足够时间；确保日志以一种能被集中日志管理解决方案使用的形式生成；确保高额交易有完整性控制的审计信息，以防止篡改或删除，例如审计信息保存在只能进行记录增加的数据库表中；建立有效的监控和告警机制，使可疑活动在可接受的时间内被发现和应对；建立或采取一个应急响应机制和恢复计划。