使用Crytic的智能合同中的漏洞搜索

Crytic是我们的Github应用程序，用于发现智能合同缺陷，在某种程度上是一件大事：它可以在没有人工干预的情况下检测安全问题，在你工作的同时提供持续的保证，并在部署之前保护你的代码库。

Crytic发现了许多其他工具无法检测到的错误，包括一些不广为人知的错误。目前，Crytic有90多个探测器，我们正在不断增加新的检查并改进现有的检查。它在每次提交时运行这些错误和优化检测器，并评估您自己添加的自定义安全属性！

今天，我们将分享仅由Crytic发现的主要项目中的12个问题，其中包括一些高度严重的问题。

Crtic在安永的“夜幕降临”项目中发现了三个漏洞，其中一个严重漏洞可让任何人制造免费代币。

FTokenShield.mint不检查transfer From的返回值。如果FTokenShield与令牌一起使用，该令牌在错误传输的情况下不会恢复，并且只返回FALSE(例如，BAT)，则任何人都可以创建免费承诺-而攻击者可以免费创建令牌。

FTokenShield.registerVerificationKey和NFTokenShield.registerVerificationKey返回空字节32。不清楚正确的返回值应该是什么。这可能会导致第三方和合同出现意想不到的行为。

可以在MerkleTree.sol中声明treeHeight和0为常量，以允许编译器优化此代码。

Crytic在DeFiStrategy中发现了一个不寻常的问题：修饰符中缺少占位符执行，导致调用者函数返回默认值。此外，Crytic发现了一个与返回BalanceOf调用时严格相等相关的问题。

在无效访问的情况下，SuperSaverZap.onlyInSurface()和SuperSaverZap.stopInSurface()修饰符不会恢复。如果修饰符没有执行或还原，则函数的执行将返回默认值，这可能会误导调用者。

ERC20toUniPoolZapV1_General.addLiquity在_UniSwapExchangeContractAddress余额上严格相等。此行为可能允许攻击者通过向_UniSwapExchangeContractAddress发送令牌来陷阱协定。

Crytic发现了另一个在DOSNetwork中并不广为人知的问题：如果使用多个动态参数调用abi.encodedPacked，则可以使用不同的参数返回相同的值。

此模式容易发生冲突，使用不同的数据源和选择器的两个调用可能会导致相同的queryId(有关详细信息，请参阅Solidity文档)。

不要在encodePacked中使用多个动态类型，并考虑首先使用keccak256散列数据源和选择器。

在基线协议中，Crtic发现了一个架构问题，其中包括：实现接口的契约不继承它。

Shield是ERC1820ImplementerInterface的实现，但它不从接口继承。此行为容易出错，可能会阻止实现或接口正确更新。

Crytic在ethKids中发现了另一个不寻常的问题：*this.Balance包括当前事务的金额(msg.value)，这可能会导致不正确的值计算。

在fundWithAward中使用this.Balance不会考虑msg.value已经添加的值。因此，价格计算是不正确的。

msg.value已经存在于此.Balance中。例如，如果this.Balance在交易前是10以太，而msg.value是1eth，那么在交易期间this.Balance将是11以太)。结果，msg.value被使用了两次，culatePurche eReturn计算错误。

更改价格计算，以便_Reserve veBalance不包括事务中发送的金额。

最后，Crtic在HQ20中发现了一个众所周知的问题：可重入性。这种可重入性很有趣，因为如果协定与具有回调功能的令牌(如ERC777)一起使用，就会发生这种情况。这类似于最近的uniswap和lendf.me黑客攻击。

在不遵循检查效果交互模式的情况下，Classfied调用从外部令牌转移。如果目标令牌具有回调机制(例如，ERC777令牌)，则这会导致可被攻击者利用的重入性。

Crytic可以将代码库从关键缺陷中拯救出来，并帮助您设计更安全的代码。有什么不喜欢的？

今天就报名参加Crtic吧。有问题吗？加入我们的松弛频道(#Crytic)或在Twitter上关注@CryticCi。