Force DAO 是最近的 DeFi 明星项目，但它一上线就发生了严重的安全事故。目前 FORCE DAO 空投已经暂停。本期本周热点将会为你介绍区块链安全，以及回顾 FORCE DAO 的安全漏洞。

安全

安全是个有人在意，有人不在意的问题。随着互联网的兴盛，各种数据泄露，黑客攻击也层出不穷。相比过去的小打小闹，现在的黑客行动有着更加明确的目标，强大的破坏力。在区块链中，安全是重中之重。因为区块链与钱的连接更加紧密，黑客们更有攻击的动力。一个严重的安全问题可能导致一个区块链项目的失败。有关区块链给安全带来的独特挑战，我们有机会再介绍。

从*项目方的披露中*我们可以了解攻击的流程。受到攻击的是 xFORCE Vault。这个合约负责 xFROCE 代币的生成和销毁。正常的逻辑是用户抵押 FORCE 代币，收到 xFORCE 代币。漏洞是没有校验 FORCE 代币的转账结果。这导致攻击者可以让 FORCE 代币转账失败，但仍旧收到 xFORCE 代币。

没有校验函数返回值是智能合约中很常见的问题。在此次事件中，攻击者就是利用了合约并没有处理 FORCE 代币 transferFrom 的返回值，凭空铸造了很多 xFORCE。然后将 xFORCE 销毁，换回 FORCE。合约认为 transferFrom 必定成功，即使用户并没有真的把 FORCE 转给智能合约。漏洞在*ForceProfitSharing.sol L43* 。

在开发过程中我们可以添加代码来处理 transferFrom 的返回值。我们也可以使用 SafeERC20 的 safeTransferFrom 使用 safeTransferFrom 时，如果转账失败整个交易会进行回滚。

我个人觉得这是一个十分容易发现的漏洞。不需要人工审计，静态分析器也能发现这个问题。很有可能项目方没有进行正规的代码审计。

在报告中他们提到 xFORCE vault 代码来自 xSUSHI，FORCE 来自 Aragon Minime。xSUSHI 代码假设转账操作失败会回滚，然而 FORCE 并没有实现转账失败回滚的功能（缝合失败）。我们可以理解为项目方借用了其他项目的代码，但并没有弄清楚这些代码运行的前提。

DEFI 开发越来越复杂，开发者们会去复用其他项目的一些代码。然而这些项目代码在编写之初并没有考虑到被他人使用，因此文档不够完善。这种稀里糊涂使用别人的代码的行为在未来或许会导致更多的问题。

因此，作为一个智能合约开发者，只掌握开发技术是不够的，我们还需要了解基本的安全漏洞。如果注意这几点，一个智能合约应该可以规避绝大部分漏洞：

1. 使用静态工具进行分析，例如 Slither。理解，评估静态工具生成的漏洞报告，这需要开发者熟悉常见的漏洞及其危害。

2. 再三检查合约代码中跟钱有关的的逻辑。比如转账的数量，转账的前置条件等。

Force DAO 是最近的 DeFi 明星项目，但它一上线就发生了严重的安全事故。目前 FORCE DAO 空投已经暂停。本期本周热点将会为你介绍区块链安全，以及回顾 FORCE DAO 的安全漏洞。

安全

安全是个有人在意，有人不在意的问题。随着互联网的兴盛，各种数据泄露，黑客攻击也层出不穷。相比过去的小打小闹，现在的黑客行动有着更加明确的目标，强大的破坏力。在区块链中，安全是重中之重。因为区块链与钱的连接更加紧密，黑客们更有攻击的动力。一个严重的安全问题可能导致一个区块链项目的失败。有关区块链给安全带来的独特挑战，我们有机会再介绍。

从*项目方的披露中*我们可以了解攻击的流程。受到攻击的是 xFORCE Vault。这个合约负责 xFROCE 代币的生成和销毁。正常的逻辑是用户抵押 FORCE 代币，收到 xFORCE 代币。漏洞是没有校验 FORCE 代币的转账结果。这导致攻击者可以让 FORCE 代币转账失败，但仍旧收到 xFORCE 代币。

没有校验函数返回值是智能合约中很常见的问题。在此次事件中，攻击者就是利用了合约并没有处理 FORCE 代币 transferFrom 的返回值，凭空铸造了很多 xFORCE。然后将 xFORCE 销毁，换回 FORCE。合约认为 transferFrom 必定成功，即使用户并没有真的把 FORCE 转给智能合约。漏洞在*ForceProfitSharing.sol L43* 。

在开发过程中我们可以添加代码来处理 transferFrom 的返回值。我们也可以使用 SafeERC20 的 safeTransferFrom 使用 safeTransferFrom 时，如果转账失败整个交易会进行回滚。

我个人觉得这是一个十分容易发现的漏洞。不需要人工审计，静态分析器也能发现这个问题。很有可能项目方没有进行正规的代码审计。

在报告中他们提到 xFORCE vault 代码来自 xSUSHI，FORCE 来自 Aragon Minime。xSUSHI 代码假设转账操作失败会回滚，然而 FORCE 并没有实现转账失败回滚的功能（缝合失败）。我们可以理解为项目方借用了其他项目的代码，但并没有弄清楚这些代码运行的前提。

DEFI 开发越来越复杂，开发者们会去复用其他项目的一些代码。然而这些项目代码在编写之初并没有考虑到被他人使用，因此文档不够完善。这种稀里糊涂使用别人的代码的行为在未来或许会导致更多的问题。

因此，作为一个智能合约开发者，只掌握开发技术是不够的，我们还需要了解基本的安全漏洞。如果注意这几点，一个智能合约应该可以规避绝大部分漏洞：

1. 使用静态工具进行分析，例如 Slither。理解，评估静态工具生成的漏洞报告，这需要开发者熟悉常见的漏洞及其危害。

2. 再三检查合约代码中跟钱有关的的逻辑。比如转账的数量，转账的前置条件等。