Web3 プロジェクトのセキュリティプラクティス要件 V1.0

この記事は GitHub で最初に公開されました。

https://github.com/slowmist/Web3-Project-Security-Practice-Requirements

この記事の関連リンクは GitHub で開くことができます. GitHub でこの記事を見て、フォークして、スターを付けてください.

0x00 背景の概要

0x02 開発プロセス

0x03 解放プロセス

0x04 動作中

0x05 応急処置

Web3 プロジェクトのセキュリティプラクティスの要件には、次のものが含まれます。

0x00 背景の概要

今日では、Web3 プロジェクトに対する攻撃方法が際限なく出現し、プロジェクト間の相互作用がますます複雑になっています.さまざまなプロジェクト間の相互作用は、しばしば新しいセキュリティの問題をもたらします.ほとんどの Web3 プロジェクトの研究開発チームは、一般的に、第一線のセキュリティ攻撃と防御の経験が不足しています.また、Web3 プロジェクトを開発する際には、全体的なビジネス上の議論とビジネス機能の実現に焦点が当てられ、セキュリティシステムの構築を完了するためのエネルギーがなくなるため、Web3 プロジェクトが確実に機能することを保証することは困難です。ライフサイクルセキュリティ全体で。

通常、Web3 プロジェクトのセキュリティを確保するために、プロジェクトチームは優れたブロックチェーンセキュリティチームを雇ってそのコードのセキュリティ監査を実施します. セキュリティ監査が実行された場合にのみ、さまざまなセキュリティ慣行要件をより適切に実装できますが、ブロックチェーンセキュリティチームの監査は短期的なガイドにすぎず、プロジェクトチームが独自のセキュリティシステムを確立することはできません。

したがって、SlowMist セキュリティチームは、Web3 プロジェクトのセキュリティプラクティス要件をオープンソース化して、ブロックチェーンエコシステムのプロジェクトチームが Web3 プロジェクトの対応するセキュリティスキルを習得できるように継続的に支援しています。 Web3 プロジェクトに基づく独自のセキュリティプラクティス要件高度なセキュリティシステムは、監査後に特定のセキュリティ機能を持つこともできます。

0x01 開発準備

要件分析ドキュメントの要件

1. プロジェクトの詳細な説明を含めるようにしてください

2. プロジェクトが解決する問題を必ず含めてください

3. セキュリティ/プライバシーリスク評価を必ず含める

開発設計ドキュメントの要件

1. プロジェクトのアーキテクチャ設計図を必ず含める

2. 関数の機能説明をコードに含めるようにしてください。

3. コード内のコントラクト間の関係の記述を必ず含めてください。

4. セキュリティ/プライバシー要件が適切に実装されていることを確認する

ビジネスプロセスドキュメントの要件

1. プロジェクト内の各ビジネスプロセスの説明を必ず含める

2. 詳細な業務プロセス図を必ず含める

3. 詳細な資金調達リンク図を必ず含めてください

0x02 開発プロセス

スマートコントラクトのセキュアコーディング要件

1. OpenZeppelin などの有名なライブラリに基づく開発を可能な限り含めるようにしてください。

2. オーバーフローの問題を回避するために、SafeMath または 0.8.x を使用するコンパイラを含めるようにしてください。

3. 関数の命名規則に従っていることを確認してください。以下を参照してください: solidity スタイルガイド

