SharkTeam在此前的“十大智能合约安全性威胁”系列课程中，依据历史时间所发生的智能合约安全事件，梳理总结在智能合约领域里出现比较多、危害最大的一个前10大漏洞。这种漏洞以前一般出现在了Solidity智能合约中，那对于Move智能合约而言，是否会存有同样的危害呢？ 

SharkTeam【Move语言安全性分析及合同财务审计关键点】系列课程将带大家逐渐深层次，基本内容管理权限漏洞、再入漏洞、逻辑性校检漏洞、返回进攻、控制预言机、合同更新漏洞、函数公式故意复位、三明治进攻、中间人攻击、提议进攻。此章具体内容【逻辑性校检漏洞】。

1 逻辑性校检漏洞

智能合约研发的业务流程有关数字逻辑繁杂，涉及到的社会经济学运算主要参数比较多，不一样项目及协议书中间可组合性极其丰富，难以预测分析，很容易发生安全性漏洞。

在Solidity智能合约中，大家归纳了4种不同的逻辑性校检漏洞：

（1）未校检传参

（2）未校检有关测算数据公式

（3）未校检函数调用

（4）未标准使用require校检

同样地，我们将要从4大领域剖析Move合同中存不存在这种逻辑性检测漏洞及其概率和危害。

1.1 未校检传参

不检查信息启用的传参，就算被启用的函数公式回到一个异常值，实行逻辑性依然会顺利进行，仅仅该函数的调用并无法实现正确逻辑性，这也会导致全部买卖无法得到正确结论，甚至还会威胁到数字货币安全性。

例如，Solidity合同中的call函数，functionCallWithValue函数如下所示：

编码中启用了call函数，如果call函数实行出现意外，例如转账失败，则传参success为false。要是没有认证该传参，即便success为false，买卖依然会正常的实行。仅仅交易过程中的该笔转帐没成功。这儿根据require对success展开了认证，假如是false，买卖便会回退(revert)。

call函数是Solidity动态性调用函数的一个关键函数公式，是Solidity语言方面的一个很容易因为传参而出现漏洞的主要代表。除了call函数以外，在业务方面，Solidity合同也频繁使用传参来判断函数是不是实行取得成功，例如ERC20合同里的函数公式：

对于此类函数公式，在实践应用时一般必须对传参开展校检，不然会造成漏洞，甚至还会威胁到数字货币安全性。

除此之外，按照实际的领域模型，函数公式会回到一些业务流程必须的信息，这些信息也应该根据业务流程开展认证，进一步确保调用函数并没有出现意外，包含但是不限于传参的种类、长短、范畴等。例如上边的functionCallWithValue函数中，激发了verifyCallResultFromTarget函数对传参开展校检。其不但对传参success展开了查验，也对retrundata的长短展开了校验和解决。

在Move合同中，从言语方面而言，因其静态数据启用的特点，不会有类似Solidity中的call函数必须校检传参的现象，即便有必须校检函数公式是不是实行恰当，一般会在spec控制模块操作规范语言表达在Move Prover中开展校检，校验失败则展销会中断。

从工作方面而言，Move合同中的spec控制模块同样也可以校检函数公式对全局性数据库的改动。除此之外，也可以在合同中撰写单元测试卷函数公式对函数直接使用单元测试卷，来确保函数公式实施的准确性。因而，一般不会将表明函数公式实行成功与否的布尔运算自变量做为传参。因而，Move函数的传参大多是具体的业务数据，是否要校检，就需要按照实际项目需求来决定，例如应该根据传参的差异，进到不同类型的函数公式逻辑性支系，就需要对传参开展判断和检测，例如DEX里的流通性函数公式：

X与Y的排列顺序不一样，必须浏览的dalance也是不一样的，还要校检order!=0。

总体来说，Move语言静态数据启用特点、spec控制模块及其单元测试卷等极大地提高了函数公式安全性，这一点Solidity要好一些。但不排除函数公式会如果没有校检传参而出现漏洞的现象。因而，开发者更应该对业务和建立逻辑性了解，开发设计的时候要慎重前行。

1.2 未校检有关测算数据信息

业务在合同完成环节中，充分考虑状况不足全方位并没有恰当校检对应的业务流程社会经济学公式计算和测算数据信息，造成合同针对特殊测算数据信息可扩展性差。例如：

（1）XCarnival安全事件

事情发生在2022年6月24日，NFT借贷合同XCarnival遭受黑客入侵，损害大概380万美金。

直接原因是controller合约borrowAllowed调用函数的orderAllowed函数公式对算法设计order的校检不全面，仅仅只是校检了订单信息存有、详细地址恰当而且没有被结算，并没校检订单信息里的NFT有没有被获取，即便订单信息里的NFT早已被获取了，order的校检仍然能够根据。

（2）Fortress Loans安全事件

事情发生在2022年5月9日，Fortress Loans遭受黑客入侵，流失了1048.1 ETH及其40万DAI。

直接原因是submit函数尽管校检了signer的总数，但是却没有对signer本身和测算的信息power开展校检。

这也使得网络攻击能调用submit函数改动初始条件fcds，最后更改了价钱预言机中的价钱。

最后，网络攻击运用该漏洞盗取了1048.1 ETH及其40万DAI。

