堅牢性の再所属を防ぐ方法は？

堅牢性の再発は、外部呼び出しが悪意のある契約が同じ機能を再帰的に実行し、潜在的に排出された資金または腐敗状態を再帰的に実行することを許可する場合に発生します。

2025/07/20 08:49

堅実さでの再所属を理解する

再発は、内部状態の変更を完了する前に関数が信頼されていない契約に外部呼び出しを行うときに発生するSolidity Smart Contractsの重大なセキュリティの脆弱性です。これにより、外部契約は元の機能に再帰的に呼び戻すことができ、潜在的に資金を排出したり、契約のロジックを破壊したりすることができます。

2016年の悪名高いダオハックは、再発をどのように活用できるかの代表的な例でした。攻撃者は、契約がバランスを更新する前に、悪意のあるフォールバック関数を使用して引き出しを繰り返し引き起こし、数百万のエーテルを失いました。

このような脆弱性を防ぐために、開発者は外部呼び出しを確保するベストプラクティスと設計パターンを実装し、外部の相互作用の前に状態の変更が発生するようにする必要があります。

Checks-effects-interactionsパターンを使用します

再発を防ぐ最も効果的な方法の1つは、チェック効果のインタラクションパターンに従うことです。このパターンにより、外部呼び出しが実行される前に、すべての内部状態の変更が行われます。

• チェック：入力と条件を検証します。
• 効果：契約の状態変数を更新します。
• 相互作用：外部契約を呼び出すか、エーテルを送信します。

この命令を順守することにより、再発の試みが発生したとしても、内部状態がすでに更新されており、二重の支出または不正なバランスアクセスを防止していることを確認します。

たとえば、単純な引き出し関数を考えてみましょう。

 function withdraw(uint amount) public { require(balances[msg.sender] >= amount); balances[msg.sender] -= amount; (bool success, ) = msg.sender.call{value: amount}(''); require(success);

}

この場合、バランスは外部呼び出しの前に更新され、再発から安全になります。

Mutexロックを実装します

再発を防ぐためのもう1つの効果的な方法は、 Mutex Lockを使用することです。これは、実行中の再発を防ぐ状態変数です。

簡単な例には、ブールフラグを使用して再入国をブロックすることが含まれます。

 bool private locked;関数撤回（UINT量）public {





require(!locked); locked = true; require(balances[msg.sender] >= amount); balances[msg.sender] -= amount; (bool success, ) = msg.sender.call{value: amount}(''); require(success); locked = false;
 }

これにより、機能がまだ実行中に再入力できないことが保証され、再帰的な呼び出しを効果的にブロックします。ただし、開発者は、ミューテックスを使用するときにデッドロックや予期しない動作を作成しないように注意する必要があります。

OpenzeppelinのReentrancyGuardを使用します

Mutexロジックを手動で実装する代わりに、開発者は、安全でテストされたソリューションを提供するOpenzePpelinが提供するReentrancyGuard契約を使用できます。

ReentrancyGuardを使用するには：

• 契約のインポート： import '@openzeppelin/contracts/security/ReentrancyGuard.sol';
• あなたの契約でそれから継承する： contract MyContract is ReentrancyGuard
• nonReentrant修飾子を再発の影響を受けやすい関数に適用します。

 pragma solidity ^0.8.0; '@openzeppelin/contracts/security/reintrancyguard.sol'をインポートします。





契約securewithdrawalはreintrancyguardです{




mapping(address => uint) public balances; function deposit() external payable { balances[msg.sender] += msg.value; } function withdraw(uint amount) external nonReentrant { require(balances[msg.sender] >= amount, 'Insufficient balance'); balances[msg.sender] -= amount; (bool success, ) = msg.sender.call{value: amount}(''); require(success, 'Transfer failed'); }
 }

このアプローチは、ミューテックスの取り扱いの複雑さを抽象化し、バグを導入するリスクを減らし、多くの開発者にとって好ましい方法になります。

生の通話を避け、安全に転送してください

Solidityでは、 address.call{value: ...}('')を使用すると、 transfer()またはsend()よりも柔軟性がありますが、ガス制限も削除され、再発に対して脆弱になります。

• transfer()およびsend()は2300ガスのみを転送します。これは意味のある実行には不十分であり、それにより再発を防ぎます。
• ただし、 call()は利用可能なすべてのガスを転送し、攻撃者がフォールバック中に複雑な悪意のあるロジックを実行したり、機能を受け取ったりすることができます。

これを軽減するには：

• 単純なエーテル転送の場合はtransfer()またはsend()選択します。
• call()を使用する必要がある場合は、コールの前に状態の変更が発生し、その再発ガードが配置されていることを確認してください。

FAQ：よくある質問

Q：堅実さの再発攻撃とは何ですか？

A：再発攻撃は、外部契約が処刑を完了する前に呼び出し関数に呼び戻し、しばしば許可されていないファンドの撤回または州の腐敗につながるときに発生します。

Q：openzeppelinのReintrancyguardを使用せずに再所属を防ぐことはできますか？

A：はい、チェックエフェクトインタラクションパターンを手動で実装するか、ミューテックスロックを使用して関数実行中の再発をブロックします。

Q：現代の堅牢性バージョンでaddress.transfer（）を使用しても安全ですか？

A： transfer()がガスを制限し、再発を防ぎますが、受信者契約がガスがなくなった場合、予期せずに失敗する可能性があります。単純な転送の場合call()よりも安全であると考えられています。

Q：すべての外部呼び出しは、堅牢性のすべての再所属に対して脆弱ですか？

A：すべてではありませんが、ユーザー制御契約への外部呼び出しは潜在的なベクトルになる可能性があります。脆弱性は、状態がコール自体ではなく、外部呼び出しに続くと発生します。