2022DAPP安全指南手册.docx

《2022DAPP安全指南手册.docx》由会员分享，可在线阅读，更多相关《2022DAPP安全指南手册.docx（37页珍藏版）》请在课桌文档上搜索。

1、DAPP安全指南手册目录1. DAPP与安全概述611 DApp概述612 DApp安全简介713 DAPP安全攻防82. DeFi的安全821 DeFi概述822 DeFi的功能特性923 DeF14二1124 DeFi项目的安全概述1225 DeFi的智能合约安全案例分析1426 DeFi通证经济设计方面的安全案例分析2627 DeFi监管安全的案例分析323. DApp安全测试建议与工具3431 木勾3432 3533 /IJ3634 T3.13735生产环境中的测试与追踪3736针对智能合约的安全测试工具384. DAPP安全最佳实践与案例3941DAPP的基本架构3942安全开发与测

2、试的要点4043DApp开发采用DevSecOps流程4144加强安全审计4143参考资料1.DApp与安全概述1.1DApp概述DAPP是DeCentraliZedAPPliCation的缩写，是基于区块链的应用程序。这些类型的应用程序的身份数据和资产由用户控制，程序的运行和数据的管理不受任何中心化的管控。一个应用程序需要有一组特定的特征才能成为DAppo具体包括：去中心化：使用一种类似区块链的加密技术。不依赖中心服务器，不需要专门的通信服务器传递消息，也不需要中心数据库来管理数据。开放生态系统：任何人都可以针对特定区块链平台的接口和协议开发应用程序，它的发布不受任何机构限制。各种创意与创新

3、可以自由表达和实现。算法及协议：交易发生的顺序由共识算法决定。DAPP参与者信息一般存储在参与者的手机。可以保护数字资产，有利于产权不会泄露、被破坏。DApp也在演变不断进化，通证化是今天DApp的显著特点。在区块链的时代，任何“价值”的流动，都可以通证化。通证需要具备三要素：权益、加密、流通，通证的三个要素缺一不可。通证化后的DApp只需聚焦在应用前端和智能合约之间的业务逻辑上。美国证监会(SEC)将加密货币划分为两类：实用型通证(IItiIitytOken)和证券型通证(SeCUritytoken)0证券型通证被用来支付红利、收益、利息，或者通过投资其他通证为通证持有人带来利益。他们是具有

4、货币价值的可交易金融工具。公共股本、私人股本、房地产、管理基金、交易所基金、债券，这些都是证券型通证的常见示例。这类通证也被细分为两类：权益通证(EquityToken)和资产通证(ASSetToken)实用型通证也被称为应用通证(apptoken)或用户通证(usertoken)o这类通证大多都是企业针对自己提供的服务或者产品为项目募资而发行的。实用型通证的价值是以项目概念的未来实用价值来评估的。与证券型通证相比，实用型通证更具体地强调自己的开发平台或生态系统，它的价值与平台或生态系统内参与者的活跃度成正比。实用型通证被细分为两类：产品或服务通证(USeOfPrOdUCt)和奖励通证(ReW

5、ardTOken)1.2DApp安全简介DAPP安全具有一些内置安全性、又可以通过密码学增加其鲁棒性。但由于DAPP直接操作数字资产，而且往往开放源代码，应用程序的源代码是所有人都可见，已经成为备受黑客关注的攻击目标。黑客的攻击手段从最初的“溢出攻击”到“假EOS攻击”、“重放攻击”、“假转账通知攻击”，而后到屡试不爽的“随机数攻击”和“交易回滚攻击”，黑客的攻击手法正在不断演变且愈发复杂。以下是Peckshield发布的波场、以太坊、EOS三大生态DAPP安全事件报告：根据PeCkShieId报告指出，从2018年7月至2019年6月，EOS上的DApp安全事件数量最多，共109起，损失EO

6、S总数约93万枚。波场（Tron）上的DApp安全事件数量为11起，损失TRX约2900万枚，而仅2019年5月波场发生的安全事件所引起是TRX损失就超2700万枚，占总统计数据的约93%0而以太坊安全事件（注：仅统计DApp的安全，不包括Token（如常规ERC20）相关的安全事件）有5起，共损失2.4万枚以太坊。下面的图介绍总结安全事件和攻击手段。1. 3DApp安全攻防根据区块链安全公司厦门慢雾科技有限公司（以下简称：慢雾科技）总结的安全攻防图对DApp的安全进行了总结。慢雾科技攻防图的总结，除了利用区块链上的常见的手段还总结了利用区块链下的传统安全的手段进行风险分析包括但不限于：链上攻