相似的安全事件也有许多，它们是毕竟在函数公式内部结构缺乏对投资模型创建的算法设计或是测算的信息缺乏校检所引起的漏洞。这种漏洞主要是因为新项目设计及开发并没充分考虑所有的现象所造成的，其比较严重级别不一，很严重的甚至还会给工程产生很大的财产损失，如同上边的安全事件。

在Move合同完成各种项目的时候，一样无法保证不会有这种问题，特别是新型项目。期待出现于Solidity智能合约中的那些安全事件可以给Move开发人员一些警告，在开发过程中，尽可能的防止安全性漏洞。

1.3 未校检函数调用

函数公式接受主要参数时，不会自动的认证输入数据属性是否具备可靠性和准确性。因而，函数公式在推进的时候要依据业务流程必须对主要参数开展校检，若缺乏校检后面一种校检不符项目需求，往往会造成漏洞，甚至还会威胁到数字货币安全性。

以Superfluid.Finance安全事件为例子。事情发生在2022年2月8日，以太币里的DeFi协议书Superfluid遭受黑客入侵，损害超1300万美金。

直接原因取决于，Superfluid合同存在重大的思路漏洞，callAgreement函数缺乏对参数校检，促使网络攻击将合同结构的ctx数据信息更换为自定ctx数据信息，这为网络攻击疯狂攻击带来了机遇。

在Move合同设计中更是需要对主要参数开展校检。在Move中，函数的参数不单单是项目需求的信息，还涵盖了管理权限必须的信息，例如signer。Move并没有类似Solidity中的msg.sender这类局部变量，Move上对权限评定是由主要参数达到的。比如下面的函数公式：

该函数中的account主要参数是货币锻造的发起帐户，它务必币的管理权限，即MintCapStore，类似Solidity中的msg.sender一定要owner。假如缺少了这一部分校检，该货币便是一切帐户都能够锻造的啦。

除此之外，Move生态里的项目类型跟Solidity绿色生态同样，仅仅完成的表达不一样。因而，Solidity合同中出现的领域模型里的漏洞在Move合同中有非常大的概率仍然存在。因而，Move开发人员在开发规划的时候要注意这些在Solidity合同里已经出现过的漏洞。

1.4 未标准使用require

Solidity中的require致力于认证函数公式的内部键入，包含调用者输入主要参数、函数的返回值、函数公式实行前后左右情况转变等。若不能标准使用require，合同可能产生漏洞，乃至威胁到数字货币安全性，例如XDXSwap安全事件。

事情发生在2021年7月2日，火币网生态圈（Heco）上DeFi新项目XDXSwap遭受闪电贷进攻，损害约400万美元。

直接原因便是闪电贷的功效完成合同，存有借出去不还钱很严重的漏洞，导致高额损害，是项目方fork Uniswap合约代码并改动时引进很严重的漏洞，即缺乏K值校检的require语句。其根本的因素还是业务不太熟悉，造成完成存有漏洞。

在Move合同中， assert句子和spec控制模块进行require类一样作用。一样，许多Solidity生态系统新项目，包含DEX、借款、大农场等几种项目不久的将来也将出现在了Move的绿色生态中。Move与Solidity基本原理及其体制是不一样的，但工程项目的服务时同样的。由于Solidity绿色生态新项目踩雷成千上万，安全事件五花八门，Move尽管安全系数高，但在完成各种项目的时候依然要细心谨慎，尽量减少发生同类的漏洞，期待同一个坑千万别踩一次了。

2 汇总

时下Move还是处于发展过程，Move生态离完善尚一定距离，开发人员偏少，开发人员工作经验缺乏，真正能娴熟开发设计Move合同的很少，因而很容易出现业务流程方面的一些漏洞。这就需要Move合同在设计开发的时候对Move语言特点及其业务流程都需要了解，才有可能少发生业务流程漏洞。

此外，Solidity已实现了很多的业务种类，比如去中心化交易所、区块链技术借款、盈利汇聚、金融杠杆借款、金融杠杆挖矿、闪电贷、跨链买卖等。这种最典型的需求场景必须在Move生态足逐一完成，并且需要根据Move与Solidity的差别开展重新定位实现方案。在这过程中，就更容易发生一下漏洞，如同Solidity初期经历了太多次进攻还有大量资产损害才逐渐变得成熟。Move虽然是一个安全系数相对较高的语言表达，但没有人可以确保并没有漏洞，我希望可以参考Solidity的发展历程，让Move生态的高速发展少走一些弯路，少一些损害，迅速更加稳定地变得成熟。

About Us

SharkTeam的企业愿景是全方位维护Web3全球的安全性。精英团队由来自全国各地的资深的安全性专业人员高级科学研究人员构成，熟练区块链和智能合约的最底层基础理论，提供专业的智能合约财务审计、链上剖析、应急处置等工作。已经与区块链生态体系每个领域的关键所在参加者,如Polkadot、Moonbeam、polygon、OKC、Huobi Global、imToken、ChainIDE等创建合作关系关联。

Twitter：https://twitter.com/sharkteamorg 

Discord：https://discord.gg/jGH9xXCjDZ  

Telegram：https://t.me/sharkteamorg 

大量区块链安全咨询和分析，点击进入连接查询

D查下|链上风险性审查https://m.chainaegis.com

转载：驼鸟区块链