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

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

一般的な分散型金融の脆弱性のタイプには、フラッシュローン、価格操作、関数権限の問題、任意の外部呼び出し、フォールバック関数の問題、ビジネスロジックの脆弱性、秘密鍵の漏洩、再入攻撃などがあります。以下では、フラッシュローン、価格操作、再入攻撃の3つのタイプについて重点的に紹介します。

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

フラッシュローン

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

過去2年間、フラッシュローンの問題が頻発しています。いくつかのプロジェクトは一見高い収益を上げているようですが、実際にはプロジェクトチームのレベルがまちまちです。コード自体に脆弱性がなくても、論理的に問題が存在する可能性があります。例えば、あるプロジェクトは固定された時間に保有者が持っているトークンの数量に基づいて報酬を配布するのですが、攻撃者がフラッシュローンを利用して大量のトークンを購入し、報酬が配布される際に大部分の報酬を獲得することがあります。また、トークンを使用して価格を計算するプロジェクトもあり、フラッシュローンを通じて価格に影響を与えることができます。プロジェクトチームはこれらの問題に対して警戒を高めるべきです。

価格操作

価格操縦問題とフラッシュローンは密接に関連しており、主に2つのタイプがあります:

1. 価格を計算する際に第三者データを使用しますが、その使用方法が不正確であるか、チェックが欠如しているために価格が悪意を持って操作される可能性があります。

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

リエントランシー攻撃

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

異なる契約に対して、再入可能性が存在する方法は多く、契約の異なる関数や複数の異なる契約の関数を組み合わせて再入攻撃を行うことができます。したがって、再入問題を解決する際には注意が必要です。

1. 単一の関数の再入問題を防ぐだけではない

2. Checks-Effects-Interactions パターンに従ってコーディングを行う

3. 時間が検証された再入防止モディファイアを使用する

最も恐れているのは、車輪を再び作ることであり、必要なものはすべて自分で書かなければならないことです。この業界には多くのベストセキュリティプラクティスがあり、私たちはそれを利用すればよいので、車輪を再び作る必要はまったくありません。車輪を作るとき、それは十分に検証されていないものであり、その時に問題が発生する確率は、非常に成熟した長年の経験を持つものに比べて、明らかに大きくなります。

セキュリティーの提案

プロジェクト側の安全に関するヒント

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

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

3. タイムロックの採用: タイムロックがある場合、例えば48時間以内に完了することが前提で、この期間中に多くの人が作成者が全員が使用できるミント方法を再更新したことに気づくことができ、監視している人はプロジェクトがハッキングされた可能性があることを知り、プロジェクト側に変更を通知することができます。通知しても誰も対応しないかもしれませんが、少なくとも自分の分のお金を取り出すことができ、まず自分の利益が損なわれないことを保証できます。したがって、プロジェクトにタイムロックがない場合、理論的には問題が発生する確率が増加します。

4. 安全投資を強化し、完璧な安全システムを構築する: 安全は点ではなく、線でもない。安全は体系的なものである。プロジェクトチームとして、契約が複数の会社によって監査されただけで問題ないと思わないでください。資金損失を引き起こす可能性のあるリスクを考慮する必要があります。リスクモデリングをできる限り実施し、その後、ほとんどのリスクを段階的に回避し、残されたリスクも受け入れ可能なリスクであり、許容範囲内にあるべきです。安全と効率は両立しないため、ある程度の取捨選択が必要です。しかし、安全を完全に無視し、安全への投資がない場合、攻撃を受けるのは非常に普通です。

5. すべての従業員の安全意識を高める: 安全意識を高めるために多くの技術は必要ありません。この大環境の中で、少し多くの「なぜ」を尋ね、少し多く考えるだけで多くの問題を回避することができます。

6. 内部の悪事を防ぎ、効率を高めながらリスク管理を強化する: 例えば、契約のオーナーが単独署名か複数署名か、時間ロックを使用するかどうかなどを考慮する必要があります。

7. サードパーティの導入の安全性: エコシステムの一環として、プロジェクト側には独自の上流と下流があります。安全性においては「デフォルトで上流も下流も安全ではない」という原則があります。上流および下流の両方に対して検証を行う必要があります。サードパーティに関しては、私たちが制御するのは非常に難しく、安全リスクのエクスポージャーは実際に特に大きいので、サードパーティの導入には非常に注意が必要です。契約はオープンソースであり、それを導入・呼び出すことができます; もし契約がオープンソースでなければ、絶対に引用してはいけません。

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

一般のユーザーにとって、プロジェクトが安全かどうかを判断する際には、以下の6点を主に見る必要があります:

1. コントラクトはオープンソースですか: オープンソースでないプロジェクトには絶対に手を出しません。なぜなら、コントラクトが何を書いているのか全く分からないからです。

2. オーナーはマルチシグを採用していますか、マルチシグは分散型ですか：マルチシグを使用しない場合、プロジェクトのビジネスロジックや内容を判断することができず、一旦安全事件が発生した場合、ハッカーによるものかどうかを判断できません。たとえマルチシグを採用しても、そのマルチシグが分散型であるかを判断する必要があります。

3. 契約の既存の取引状況: 特に市場には多くのフィッシング詐欺のプロジェクトが存在し、比較的類似した契約を作成する可能性があります。このような場合、契約のデプロイ時間やインタラクション回数などを確認する必要があります。これらは契約が安全かどうかを判断するための指標です。

4. コントラクトは代理コントラクトですか？アップグレード可能ですか？タイムロックはありますか？もしコントラクトが完全にアップグレードできない場合、あまりにも硬直しているので、プロジェクトのコントラクトはアップグレード可能であることをお勧めします。ただし、アップグレードには方法が重要で、アップグレード内容や重要なパラメータの変更がある場合、タイムロックを設ける必要があります。ユーザーにとって真のアップグレードが有害か有益かを判断するための時間ウィンドウを提供することは、公開で透明な方法の一つです。

5. 契約は複数の機関の監査を受けていますか(監査会社を盲目的に信頼しない)、Ownerの権限は過大ではないか: まず、ただ一つの監査会社を信じてはいけません。なぜなら、異なる監査会社や異なる監査人は、問題を見る視点が異なるからです。次に、Ownerの権限が過大ではないかを確認する必要があります。正常なプロジェクトでは、Ownerの権限は必ず制御可能であるべきです。そうすれば、高リスクな操作があまり発生せず、操作もタイムロックの方法を使い、ユーザーにどのような操作が行われているかを知らせることができます。

6. オラクルに注意: プロジェクトが市場にある主要なオラクルを使用している場合、基本的に大きな問題はありませんが、独自のオラクルを使用する場合や、適当に担保としていくつかのトークンを持っているだけで価格を提供できるオラクルを使用する場合は注意が必要です。オラクルに問題がある可能性や操作される可能性があることが分かった場合、たとえプロジェクトの利益がどんなに高くても参加してはいけません。