7、防：包括但不限于：逻辑设计、溢出、未初始化、假充值、条件竞争、随机数、资源优化、假通知、回调安全、拒绝服务、内存吞噬、假账号、权限控制、恶意事件、硬件编码、假币、重放攻击、第三方模块、显现编码、编译器版本等问题。“1-=链下攻防：包括但不限于XSS、CSRF.SQL注入、中间人劫持、私钥存储、SSRF、加密传输、权限控制、命令执行、认证授权、第三方组件、ATT&CK.终端安全、后端安全、Web安全、节点安全等问题，除了考虑智能合约安全，还需要考虑节点的安全。除了考虑数据的加密还需要考虑共识算法的安全。Gotrv Pentynodoos共识gwIawwwIa*bm三声Iwm-IInMt-|wmI

8、iflwa-IaraBMIE-1IW-IWMw-LI权WgMW/口件Ia三wIro_IIWgIBJtIautaMWMXSSIICSRFIISQCaAlt0gfflWMI私WIJTWISSRF后嫡安全IIngWIeawaw|命行I认atCompound,BzX,AAVE等DeFi项目都包括借贷或者闪贷服务。DeFi的借币方主要是利用某一种数字货币作为抵押，借出另外一种数字货币（大部分的应用场景是稳定币的借贷）进行交易获得利润。因此DeFi的借贷服务目前是建立在公链技术，去中心化交易所和稳定币基础上的金融服务。5 .ETF,合成资产、ABS等金融衍生品：不仅是数字资产的衍生产品，也可以将物理资产用

9、数字资产的形式来表现。DeFi的金融衍生品目前还是比较初期的应用，项目包括Synthetix.i。等等。这个层次的应用利用了前面4个层次的服务。6 .预测市场、保险、供应链金融：这个层次的应用利用前面五个层次的服务，给DeFi在现实世界的金融服务落地提供更加广阔的想象空间。例如NexusMutual,Cover协议，OPyn等等分布式保险协议利用公链技术实现保险服务，利用DEX交易保险的治理币和保险标的的数字货币，利用稳定币给保险产品进行定价，利用WrappedToken进行借贷服务，利用合成资产与保险产品进行合成生成新的保险产品。目前DeFi还不够成熟，暂时缺少成熟的具体的应用，但是发展前景

10、广阔。需要注意的是，从第二到第六个层次，同时需要预言机（OraCIe）的协助。并且不同层次的组合必须要注意安全问题。近期一个典型的案例就是LendfMe黑客攻击事件，其原因就是ERC-777与Uniswap组合所产生的问题。单独拿ERC-777与Uniswap来说，它们本身都没有什么问题，但组合在一起就可能产生一系列连锁反应，从而带来难以估测的安全隐患。所以在实际应用中需要进行大量测试，以确保应用的安全。DeFi目前最大的问题就是它还处于发展初期，各方面还不够成熟。像MakerDAO.Uniswap等知名项目其实大部分都还处于Beta阶段，出现包括漏洞在内的安全问题在所难免。关于DeFi生态，

11、目前大部分应用都是建立在以太坊公链之上，在其他公链，比如BTC、EOS、波场、元界DNA上面也有，但相较于以太坊还是要少。应用类型方面，目前以借贷、合成资产与DEX为主。2.4DeFi项目的安全概述根据美国区块链数据分析公司CiPherTraCe统计，2020年DeFi项目被黑客攻击造成的损失是1亿美金。DeFiAdds$100Millionto2020Thefts2020 Q3-4 DeFi$340MI $51.5MI S76.5iV!$128M2020Ql-2OtherHacksandTheftsSource:CipherTracecryptocurrencyInteIIigence我们总

