# 一般的なDeFiセキュリティの脆弱性と注意事項最近、安全専門家がコミュニティメンバーのために分散型金融のセキュリティ講座を共有しました。専門家は、過去一年以上にわたりWeb3業界で発生した重大なセキュリティ事件を振り返り、これらのセキュリティ事件が発生した理由とその回避方法を探討し、一般的なスマートコントラクトのセキュリティホールと予防策をまとめ、プロジェクト側と一般ユーザーにいくつかのセキュリティアドバイスを提供しました。一般的な分散型金融の脆弱性のタイプには、フラッシュローン、価格操作、関数権限の問題、任意の外部呼び出し、フォールバック関数の問題、ビジネスロジックの脆弱性、秘密鍵の漏洩、再入攻撃などがあります。以下では、フラッシュローン、価格操作、再入攻撃のこの3つのタイプについて重点的に紹介します。## フラッシュローンフラッシュローン自体は分散型金融の一種の革新ですが、ハッカーがそれを悪用すると、彼らはコストなしで大量の資金を借りて、アービトラージプロセス全体を実行した後、わずかなガス料金を支払うだけで巨額の利益を得ることができます。過去2年間、フラッシュローンには多くの問題が発生しました。一部の分散型金融プロジェクトは高い収益を上げているように見えますが、実際にはプロジェクトのレベルはまちまちです。中には、コードが購入された可能性があるプロジェクトもあり、コード自体に脆弱性がなくても、論理的に問題が存在する可能性があります。例えば、かつてあるプロジェクトは、固定された時間に保有者が持っているトークンの数量に応じて報酬を配布しましたが、攻撃者はフラッシュローンを利用して大量のトークンを購入し、報酬が配布される際に大部分の報酬が攻撃者に流れてしまいました。また、トークンを通じて価格を計算するプロジェクトもあり、フラッシュローンを利用して価格に影響を与えることができます。プロジェクト側は、これらの問題に対して警戒を強めるべきです。## 価格操作価格操作の問題はフラッシュローンと密接に関連しており、この問題は主に価格計算時に一部のパラメータがユーザーによって制御可能であることから生じます。よく見られる問題のタイプは2つあります。1. 価格を計算する際に第三者のデータを使用するが、使用方法が不適切またはチェックが欠如しているため、価格が悪意を持って操作される。2. 一部のアドレスのトークン数量を計算変数として使用し、これらのアドレスのトークン残高は一時的に増加または減少する可能性があります。## リエントランシー攻撃外部コントラクトを呼び出す主要な危険の一つは、制御フローを引き継ぎ、あなたのデータに対して関数を予期しない変更を加えることができるということです。ユーザーの残高は関数の最後まで0に設定されないため、2回目の(およびそれ以降の)の呼び出しは成功し続け、残高を何度も引き出すことができます。異なる契約に対して、再入可能性の存在方法は多岐にわたります。契約の異なる関数や複数の異なる契約の関数を組み合わせて再入攻撃を実行することができます。したがって、再入問題を解決する際には、以下の点に注意する必要があります。1. 単一の関数の再入問題を防ぐだけではない;2. エンコードについては、Checks-Effects-Interactions パターンに従います。3. 時間が検証された再入防止モディファイアを使用する。実際に最も恐れているのは、車輪を繰り返し作ることです。必要なものはすべて自分で書かなければなりません。この業界には多くのベストセキュリティプラクティスがあり、それを使えば良いので、完全に車輪を再度作る必要はありません。車輪を作るとき、それは十分に検証されていないため、この時に問題が発生する確率は、非常に成熟した検証済みのものを使う場合の問題が発生する確率よりも明らかに大きくなります。## セキュリティの提案### プロジェクト側の安全ティップス1. 契約開発は最良のセキュリティプラクティスに従います。2. コントラクトはアップグレード可能で、一時停止できます: 多くの攻撃は一度にすべてのコインを移動させるのではなく、複数の取引に分けて実行されます。もし比較的健全な監視メカニズムがあれば、発見することができます。発見後、コントラクトが一時停止できると仮定すれば、損失を効果的に軽減することができます。3. タイムロックの採用: タイムロックがある場合、例えば48時間以内に完了しなければならないと仮定すると、その間にタイムロックの多くの人々がこの作成者が新たにmintの方法を更新したことを発見し、誰でも使用できることになり、監視している人々はプロジェクトがハッキングされたことを認識し、プロジェクト側に通知することができます。仮に通知されたとしても誰も気にかけない場合、少なくとも自分の一部の資金を取り出し、まず自分の利益が損なわれないことを保証できます。したがって、プロジェクトにタイムロックがない場合、理論的には問題が発生する確率が増加します。4. セキュリティ投資を増やし、完備したセキュリティシステムを構築する: セキュリティは一点ではなく、一線ではなく、システム全体に関わるものである。プロジェクト側として、契約が多くの会社によって監査されれば問題ないと考えてはいけない。リスクモデリングをできるだけ行い、徐々に大部分のリスクを回避し、残ったリスクは受け入れ可能なリスクであり、許容範囲内であるべきだ。セキュリティと効率は両立することは不可能であり、一定の妥協が必要である。しかし、セキュリティを全く無視し、セキュリティへの投資をしない場合、攻撃を受けるのは非常に普通のことである。5. すべての従業員のセキュリティ意識を高める: セキュリティ意識を高めるために多くの技術は必要ありません。この大きな環境の中で、少し多くの「なぜ」を尋ね、少し多くのことを考えるだけで多くの問題を回避できます。6. 内部の悪事を防ぎ、効率を高めながらリスク管理を強化する。7. サードパーティの導入の安全性: エコシステムの一環として、プロジェクト側にはそれぞれの上下流があります。安全性に関しては「デフォルトで上下流はすべて安全ではない」という原則があります。上流にも下流にも検証を行う必要があります。サードパーティに関しては、私たちは管理が非常に難しく、安全のリスクは実際に特に大きいので、サードパーティの導入には非常に注意が必要です。契約はオープンソースであり、それを導入したり呼び出したりすることができます; もし契約がオープンソースでなければ、絶対に引用してはいけません。### ユーザー/LP はどのようにスマートコントラクトが安全かどうか判断しますか?一般のユーザーにとって、プロジェクトが安全かどうかを判断する際には、主に以下の6点を見ます:1. コントラクトはオープンソースですか: コントラクトがオープンソースでないプロジェクトには絶対に手を出しません。なぜなら、コントラクトが何を書いているのか全くわからないからです。2. オーナーはマルチシグを採用していますか？マルチシグは分散型ですか？: マルチシグを使用しない場合、プロジェクトのビジネスロジックや内容を判断できません。安全事件が発生した場合、ハッカーによるものかどうか判断できません。たとえマルチシグを採用しても、それが分散型であるかどうかを判断する必要があります。3. 契約の既存の取引状況: 特に市場には多くのフィッシング詐欺プロジェクトが存在し、比較的似たような契約を作成する可能性があります。この場合、契約のデプロイ時間やインタラクション回数などを確認する必要があります。これらは契約が安全であるかどうかを判断するための指標です。4. 契約は代理契約ですか？アップグレード可能ですか？タイムロックはありますか？契約が完全にアップグレードできない場合は、あまりにも硬直しているため、プロジェクトの契約はアップグレード可能な方が推奨されます。しかし、アップグレードには方法が重要であり、アップグレード内容や重要なパラメータの変更がある場合は、タイムロックを設定し、ユーザーが実際のアップグレードが有害か有益かを判断するための時間ウィンドウを提供する必要があります。これは、公開透明性の一つの方法でもあります。5. 契約は複数の機関による監査を受けていますか(監査会社を盲信しない), オーナーの権限は過大ですか: まず、一つの監査会社だけを信じないでください。なぜなら、異なる監査会社、異なる監査員によって、問題を考える視点が異なるからです。次に、オーナーの権限が過大でないかを確認する必要があります。正常なプロジェクトのオーナーの権限は必ず制御可能であるべきで、そうすれば高リスクな操作があまり発生せず、操作もタイムロックの形で行われ、ユーザーが操作内容を知ることができます。6. オラクルに注意: プロジェクトが市販の主要なオラクルを使用している場合、基本的には大きな問題はありませんが、独自に構築したオラクルや、いくつかのトークンを適当に担保にして価格を提供できるオラクルを使用している場合は注意が必要です。オラクルに問題がある可能性がある、または操作される可能性があることがわかった場合、プロジェクトの利益がいかに高くても参加すべきではありません。! [Cobo DeFiセキュリティセクション(パートII):D eFiの一般的なセキュリティの脆弱性と防止](https://img-cdn.gateio.im/social/moments-cf2aa755426b31e8f21cbb05cc1fe39a)
DeFiセキュリティコース:一般的な脆弱性と予防策
一般的なDeFiセキュリティの脆弱性と注意事項
最近、安全専門家がコミュニティメンバーのために分散型金融のセキュリティ講座を共有しました。専門家は、過去一年以上にわたりWeb3業界で発生した重大なセキュリティ事件を振り返り、これらのセキュリティ事件が発生した理由とその回避方法を探討し、一般的なスマートコントラクトのセキュリティホールと予防策をまとめ、プロジェクト側と一般ユーザーにいくつかのセキュリティアドバイスを提供しました。
一般的な分散型金融の脆弱性のタイプには、フラッシュローン、価格操作、関数権限の問題、任意の外部呼び出し、フォールバック関数の問題、ビジネスロジックの脆弱性、秘密鍵の漏洩、再入攻撃などがあります。以下では、フラッシュローン、価格操作、再入攻撃のこの3つのタイプについて重点的に紹介します。
フラッシュローン
フラッシュローン自体は分散型金融の一種の革新ですが、ハッカーがそれを悪用すると、彼らはコストなしで大量の資金を借りて、アービトラージプロセス全体を実行した後、わずかなガス料金を支払うだけで巨額の利益を得ることができます。
過去2年間、フラッシュローンには多くの問題が発生しました。一部の分散型金融プロジェクトは高い収益を上げているように見えますが、実際にはプロジェクトのレベルはまちまちです。中には、コードが購入された可能性があるプロジェクトもあり、コード自体に脆弱性がなくても、論理的に問題が存在する可能性があります。例えば、かつてあるプロジェクトは、固定された時間に保有者が持っているトークンの数量に応じて報酬を配布しましたが、攻撃者はフラッシュローンを利用して大量のトークンを購入し、報酬が配布される際に大部分の報酬が攻撃者に流れてしまいました。また、トークンを通じて価格を計算するプロジェクトもあり、フラッシュローンを利用して価格に影響を与えることができます。プロジェクト側は、これらの問題に対して警戒を強めるべきです。
価格操作
価格操作の問題はフラッシュローンと密接に関連しており、この問題は主に価格計算時に一部のパラメータがユーザーによって制御可能であることから生じます。よく見られる問題のタイプは2つあります。
価格を計算する際に第三者のデータを使用するが、使用方法が不適切またはチェックが欠如しているため、価格が悪意を持って操作される。
一部のアドレスのトークン数量を計算変数として使用し、これらのアドレスのトークン残高は一時的に増加または減少する可能性があります。
リエントランシー攻撃
外部コントラクトを呼び出す主要な危険の一つは、制御フローを引き継ぎ、あなたのデータに対して関数を予期しない変更を加えることができるということです。
ユーザーの残高は関数の最後まで0に設定されないため、2回目の(およびそれ以降の)の呼び出しは成功し続け、残高を何度も引き出すことができます。
異なる契約に対して、再入可能性の存在方法は多岐にわたります。契約の異なる関数や複数の異なる契約の関数を組み合わせて再入攻撃を実行することができます。したがって、再入問題を解決する際には、以下の点に注意する必要があります。
単一の関数の再入問題を防ぐだけではない;
エンコードについては、Checks-Effects-Interactions パターンに従います。
時間が検証された再入防止モディファイアを使用する。
実際に最も恐れているのは、車輪を繰り返し作ることです。必要なものはすべて自分で書かなければなりません。この業界には多くのベストセキュリティプラクティスがあり、それを使えば良いので、完全に車輪を再度作る必要はありません。車輪を作るとき、それは十分に検証されていないため、この時に問題が発生する確率は、非常に成熟した検証済みのものを使う場合の問題が発生する確率よりも明らかに大きくなります。
セキュリティの提案
プロジェクト側の安全ティップス
契約開発は最良のセキュリティプラクティスに従います。
コントラクトはアップグレード可能で、一時停止できます: 多くの攻撃は一度にすべてのコインを移動させるのではなく、複数の取引に分けて実行されます。もし比較的健全な監視メカニズムがあれば、発見することができます。発見後、コントラクトが一時停止できると仮定すれば、損失を効果的に軽減することができます。
タイムロックの採用: タイムロックがある場合、例えば48時間以内に完了しなければならないと仮定すると、その間にタイムロックの多くの人々がこの作成者が新たにmintの方法を更新したことを発見し、誰でも使用できることになり、監視している人々はプロジェクトがハッキングされたことを認識し、プロジェクト側に通知することができます。仮に通知されたとしても誰も気にかけない場合、少なくとも自分の一部の資金を取り出し、まず自分の利益が損なわれないことを保証できます。したがって、プロジェクトにタイムロックがない場合、理論的には問題が発生する確率が増加します。
セキュリティ投資を増やし、完備したセキュリティシステムを構築する: セキュリティは一点ではなく、一線ではなく、システム全体に関わるものである。プロジェクト側として、契約が多くの会社によって監査されれば問題ないと考えてはいけない。リスクモデリングをできるだけ行い、徐々に大部分のリスクを回避し、残ったリスクは受け入れ可能なリスクであり、許容範囲内であるべきだ。セキュリティと効率は両立することは不可能であり、一定の妥協が必要である。しかし、セキュリティを全く無視し、セキュリティへの投資をしない場合、攻撃を受けるのは非常に普通のことである。
すべての従業員のセキュリティ意識を高める: セキュリティ意識を高めるために多くの技術は必要ありません。この大きな環境の中で、少し多くの「なぜ」を尋ね、少し多くのことを考えるだけで多くの問題を回避できます。
内部の悪事を防ぎ、効率を高めながらリスク管理を強化する。
サードパーティの導入の安全性: エコシステムの一環として、プロジェクト側にはそれぞれの上下流があります。安全性に関しては「デフォルトで上下流はすべて安全ではない」という原則があります。上流にも下流にも検証を行う必要があります。サードパーティに関しては、私たちは管理が非常に難しく、安全のリスクは実際に特に大きいので、サードパーティの導入には非常に注意が必要です。契約はオープンソースであり、それを導入したり呼び出したりすることができます; もし契約がオープンソースでなければ、絶対に引用してはいけません。
ユーザー/LP はどのようにスマートコントラクトが安全かどうか判断しますか?
一般のユーザーにとって、プロジェクトが安全かどうかを判断する際には、主に以下の6点を見ます:
コントラクトはオープンソースですか: コントラクトがオープンソースでないプロジェクトには絶対に手を出しません。なぜなら、コントラクトが何を書いているのか全くわからないからです。
オーナーはマルチシグを採用していますか？マルチシグは分散型ですか？: マルチシグを使用しない場合、プロジェクトのビジネスロジックや内容を判断できません。安全事件が発生した場合、ハッカーによるものかどうか判断できません。たとえマルチシグを採用しても、それが分散型であるかどうかを判断する必要があります。
契約の既存の取引状況: 特に市場には多くのフィッシング詐欺プロジェクトが存在し、比較的似たような契約を作成する可能性があります。この場合、契約のデプロイ時間やインタラクション回数などを確認する必要があります。これらは契約が安全であるかどうかを判断するための指標です。
契約は代理契約ですか？アップグレード可能ですか？タイムロックはありますか？契約が完全にアップグレードできない場合は、あまりにも硬直しているため、プロジェクトの契約はアップグレード可能な方が推奨されます。しかし、アップグレードには方法が重要であり、アップグレード内容や重要なパラメータの変更がある場合は、タイムロックを設定し、ユーザーが実際のアップグレードが有害か有益かを判断するための時間ウィンドウを提供する必要があります。これは、公開透明性の一つの方法でもあります。
契約は複数の機関による監査を受けていますか(監査会社を盲信しない), オーナーの権限は過大ですか: まず、一つの監査会社だけを信じないでください。なぜなら、異なる監査会社、異なる監査員によって、問題を考える視点が異なるからです。次に、オーナーの権限が過大でないかを確認する必要があります。正常なプロジェクトのオーナーの権限は必ず制御可能であるべきで、そうすれば高リスクな操作があまり発生せず、操作もタイムロックの形で行われ、ユーザーが操作内容を知ることができます。
オラクルに注意: プロジェクトが市販の主要なオラクルを使用している場合、基本的には大きな問題はありませんが、独自に構築したオラクルや、いくつかのトークンを適当に担保にして価格を提供できるオラクルを使用している場合は注意が必要です。オラクルに問題がある可能性がある、または操作される可能性があることがわかった場合、プロジェクトの利益がいかに高くても参加すべきではありません。
! Cobo DeFiセキュリティセクション(パートII):D eFiの一般的なセキュリティの脆弱性と防止