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

最近、あるセキュリティ専門家がコミュニティメンバーに分散型金融のセキュリティに関する話題を共有しました。この専門家は、過去1年以上にわたってWeb3業界が直面した重大なセキュリティ事件を振り返り、これらの事件の原因と回避方法について深く掘り下げ、一般的なスマートコントラクトのセキュリティ脆弱性と予防策をまとめ、プロジェクトチームと一般ユーザーにいくつかのセキュリティアドバイスを提供しました。

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

フラッシュローン

フラッシュローンは分散型金融の一つの革新ですが、ハッカーによって利用されることもあります。攻撃者はフラッシュローンを使って大量の資金を借り出し、価格を操作したりビジネスロジックを攻撃したりすることができます。開発者は、契約の機能が巨額の資金によって異常になるか、または一度の取引で複数の関数と相互作用して不正な利益を得るために利用されるかを考慮する必要があります。

多くの分散型金融プロジェクトは高い利益に見えますが、プロジェクトチームのレベルはまちまちです。コード自体に脆弱性がなくても、論理的に問題が存在する可能性があります。例えば、あるプロジェクトは固定時間に保有量に応じて報酬を配布しますが、攻撃者がフラッシュローンを利用して大量のトークンを購入し、報酬が配布される際に大部分の利益を得ることがあります。また、Tokenで価格を計算するプロジェクトも、フラッシュローンによって価格に影響を受けやすいです。プロジェクトチームはこれらの問題に注意を払うべきです。

価格操作

価格操縦問題はフラッシュローンと密接に関連しており、主に価格計算時に特定のパラメータがユーザーによって制御されるためです。一般的には2つの状況があります:

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

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

リエントランシー攻撃

外部契約を呼び出す主要なリスクの1つは、それらが制御フローを引き継ぎ、データに予期しない変更を加える可能性があることです。例えば:

ソリディティ マッピング (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. Ownerが分散型のマルチシグを採用しているか確認する

3. 既存の契約の取引状況を確認する: 配備時間、インタラクション回数など

4. コントラクトが代理コントラクトであるか、アップグレード可能であるか、タイムロックがあるかを確認する

5. 契約が複数の機関による監査を受けたかどうか、オーナーの権限が過大でないか確認してください。

6. オラクルの信頼性に注意: 主要なオラクルは比較的安全ですが、自前のオラクルや低コストのオラクルは注意が必要です。

要するに、分散型金融の分野では、参加者は常に警戒を怠らず、プロジェクト側は安全性の問題を全方位で考慮し、ユーザーはプロジェクトの安全性を慎重に評価してから意思決定を行うべきです。

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