12、结，DeFi项目需要注意三方面的安全，第一就是智能合约的安全，第二就是通证经济设计方面的安全，第三就是监管的安全。DeFi第一方面的安全：关于智能合约的安全，机械工业出版社在2018年5月出版的区块链安全技术指南本书里面，很大篇幅的内容讲智能合约的安全值得借鉴，另外云安全联盟CSA大中华区的区块链安全工作组也在最近发布了智能合约安全方面的白皮书也可以参考。举两个例子来说明一下。第一个，是DeFi去中心化保险项目OPyn的漏洞，第二是波场与以太坊跨链的DeFi项目的漏洞。两个漏洞都与智能合约代码有关。DeFi第二方面的安全：就是通证经济设计方面的安全。如果通证经济没有设计好，会造成死亡螺旋的问题

13、。就是你价格越低，参与的人越少，然后逐渐的就价格就归零了，或者趋近于零，这就是死亡螺旋，你怎么样去避免死亡螺旋，促进价格和生态可持续的发展,这个其实是通证经济与DAO设计的一个关键。或者因为通证经济设计参数方面有漏洞，可以被黑客利用。我们下面会用DeFi项目CUrVe作为例子来说明可能被黑客利用的通证经济设计参数方面的漏洞。总体来说DeFi的90%的项目，因为有可能会因为共识不够，通证经济设计不合理，可能技术还可以，但是最后还是要靠生态，靠通证经济，因为它是多学科的领域，其中某个领域没做好，最后可能不能成功偃旗息鼓了,这些例子已经非常多，就不一一列举了。DeFi第三方面的安全：是监管安全。现在

14、DeFi生态还小，监管还没有开始。但是到某个程度就要受监管，那么有些如果不符合监管的话，整个生态会受到打击，所以这个风险就严重了。下面我们用去中心化交易所EtherDeIta项目被美国政府罚款作为例子进行分析说明。需要注意的是DeFi项目最终都一定要符合本地的监管，所以首先项目需要有自律的精神，绝对不能够去做非法的一些事情。DeFi要能够真正地进行发展，一定要有行业的自律，现在国内很多DeFi的仿盘，内在还是中心化的，不是去中心化，有可能会圈钱跑路的，所以大家要小心，保证好项目的安全工作，及时规避风险。2. 5DeFi的智能合约安全案例分析DeFi的业务逻辑由智能合约的代码实现，智能合约本身的

15、安全可以参考CSAGCR的智能合约安全指南白皮书，也可以参考机械工业出版社的区块链安全技术指南这本书关于智能合约安全的内容。这里主要具体分析两个智能合约安全被黑客攻击成功的案例。另外下面是与智能合约安全有关的需要考虑的内容。1 .私钥风险：没有多签的DeFi合约意味着掌握合约私钥的可以随意更改合约或者跑路；因此DeFi合约的管理地址一定需要多签名。但是目前大部分DeFi项目的管理地址是单签名，或者不能证明多签名地址是一个人还是多个人拥有。随着DeFi应用增加这个问题会越来越重要。2 .无常损失风险：例如自动做市的流动性挖矿提供者的无常损失，尤其是如果交易对的两种风险资产的价格波动太大，流动性提

16、供者按照智能合约的自动做市的逻辑就会有大的无常损失。这个需要优化智能合约的自动做市的逻辑，预言机的价格公正性和可用性，和交易对价格的稳定性来解决。3 .交易摩擦风险：在以太坊交易Gas费率极高的时候，DeFi用户必须支付非常高的费用，如果本金小，就可能在不知不觉中损失本金。这个需要设计GaS费用合理的新的公链，或者第二层协议来解决GaS费用高的问题。4 .操作失误风险：在转账过程中失误导致资产永久丢失。比如直接向DeFi智能合约地址转账，造成资金被永远锁定在合约中。这个需要用户对于智能合约和DeFi项目本身的了解。5 .闪贷(FIaShLoan)造成的DeFi风险：闪贷的基本工作原理是：在单笔

