一般的なDeFiセキュリティの脆弱性と注意事項

最近、あるセキュリティ専門家がコミュニティメンバーのために分散型金融のセキュリティ講座を共有しました。彼は過去1年以上にわたるWeb3業界で発生した重大なセキュリティ事件を振り返り、これらのセキュリティ事件が発生した理由とその回避方法を探求し、一般的なスマートコントラクトのセキュリティ脆弱性と予防策をまとめ、プロジェクト側と一般ユーザーにいくつかのセキュリティアドバイスを提供しました。

一般的な分散型金融の脆弱性のタイプには、フラッシュローン、価格操作、関数権限の問題、任意の外部呼び出し、フォールバック関数の問題、ビジネスロジックの脆弱性、秘密鍵の漏洩、再入攻撃が含まれます。本記事では、フラッシュローン、価格操作、再入攻撃の3種類に重点を置いて説明します。

! Cobo DeFiセキュリティセクション(パートII):D eFiの一般的なセキュリティの脆弱性と防止

フラッシュローン

フラッシュローン自体は分散型金融の一種の革新ですが、ハッカーに利用されると、彼らはコストをかけずに大量の資金を借り、アービトラージを実行した後に返済し、わずかなガス代を支払うだけで巨額の利益を得ることができます。

多くの分散型金融プロジェクトは、高い収益があるように見えますが、実際にはプロジェクトチームのレベルはまちまちです。いくつかのプロジェクトのコードは購入されたものであり、コード自体に脆弱性がなくても、論理的に問題が存在する可能性があります。例えば、あるプロジェクトは固定の時間に保有者が持っているトークンの数量に基づいて報酬を支給しますが、攻撃者がフラッシュローンを利用して大量のトークンを購入し、報酬の支給時に大部分の報酬を獲得することがあります。

さらに、トークンを使用して価格を計算するプロジェクトもいくつかあり、フラッシュローンによって価格に影響を与えることができます。プロジェクト側はこれらの問題に対して警戒を強めるべきです。

価格操作

価格操作の問題とフラッシュローンの関係は密接で、主に2つの一般的なタイプがあります：

1. 価格を計算する際にサードパーティのデータを使用しますが、使用方法が不適切またはチェックが欠落しているため、価格が悪意を持って操作される可能性があります。

2. 特定のアドレスのトークン数量を計算変数として使用し、これらのアドレスのトークン残高は一時的に増加または減少することができます。

リエントランシー攻撃

外部コントラクトを呼び出す主な危険の一つは、それらが制御フローを引き継ぎ、データに対して予期しない変更を加える可能性があることです。例えば：

ソリディティ マッピング (address => uint) private userBalances;

関数 withdrawBalance() public { uint amountToWithdraw = userBalances[msg.sender]; 成功(bool、) = msg.sender.call.value(amountToWithdraw)("" ); require(success); userBalances[msg.sender] = 0; }

ユーザーの残高は関数の最後まで 0 に設定されないため、2 回目（およびそれ以降）の呼び出しは引き続き成功し、残高を何度も引き出すことができます。

再入問題を解決するためには、以下の点に注意する必要があります。

1. 単一の関数の再入問題を防ぐだけではない
2. Checks-Effects-Interactions パターンに従ってコーディングを行う
3. 時間をかけて検証された再入防止モディファイアを使用する

この分野には多くの最良のセキュリティプラクティスがあり、私たちはそれを直接使用すべきであり、輪を再発明すべきではありません。成熟した、実績のあるソリューションを使用する方が、自分で開発した新しいソリューションが問題を起こす可能性ははるかに低いです。

プロジェクトチームの安全に関する提案

1. コントラクト開発はベストセキュリティプラクティスに従います。

2. コントラクトはアップグレード可能で、一時停止できる：多くの攻撃は一度に全てのコインを移動させるのではなく、複数の取引に分けて実行されます。比較的健全な監視メカニズムがあれば、迅速に発見してコントラクトを一時停止させることができ、損失を効果的に軽減できます。

3. タイムロックの採用：時間ロックがある場合は、異常を発見し、行動を起こすのに十分な時間を与えることができます。

4. セキュリティへの投資を増やし、完璧なセキュリティシステムを構築する：セキュリティは体系的なものであり、契約監査だけでなく、秘密鍵管理、経済モデルなどの複数の側面も含まれます。

5. すべての従業員のセキュリティ意識を高める：多くのセキュリティ問題は、警戒を高めることで回避できます。

6. 内部での悪事を防ぎ、効率を向上させると同時にリスク管理を強化する：マルチシグやタイムロックなどのメカニズムを採用することで、効率を保ちながら安全性を向上させることができます。

7. サードパーティの導入セキュリティ：上下流の両方でセキュリティ検証を実施する必要があり、特にオープンソースでない契約に対しては特に慎重であるべきです。

ユーザー/LP はどのようにスマートコントラクトの安全性を判断しますか?

1. コントラクトはオープンソースですか：オープンソースでないプロジェクトには参加しないでください。

2. オーナーはマルチシグを採用していますか？マルチシグは非中央集権ですか？

3. 既存の契約の取引状況を確認する：展開時間、インタラクション回数などを含む。

4. コントラクトは代理コントラクトですか、アップグレード可能ですか、タイムロックはありますか。

5. 契約は複数の機関による監査を受けていますか？オーナーの権限は過大ですか？

6. オラクルに注意：有名なオラクルを使用しているプロジェクトは相対的に安全であり、自社で構築したり操作されやすいオラクルには特に警戒が必要です。

要するに、Web3 環境では、警戒を保ち、いくつかの「なぜ」を尋ねることで、多くの潜在的なリスクを回避できます。プロジェクト側も一般ユーザーも、安全問題を重視し、十分な安全意識と防止メカニズムを構築すべきです。