Tact智能合约安全实践:TON生态系统中的常见错误
智能家居安全系统的常见问题解决办法 #生活技巧# #居家生活技巧# #家庭安全技巧# #智能家居设备使用指南#
TON(The Open Network)以其创新特性和强大的智能合约性能,不断拓宽区块链技术的边界。基于早期的区块链平台(如以太坊等)的经验与教训,TON为开发者提供了一个更加高效且灵活的开发环境。其中推动这一进步的关键要素之一便是Tact编程语言。
Tact是专为TON链设计的一种全新编程语言,以高效与简洁为核心目标。它易于学习和使用,并与智能合约完美契合。Tact是一种静态类型语言,拥有简单的语法和强大的类型系统。
尽管如此,开发者在使用FunC时遇到的许多问题,在Tact开发中仍然存在。以下将结合审计实践案例,分析Tact开发中的一些常见错误。
数据结构
可选地址
Tact语言简化了声明、解码和编码的数据结构。然而,开发者仍需保持谨慎。我们来看一个例子:
这是根据TEP-74[1]标准用于转移jetton的内部传输(InternalTransfer)消息声明。请注意response_destination的声明,它是一个地址(Address)类型。在Tact中,要求地址必须是非零地址。然而,jetton标准的参考实现[2]允许零地址(addr_none),它由两个零位表示。这意味着用户或其他合约可能会尝试发送带有零响应地址的jetton,而该操作会意外失败。
此外,如果用户发送给其钱包的Transfer消息允许设置response_destination,而从发送方钱包到接收方钱包的InternalTransfer消息却不支持该参数,那么jetton将会“飞出”,意味着jetton无法到达目标地址,最终导致丢失。稍后,我们将讨论一种例外情况,即如何正确处理被退回的消息。息会被妥善处理。
在这种情况下,允许零地址的更好结构声明应为Address?,但在Tact中,将可选地址传递到下一条消息目前较为繁琐。
数据序列化
在Tact中,开发者可以指定字段的序列化方式。
本例中,totalAmount将序列化为coins,而releasedAmount将序列化为int257(默认为Int)。releasedAmount可以是负值,并且将占用257位。在大多数情况下,省略序列化类型不会带来问题;然而,如果数据涉及到通信,这就变得至关重要。
以下是我们审计的项目中的一个例子:
该数据结构是由NFT项目用作对链上get_static_data[3]请求的回复。根据标准,回复应该是:
上述索引是uint256(而不是int257),这意味着返回的数据将被调用者错误解读,从而导致不可预测的结果。很可能的结果是report_static_data处理程序会发生回滚,消息流也会因此中断。这些例子说明了为什么即使在使用Tact时,考虑数据序列化也是至关重要的。
有符号整数
不指定Int的序列化类型可能会导致比上述示例更严重的后果。与coins不同,int257可以为负值,这常常会让程序员感到意外。例如,在Tact的实时合约中,看到amount: Int是极其常见的。
这种写法本身并不一定意味着存在漏洞,因为该金额(amount)通常会被编码到JettonTransfer消息中,或传递到send(SendParameters{value: amount}),后者使用的是coins类型,不允许负值。然而,在一个案例中,我们发现一个拥有大量余额的合约,它允许用户将所有值设置为负数,包括奖励、手续费、金额、价格等。因此,恶意行为者可能利用这一漏洞进行攻击。
并发
以太坊链的开发者必须注意重入攻击,即在当前函数执行完成之前,能够再次调用同一个合约的函数。而在TON链上,重入攻击是不可能的。
由于TON是一个支持异步和并行智能合约调用的系统,追踪处理动作的顺序可能变得更加困难。任何内部消息都会被目标账户接收,交易结果会在交易本身之后处理,但并没有其他保证。
我们无法预测消息3或消息4哪个会先被送达。
在这种情况下,中间人攻击(Man-in-the-Middle Attack)[5]在消息流中是高发的攻击类型。为了确保安全,开发者应该设定每条消息的传递时间为1到100秒,在此期间,任何其他消息都有可能被传递。以下是一些可以提高安全性的其他注意事项:
1. 不要检查或更新合约状态以供消息流的后续步骤使用。
2. 使用携带值模式(carry-value pattern)[6]。不要直接发送有关值的信息,而是与消息一起发送。
以下是一个存在漏洞的真实例子:
在上述示例中,发生了以下步骤:
1. 用户通过collection_jetton_wallet向NftCollection发送jetton。
2. TransferNotification被发送到NftCollection合约,合约记录了received_jetton_amount。
3. 合约将jetton转发给NftCollection的所有者。
4. 向NftCollection发送Excesses消息,作为response_destination。
5. NftItem在Excesses处理程序中部署,使用received_jetton_amount。
这里有几个问题需要注意:
首先,Excesses消息并不能保证按照jetton标准被送达。如果没有足够的gas费来发送Excesses消息,它将被跳过,消息流将停止。
其次,更新received_jetton_amount并在后续使用它会使系统容易受到并发执行的影响。其他用户可能会同时发送另一个金额并覆盖已保存的金额,这也可能会被恶意利用以从中获利。
在并发的情况下,TON与传统的中心化多线程系统相似。
处理退回消息
许多合约忽视了退回消息的处理。然而,Tact使这一过程变得简单明了:
要决定消息是否应以可退回模式发送,可以考虑两个因素:
1. 如果消息失败,谁应该收到附加的Toncoin?如果目标应该接收这些资金,而不是发送合约,那么就以非可退回模式[7]发送消息。
2. 如果下一个消息被拒绝,消息流会发生什么?如果通过处理退回的消息可以恢复一致的状态,那么最好进行处理。如果不能恢复,最好修改消息流。
以下是jetton标准[8]中的一个例子:
1. Excesses消息以非可退回模式发送,因为合约不需要返回toncoins。
2. 以非可退回模式发送TransferNotification消息,因为forward_ton_amount属于调用者,合约不会保留它。
3. 相反,BurnNotification是以可退回模式发送,因为如果它被jetton主合约退回,钱包需要恢复其余额,以保持total_supply一致。
4. InternalTransfer也是可退回的。如果接收方拒绝资金,发送方的钱包必须更新余额。
请记住以下几点:
1. 退回消息仅接收256位[9]的原始消息;在消息识别之后,有效数据仅有224位。因此,你将得到有限的关于失败操作的信息,通常是存储为coins的某个金额。
2. 如果没有足够的gas费,退回的消息将无法送达。
3. 退回消息本身无法再次被退回。
返回Jetton
在某些情况下,撤销和处理退回消息不是一个选项。最常见的例子是当你的合约收到TransferNotification关于到达的jetton时,退回该消息可能会导致jetton永远被锁定。相反,你应该使用try-catch块[10]来处理。
让我们来看一个例子。在EVM中,当一笔交易被撤销时,所有结果都会被回滚(除了gas——它会被矿工收取)。但在TVM中,“交易”被分解为一系列消息,因此只回滚其中一条消息很可能会导致“合约组”状态不一致。
为了解决这个问题,必须手动检查所有条件,并在紧急情况下来回发送修正消息。然而,由于在没有异常的情况下解析有效载荷非常繁琐,因此最好使用try-catch块。
下面是一个典型的Jetton接收代码示例:
请注意,如果gas费不足,即使是将jettons发送回去也无法正常工作。此外,需要注意的是,我们是通过sender()的“钱包”返还jetton,而不是通过我们合约的实际jetton钱包返还。这是因为任何人都可以手动发送TransferNotification消息来欺骗我们。
管理Gas费
在审计TON合约时,最常见的问题之一就是gas费管理问题。主要原因有两个:
1. 缺乏gas费控制可能导致以下问题:
消息流执行不完整: 部分操作会生效,而另一部分由于gas不足而被回滚。例如,如果奖励获取操作在jetton钱包中完成,但销毁份额操作在jetton主合约中被忽略,那么整个合约组将变得不一致。
用户可以提取自己的合约余额: 此外合约中可能会积累过多的Toncoin。
2. TON合约开发者难以管理和控制gas: Tact的开发者需要通过测试来获得gas消耗量,并在开发过程中每次更新消息流时都更新相应的数值。
我们建议的做法如下:
1. 确定“入口点”:这些是所有可以接受来自“外部”消息的消息处理器,即来自终端用户或其他合约(如Jetton钱包)。
2. 对于每个入口点,绘制所有可能的路径并计算gas消耗。使用printTransactionFees()(可在@ton/sandbox中找到,该工具随Blueprint[11]一起提供)。
3. 如果可以在消息流过程中部署合约,则假设它将被部署。部署将消耗更多的gas费和存储费用。
4. 在每个入口点,根据情况添加最低的gas要求。
5. 如果处理器不发送更多消息(消息流在此终止),那么最好返回Excesses,如下所示:
不发送Excesses也是可以的,但对于像Jetton Master这样的高吞吐量合约,存在大量BurnNotification消息或大量传入转账的合约,累计金额可能会迅速增长。
6. 如果处理器只发送一条消息——包括emit(),实际上是一个外部消息——最简单的方式是通过forward()传递剩余的gas费(见上文)。
7. 如果处理器发送多条消息,或者如果通讯中涉及ton数量,那么计算应发送金额比计算应剩余金额要更容易。
在下一个例子中,假设合约希望将forwardAmount发送给两个子合约作为押金:
正如你所看到的,gas费管理需要高度关注,即使是在简单的情况下。请注意,如果你已经发送了消息,则不能在send()模式中使用SendRemainingValue标志,除非你故意想要从合约余额中支出资金。
结论
随着TON生态系统的发展,Tact智能合约的安全开发将变得越来越重要。虽然Tact提供了更高的效率和简洁性,但开发者必须保持警惕,避免常见的陷阱。通过了解常见错误并实施最佳实践,开发者可以充分开发Tact的潜力,创建强大而安全的智能合约。持续学习并遵循安全实践指南,将确保TON生态的创新能力得到安全有效地利用,从而为更安全、可信的区块链环境作出贡献。
更多相关信息,请,https://t.me/gtokentool
网址:Tact智能合约安全实践:TON生态系统中的常见错误 https://www.yuejiaxmz.com/news/view/553465
相关内容
智能安全实验室-全能优化(Guardio)错误解决(1):“出现异常:EXCEPTIONHarmonyOS Next 打造智能家居安全系统实战
专题丨人工智能系统安全综述
智能家居安全防范系统设计与实现
常见的全屋智能控制系统有哪些?
智能家居安全系统.doc
“Home”安全环保智能化系统
安全智能系统,给你一个安全家!
智能交通灯控制系统:基于FPGA的实践指南
智能安全监控系统:电力系统实时防护与异常检测