17、交易中贷出借款人需要的金额。然而在交易结束时，借款人必须偿还不少于贷款金额的数目。如果借款人做不到，贷款智能合约的逻辑会自动回滚交易。黑客利用闪贷零成本借贷，并且利用所借到的资本通过交易手段拉高或者拉低某一种数字货币进行价格操纵，把借来的币用高价格卖出，再用低价格买进以后全额还回。这些操作是通过一系列的智能合约调用在同一个区块完成，黑客单笔交易中获利。闪贷造成的DeFi风险本身不是因为有闪贷才造成的，而是由于DeFi项目本身在流动性设计或者预言机选择的漏洞造成的。理论上黑客通过闪贷调用智能合约的获利，都可以被一个拥有充分多数字货币的大户通过同样的智能合约调用来获取。因此解决闪贷(FlaShLo

18、an)造成的DeFi风险还是需要看DeFi项目本身的流动性设计和预言机设计。6 .智能合约授权滥用风险：DeFi项目比如ComPoUnd,Uniswap,Kyber,Maker等等都是通过ERC20的APlApprove获得用户的一次性授权，但是授权的金额没有限制，理论上这些项目可以滥用权限转走用户授权的资金。这个问题目前没有收到大家的重视。解决这个问题的方法非常简单，就是项目只能获得用户有明确限额的授权。每次超过限额的调用都需要用户批准。2.5.1Opyn的智能合约漏洞分析北京时间2020年08月05日，DeFi期权平台和保险项目OPyn的看跌期权(OPynETHPut)智能合约遭到黑客攻击

19、，损失约37万美元。Opyn是一个通用期权协议，于今年2月份转型为保险平台，通过OTokenS为DeFi平台提供可交易的ETH看跌期权，以此锚定ETH市场价格，为高波动性的DeFi市场提供相对的稳定性。PeCkShield安全团队获悉OPyn平台遭受攻击后，迅速定位到问题关键点在于：攻击者发现OPyn智能合约行权(exercise)接口对接收到的ETH存在某些处理缺陷，其合约并没有对交易者的实时交易额进行检验，使得攻击者可以在一笔对自己发起真实的交易之后，再插入一笔伪装交易骗得卖方所抵押的数字资产，进而实现空手套白狼。简单来说，由于OPynETHPUt智能合约中的行权函数exercise。没有

20、对交易者的ETH进行实时校验。根据OPyn平台的业务逻辑，看跌期权的买方给卖方转移相应价值的ETH,即可获得卖方抵押的数字资产。狡猾的攻击者，先向自己发起伪装的交易，利用这笔ETH可以重复使用的特性，再次向卖方用户发起转账，进而骗取卖方已经抵押的数字资产。下面是PeckShieId的详细分析:漏洞详细过程分析：先来说说，OPyn平台的业务逻辑：当用户使用OPyn合约行权即买卖期货(exercise)时，需要买方向卖方转入相应数量的ETH或者ERC20Token,然后合约将销毁买方对应的OToken,而后买方将获得卖方已经抵押的资产。例如：小王认为行情进入了下跌趋势，看到OPyn上挂着一个小李对

21、ETH330美元的看跌期权，于是进入交易系统，向小李转账一个ETH,获得小李抵押的等额数字资产。若此刻行情已经跌至了300美元，小王便可获得其中的差价。14951149614971498149915001501150215031504155 looPfunction exercseuint2S6 OTokensToExercisetaddress PayQble memory VaultsToExerciseFrom)public payable fortuint256 i - 0; i - OTokensToExercise) _exercise(oTokensToExercise, VQl

22、IltOWner); returnT else (eerciOTokensToExercise 上 OTokensToExercise.sub(vult.OTokensIssued); _exercise(vault.OTokensIssued, VaUItoWner);图1exercise。函数中循环执行传入的VaUltS地址列表如上面的合约代码片段所示，行权函数exercise()的内部是一个循环，依据参数中传递的VaUItSTOEXerCiSeFrOm中的地址数量依次调用真正的行权逻辑_exercise()函数。1876/4.Transferinunderlying,burn0T0ken

23、spayoutcollateral1877/4.1Transferinunderlying1878if(isETH(underlying)1879requrnsg.valueamtUnderlyingToPay,Incorrectmsg.value*)J1880)ets111881require(msg.valueofETHisreusedinthe1882-underlying.transferFrom(second(andfurther)exercisecall1883msg.sender,1884FP911r-acoJddress(this)t18852W3se、QmtUnderlyin

24、gToPoy1886takesintoken)f1887neachcallCouldnottransferintokens1888);1889)图2重用传入合约的ETH来获得抵押资产函数处理ERC20Token时，和大部分的DeFi项目做法一样，使用transferFrom(),如代码1882行所示,从msg.sender转账到address(this)o但是当函数处理的资产为ETH时，处理的方式就完全不一样了。因为在Solidity中，msg.value的意思是合约调用者在调用具有payable接口时所转给该合约的ETH数量，仅是一个量值，所以在合约代码的1879行中，检查msg.value