(https://docs.soliditylang.org/en/v0.8.14/style-guide.html)

4. 関数と変数の可視性が明示的に宣言されていることを確認する

5. 関数の戻り値が明示的に割り当てられていることを確認する

6.関数関数とパラメーターのコメントが完全であることを確認します

7. transfer、transferFrom、send、call、delegatecall などの外部呼び出しの戻り値が正しくチェックされていることを確認します。

8. インターフェイスのパラメーターの型と戻り値の実装が正しいことを確認します。

9. コントラクトの主要なパラメータが認証され、イベントを使用して記録されていることを確認する

10. アップグレード可能なモデルの新しい実装契約のデータ構造が、古い実装契約のデータ構造と互換性があることを確認する

11. コード内の算術演算に関連するロジックが精度の問題を完全に考慮していることを確認し、除算と乗算による精度の低下を回避します。

12. call などの低レベル呼び出しのターゲットアドレスと機能が想定されていることを確認します。

13.通話やその他の低レベルの通話を使用する場合は、ビジネスのニーズに応じてGasを制限します

14. コーディング標準には制約があります。最初に判断し、次に変数を書き込み、次に外部呼び出しを行います (チェック-効果-相互作用)。

15. デフレ/インフレトークン、ERC-777、ERC-677、ERC-721、およびその他のリエントラントトークンなど、ビジネスで相互作用する外部コントラクトが相互に互換性があることを確認します。リエントラントな脆弱性のケースを参照してください。

(https://medium.com/amber-group/preventing-re-entrancy-attacks-lessons-from-history-c2d96480fac3)

16. 外部呼び出しが再入可能性のリスクを十分に考慮していることを確認してください

17. コントラクトストレージ変数の割り当て/読み取りに多くのループを使用しない

18. 権限が過度に集中する問題、特に契約の主要なパラメーターを変更する権限、権限の分離、および管理のためのガバナンス、タイムロック契約またはマルチサイン契約の使用を可能な限り回避するよう努めます。

19. 契約の継承関係は線形継承を維持し、継承された契約のビジネスニーズを確実にする必要があります。

20.チェーン上のブロックデータを乱数のシードソースとして使用しない

21. 乱数の取得と使用は、ロールバック攻撃の可能性を十分に考慮してください

22. Chainlink VRF を使用して、信頼できる乱数を取得してみてください。参照: Chainlink VRF

(https://docs.chain.link/vrf/v2/はじめに)

23. サードパーティ契約のトークン数を使用して LP トークンの価格を直接計算することは避けてください。参照: LP の価格を正しく取得する方法

(https://blog.alphaventuredao.io/fair-lp-token-pricing/)

24. 第三者契約を通じて価格を取得する場合は、単一の価格ソースを避け、少なくとも 3 つの価格ソースを使用することをお勧めします

25. イベントを使用して、プロジェクト実行中のデータ分析のために、主要なビジネスプロセスの実行状況を可能な限り記録します。

26.ブラックスワンイベントが発生したときの時間の損失を止めるために、グローバルおよびコアビジネスの緊急停止のためにスイッチを予約します

テストケースコードの要件

1. ビジネスプロセス/機能の機能ユーザビリティテストを必ず含める

2. 単体テストのカバー率が 95% を超えていることを確認し、コアコードのカバー率が 100% に達する必要があります。

基本的なセキュリティ構成要件

1. 公式メールボックスが Gmail などのよく知られたサービスプロバイダーを使用していることを確認します。

2. 公式のメールアカウントが強制的に MFA 機能を有効にしていることを確認します。

3. GoDaddy などの評判の良いドメイン名プロバイダーを使用してください。

4. ドメインネームサービスプロバイダープラットフォームのアカウントで MFA セキュリティ構成が有効になっていることを確認します。

5.Akamai、Cloudflareなどの優れたCDNサービスプロバイダーを使用してください

6. DNS 構成で DNSSec が有効になっていることを確認し、ドメインネームサービス管理プラットフォームの管理アカウントに強力なパスワードを設定し、MFA 認証を有効にします。

7. すべての従業員が、Kaspersky、AVG などの携帯電話やコンピューター機器でウイルス対策ソフトウェアを使用していることを確認します。

Web フロントエンドのセキュリティ構成要件

1. サイト全体のHTTP通信がHTTPSを採用していることを確認する

2. DNS ハイジャック、BGP ハイジャックなどの中間者攻撃を防止するように HSTS が構成されていることを確認します。参照: HSTS 構成の概要

(https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security)

3. X-FRAME-OPTIONS がクリックジャッキング攻撃を防ぐように設定されていることを確認します。以下を参照してください: X-FRAME-OPTIONS 設定の紹介

(https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options)

4. X-Content-Type-Options がブラウザーのスニッフィング動作によって引き起こされるリスクに対処するように構成されていることを確認してください。

(https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options)

5. XSS 攻撃を防止するように CSP ポリシーが構成されていることを確認します。以下を参照してください: CSP コンテンツセキュリティポリシーの概要

(https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)

6. アクセス許可とユーザー資格情報に関連する Cookie が HttpOnly、Secure、Expires、SameSite フラグで構成されていることを確認します。参照: Cookie 構成の概要

(https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies)

7. 相互に影響するサブドメインの XSS 問題を回避するために、異なるビジネスのサブドメインが厳密に分離されていることを確認します。

8. サードパーティがハッキングされてプロジェクトサイトが影響を受けるのを防ぐために、整合性属性を使用して、参照されているサードパーティリソースが制限されていることを確認します。

(https://developer.mozilla.org/zh-CN/docs/Web/Security/Subresource_Integrity)

9. CORS が正しく構成されていることを確認し、指定された元のドメイン、プロトコル、およびポートのみがプロジェクトのリソースへのアクセスを許可されていることを確認します。

(https://developer.mozilla.org/zh-CN/docs/Web/HTTP/CORS)

10. ビジネスに実装された addEventListener/postMessage にチェックメッセージのオリジンとターゲットがあることを確認します。次を参照してください: postMessage セキュリティの概要

(https://developer.mozilla.org/zh-CN/docs/Web/API/Window/postMessage)

バックエンド環境のセキュリティ構成要件

1. AWS、Google Cloud などの優れたクラウドサーバープロバイダーを選択してください。

2. プロジェクトで使用されるクラウドプラットフォーム管理アカウントが強力なパスワードを使用し、MFA 認証を有効にしていることを確認します。

3. プロジェクトコードがサーバーにデプロイされる前に、サーバーがセキュリティで保護されていることを確認します。たとえば、HIDS をインストールする、SSH キーを使用してログインする、SSH ログインアラートを設定する、SSH ログイン google-auth を設定するなどです。

4. APM、Zabbix などの専門的なソフトウェアを使用して、サービス、サーバーの可用性を監視してください。

5. SlowMist、Trail of Bits などの専門機関を使用して、プロジェクトのセキュリティを定期的にテストしてください。

0x03 解放プロセス

完全なセキュリティリリースプロセスが必要です。これは、次の内容を参照して調整できます。

コード凍結要件

ローンチ予定時刻は 2 日遅れます。つまり、コードを凍結する必要があり、コードの変更はローンチの 2 日前には行われません。

単体テストの要件

1. 単体テストのカバー率が 95% を超え、コアコードのカバー率が 100% であることを確認します。

2.ユニットテストカバレッジレポートを必ず出力する

回帰テストの要件

本番稼働の 1 日前に単体テストと回帰テストを実行する

テストレポートの要件

ローンチの 0.5 日前に、開発とテストを組み合わせてテストレポートを完成させます.失敗した場合 (単体テストとリグレッションテストを含む)、ローンチ時間を延期します.開発が完了し、修正された後、再コード凍結段階に入る (つまり、少なくとも 2 日間延期される)

セキュリティ監査要件

1. セキュリティ監査者は、コードが凍結された後、全体的なセキュリティ回帰を入力します. 抜け穴またはセキュリティリスク (重大、高リスク、および中リスク) が見つかった場合、オンライン時間は延期されます.)

2. セキュリティ監査では、独立した監査を実施するために少なくとも 3 つのチームが必要であり、1 つの内部チーム + 2 つの外部チームを使用できます

0x04 動作中

ランタイムセキュリティの監視

可能な限り、主要なビジネスプロセスでトリガーされるイベントを通じて、プロジェクトの実行時に次のようなセキュリティの問題を発見します。

1. 契約の主要権限/パラメーターの変更: 管理役割の変更のイベント、管理役割が契約の主要パラメーターを変更するイベントを監視し、秘密鍵が盗まれる可能性のある状況をタイムリーに発見します。

2. 契約資金の変化: 価格の変化と契約資金の変化を監視し、潜在的なライトニングローンやその他の攻撃をタイムリーに検出します。

3. 定期的な調整: チェーン上のイベントとトランザクションを定期的に調整して、ビジネスロジックの問題の可能性を適時に検出します。

動作環境のセキュリティ強化

1. フロントエンドコードが存在するサーバーにセキュリティ強化を実装してください。たとえば、HIDS (https://www.aliyun.com/product/aegis) をインストールし、SSH キーを使用してログインし、SSH ログインを設定します。アラート (https://medium.com /@alessandrocuda/ssh-login-alerts-with-sendmail-and-pam-3ef53aca1381)、SSH ログイン google-auth を設定 (https://goteleport.com/blog/ssh- 2fa-tutorial/)など

2. DNS 構成で DNS Sec が有効になっていることを確認し、ドメイン名サービス管理プラットフォームで管理アカウントに強力なパスワードを設定し、2 要素認証を有効にします。

3. プロジェクトで使用されるクラウドプラットフォーム管理アカウントが強力なパスワードを使用し、2 つの認証を有効にしていることを確認します。

バグ報奨金プログラムのリリース

バグ報奨金プログラムを公開するか、有名なバグ報奨金プラットフォームに参加して、プロジェクトをエスコートするコミュニティホワイトハットを引き付けます。BugRap (https://bugrap.io/)、code4rena (https://code4rena.com/) を選択できます。、免疫フィ（https://immunefi.com/）

公称緊急対応チームの編成

名目上の緊急チームを設立し、外の世界に連絡先情報を提供します. 緊急チームは、ホワイトハットによって発見された問題に対処するか、ブラックスワン事件が発生したときにチームメンバーを緊急に対処するように導く責任があります.

0x05 応急処置

緊急対応プロセスの完了

可能な限り完全な緊急対応プロセスを開発し、緊急対応プロセスに従って秩序ある方法でブラックスワンイベントに対処します。

ストップロス処分要件

1.問題の範囲と被害の程度に応じて、緊急停止スイッチを介してタイムリーに損失を停止します

2.ユーザーがプロジェクトとやり取りを続けることによる損失を避けるために、コミュニティメンバーにブラックスワンイベントを通知します

ハッカーの追跡要件

1. ハッカーの営利目的アドレスを迅速に分析し、PC/Web/サーバーのアクセスログを保存（トロイの木馬が存在する場合は、トロイの木馬ファイルを保管してください）

2. サーバーのスナップショットを取り、ハッキングされたサイトを時間内に保つ

3. MistTrack 追跡分析プラットフォーム (https://misttrack.io/)、Chainalysis (https://www.chainalysis.com/) などの専門のセキュリティチームに連絡して、追跡を支援してもらいます。

問題の修正リクエスト

1. 専門のセキュリティチームと問題の最適な修正方法について話し合う

2.修正を正しく実装し、専門のセキュリティチームに検証してもらいます

セキュリティリリース要件

リリースプロセス要件を実行して、すべてのコード変更がテストされ、セキュリティが監査されていることを確認します

分析要件の確認

1. 事後分析レポートを公開し、修正と改善策をコミュニティメンバーと同期する

2. 検死レポートは、問題の本質的な原因、問題の範囲、特定の損失、問題の修復、ハッカーの追跡、およびその他の関連する進捗状況を同期させる必要があります。

要約する

セキュリティは動的な管理プロセスであり、サードパーティのセキュリティチームによる短期的な監査だけに頼っていては、プロジェクトの長期的な安全で安定した運用を真に保証することはできません。したがって、Web3 プロジェクトのセキュリティシステムを確立し、改善することは非常に重要であり、プロジェクトチームが一定のセキュリティ能力を備えている場合にのみ、Web3 プロジェクトの安全で安定した運用をより確実に保証することができます。

さらに、プロジェクトチームがセキュリティコミュニティに積極的に参加し、最新のセキュリティ攻撃と防御の技術と経験を学び、他のプロジェクトチームやセキュリティ専門家とコミュニケーションを取り、協力し、エコシステム全体のセキュリティを共同で改善することをお勧めします。同時に、社内の安全教育や知識の普及を強化し、全従業員の安全意識と能力を向上させることも、安全体制の確立と向上にとって重要なステップです。

最後に、Web3 プロジェクトのセキュリティプラクティス要件は、現在 v0.1 バージョンに属しており、まだ改善中です. より良い提案がある場合は、フィードバックを送信してください.