25、=amtnderlyingToPay仅能确保合约确实收到了amtnderlyingToPay数量的ETH,并不会对msg.value的值造成任何影响。但是正如上面讲到的在exercise()中会循环调用_exercise()函数，这导致尽管合约实际只收到一次ETH,然而在循环过程中却可以重复使用。攻击点就在这里，由于合约少了一步对ETH实时数量的检验，使得攻击者可以先伪造一笔指向自己的交易，然后再把已经花掉的本金再次利用，和平台其他用户完成一笔正常交易ddERC20CoitetorOptton(mtToCrwte:750000000.mtCototoral:247500000,ecivr:78

26、70231992b4bU)forToMnOOETH$330PUtM/14/20ton*Nffrom(from787O231992ab4b1a.*0E951d51bM72319d.,vh:247500000)forSmartCentradOFiatTokanPraxy,Stabtecan.hnpMww.centrok.USDCotn(USOC).USOCom.TokenContracttransfrfrom(from:7870231M2ab4b1a.to:951d51bMft72310d.value:247500000)dWgatCaNtoTokenOFtatTokenVIxrciM(oTokn

27、sToErcis*15000000,UtteTofafcaFrornfimmqm:.*7皿，“k11tranfrS.OETHoTokenoETH$330Put0H40twovaultstoexrcise()m*g.valuis75ETH上yr,WiXWMW000orSmartContractORaHbkanftaqiOtaMnoin.MtpRkJQ.USOCan(USOCKUSOCan.Tokuoafirst24,750USDCout,75oETHburnedtramtr(to:e7870231997M4tia.ValUk247SOOOOO)MgatctoTokenOFtMTokecVl(Kc

28、.78702319924bi.valu:247SQ0000j)torSmvtCOntrKlOFelToMnPioxy.StabtKO4b1a.rakw:24750000000)(toto0tfCMtoTOkenOFiMTokanVIremowUntransfer7&.0ETHtoSmartContractO0x7870231992ab4b.图3攻击交易分析在图3中，我们通过Bloxy浏览器显示的调用过程来展示攻击的过程。由于攻击者吃掉了很多笔订单，我们以其中一笔交易为例，向大家展示其攻击逻辑：1 .攻击者先从UniSWaP购入了75。ETH为进一步调用函数行权做好筹备；2 .攻击者创建了一个V

29、aUIt地址，作为看空期权卖方，并且抵押24,750USDC铸造出75OETH,但并未卖出这些期权，等于自己同时买入了以330的价格卖出75ETH的权利；3 .攻击者在OPyn合约中调用了exercise(),在持有150oETH看空期权的情况下，先向自己的VaUIt地址转入了75个ETH,获得自己事先抵押的24,750个USDC,再重利用了这75个ETH,成功吃掉了另一个用户的24,750个USDC,进而实现非法获利。修复建议PeCkShieId安全团队建议，在Solidity中，合约可使用一个局部变量msgValue来保存所收到ETH(即msg.value的值)。这样，在后续的步骤中通过操

30、作msgValue,就能准确的标记有多少ETH已经被花费，进而避免资产被重复利用。此外，我们还可以使用address(this).balance来检查合约余额来规避msg.value被重复使用的风险。2. 5.2波场DeFi项目Myrose智能合约漏洞分析1 .事件起因2020年9月14日晚20:00点，未经安全审计的波场最新DeFi项目MyroseJinance登陆TOkenPOCket钱包，首批支持JST、USDT.SUN、DACC挖矿，并将逐步开通ZEUS、PEARL、CRT等的挖矿，整个挖矿周期将共计产出8400枚RoSE,预计将分发给至少3000名矿工，RoSE定位于波场DeFi领域

31、的基础资产。项目上线之后引来了众多的用户(高达5700多人)参与挖矿，但是好景不长，在20:09左右有用户在TeIegram,Rose中文社区群,，中发文表示USDT无法提现。CSA大中华区的区块链安全工作组成员知道创宇404区块链安全研究团队对于整个事件进行分析，描述如下：2 .代码的分析:知道创宇在remix上部署和测试USDLEthereUm、USDTJrOn、Test三个合约（合约代码具体链接：https:/paper.seebug.org/1337/）调用USDT-Ethereum和USDTjrrOn的mint函数给TeSt合约地址增添一些代币。然后调用TeSt合约的WithdraW

32、函数提现测试。可以看到USDT_Ethereum提现成功，USDTJrOn提现失败。失败的回滚信息中，正是SafeTranSfer函数中对最后返回值的校验。知道创宇的合约模拟实验揭示了以太坊与波场两个不同平台下USDT代币合约中transfer函数关于返回值处理差异性带来的安全风险，而关于“missingreturnvaluebug这一个问题，早在2018年就有研究人员在Medium上公开讨论过，只不过是针对以太坊的，这里对以太坊中的“missingreturnvaluebug问题做一个简单的介绍：3. MissingReturnValueBugERC20标准是以太坊平台上最常见的Token标

33、准，ERC20被定义为一个接口，该接口指定在符合ERC20的智能合同中必须实现哪些功能和事件。在ERC20的开发过程中，有研究人员对于ERC20合约中的transfer函数的正确返回值进行了讨论，主要分为两个阵营：一方认为，如果transfer函数允许在调用合约中处理FaiIederror,那么应该在被调用合约中返回false值，另一方声称，在无法确保安全的情况下，ERC20应该revert交易，关于这个问题在当时被认为都是符合ERC20标准的，并未达成一致。事实证明，很大比例的ERC20Token在传递函数的返回值方面表现出了另一种特殊的方式，有些智能合约的TQnSfer函数不返回任何东西。

34、那么符合ERC20标准的接口的合约试图与不符合ERC20的合约进行交互，会发生什么呢？下面我们通过一个合约示例来做解释说明：interfaceTokenfunctiontransfer()returns(bool);)contractGoodTokenisTokenfunctiontransfer)returns(bool)returntrue;)contractBadTokenfunctiontransfer()contractWalletfunctiontransfer(addresstoken)require(Token(token).transfer()；)在SOIidity中，函数选

35、择器是从它的函数名和输入参数的类型中派生出来的：selector=bytes4(sha3(/transfer(),/)函数的返回值不是函数选择器的一部分，因此，没有返回值的函数transfer。和函数transfer。返回(bool)具有相同的函数选择器，但它们仍然不同，由于缺少返回值，编译器不会接受transfer。函数作为令牌接口的实现，所以Goodtoken是Token接口的实现，而Badtoken不是。当我们通过合约去外部调用BadToken时，Badtoken会处理该transfer调用，并且不返回布尔返回值，之后调用合约会在内存中查找返回值，但是由于被调用的合约中的Transfer

36、函数没有写返回值，所以它会将在这个内存位置找到的任何内容作为外部调用的返回值。完全巧合的是，因为调用方期望返回值的内存槽与存储调用的函数选择器的内存槽重叠，这被EVM解释为返回值“真”。因此，完全是运气使然，EVM的表现就像程序员们希望它的表现一样。自从2018年10月以太坊拜占庭硬分叉以来，EVM有了一个新的操作码，叫做returndatasize,这个操作码存储(顾名思义)外部调用返回数据的大小，这是一个非常有用的操作码，因为它允许在函数调用中返回动态大小的数组。这个操作码在solidity0.4.22更新中被采用，现在，代码在外部调用后检查返回值的大小，并在返回数据比预期的短的情况下revert事务，这比从某个内存插槽中读取数据安全得多，但是这种新的行为对于我们的BadToken来说是一个巨大的问题。如上所述，最大的风险是用sole20.4.22编译的智能合约(预期为ERCO接口)将无法与我们的Badtokens交互，这可能意味着发送到这样的合约的Token将永远停留在那里，即使该合约具有转移ERC20Token的功能。类似问题的合约：,addr:,0xae616e72d3d89e847f74e8ace41ca68bbf56af79,zname:GOOD