
この記事は、Consensys DiligenceとMSQプロジェクトの共同作業の成果であり、DFinity FoundationとMetaMask Snaps DAOの支援を受けています。

Consensys Diligenceは、Consensys Software Inc.内の監査部門であり、Solidity、Cairo、および各種ZKライブラリにわたる幅広いスペクトルで精緻な監査を実施する卓越した専門知識で知られています。DiligenceチームはMetaMask Snapsの監査およびセキュリティ基準を主導し、ウォレット機能のセキュリティを確保するためにMetaMaskチームと緊密に連携しています。さらに、Diligenceチームはセキュリティツールの開発と、最も厳しい本番環境で検証された最先端の継続的ファジングソリューションの開発を先導しています。
MSQプロジェクトは最近、MetaMask Snapsストアにローンチされました。MSQは、ユーザーがInternet Computerネットワークとやり取りし、ICベースのトークンを管理し、ICベースのdapps内で安全に認証を行い、デジタル商品やサービスの支払いを行えるSnapです。本質的には、MetaMaskと統合されたcrypto walletであり、認証と支払いに特化した機能を持つInternet Computer専用に設計されています。
DiligenceチームとMSQチームは共同で、この記事でカバーすべき5つの重要な領域を特定しました。ドキュメント、ソフトウェア設計、コード、サプライチェーン、および修正です。これらは、MSQチームが開発中に採用したプラクティスのリストと、それらのセキュリティ上の利点を詳しく説明するDiligenceチームのコメントとともに提供されており、MetaMask WalletまたはセキュリティAuditの対象となりうるその他のセキュリティクリティカルなシステム向けのSnapを構築する方にとって有益なリソースとなっています。それでは始めましょう!
ドキュメントは、あなたの頭の中にある概念を他者が見える形に変換するものです。階層化されたドキュメントは、読者を段階的にコンテキストに没入させることで、あなたが意図した通りにこれらの概念を理解させる助けとなります。当然ながら、ドキュメントが整理されているほど、プロジェクトに対してより広い視野を提供でき、他者があなたをより深く理解できるようになります。
ドキュメントの層は、読者が通常アクセスする順序とは逆に定義します。各層はより高いレベルの抽象化を提供します。こうすることで、全体像から始める読者は徐々に詳細へと深く入り込んでいけます。
ソフトウェアに関する究極の情報源はコード自体であり、ドキュメントの基盤となる層として機能します。必要な情報はすべて含まれていますが、その情報を処理するのは困難です。コードが整理されているほど、より高レベルの抽象化をコードから読み取りやすくなります。しかし実際のシステムでは、これらの抽象化はシステムコンポーネントの複雑な相互作用、数週間分の技術的負債、そして場当たり的な解決策の背後に隠れています。
まず、コードを読む人が複雑な部分に惑わされないようにする必要があります。最善の方法は、コードを読む際の認知負荷を軽減することです。いくつかの戦略を以下に示します:
コードをナビゲートしやすくし、IDEでの簡単なトラバーサルを可能にする。
詳細な命名を使用して、コード要素の目的と機能を明確にする。
強く型付けされた言語を採用して、明確なデータ形式を定義する。
MSQ SnapとdappフロントエンドはTypeScriptで開発されており、プレーンなJavaScriptの落とし穴とは対照的に、多くの潜在的なエラーを防いできました。同様に、バックエンドはRustを活用しており、その堅牢な型システムで知られています。また、MSQ Snapはサードパーティアプリが実行できる多数のメソッドをエクスポートしています。ただし、これらのメソッドを識別するために文字列は使用せず、代わりに定数を使用しています。次のような定数オブジェクトを持っています:
コード内では、この定数オブジェクトを適切なメソッドにアクセスするためのガイドとして使用でき、読者はオブジェクト内の識別子からそのメソッドについて多くを理解できます。例えば、SNAP_METHODS.protected.identity.loginというメソッドは、MSQのコンパニオンdappのみが実行でき、ユーザーのログインを可能にします。このアプローチはコードの明確さを高め、メソッド名の変更が複数の箇所で更新されるのではなく一元管理されるため、リファクタリングを簡素化します。
メソッド名をマッチングするために、次のようなブランチを持つ大きなswitch式を使用しています:
ご覧の通り、ここを読んでいて何かを誤解することは非常に難しく、すべてが正確に命名されており、想像の余地がありません。
Diligenceのコメント 時間は重要な要素です。開発者がコードベースを理解するのに数週間かかる一方、セキュリティエンジニアはリスクを特定するのにわずか数日しかないことが多いです。この制約は、コードの認知負荷を軽減することの重要性を浮き彫りにしています。これは開発者の効率とセキュリティの両方に利益をもたらすプラクティスです。
MSQのコードベースから学べることは、説明的な命名と強い型付け(TypeScriptなど)を持つ明確でナビゲートしやすいコードが誤解を減らし、それが脆弱性の一般的な原因となっているということです。
ただし、TypeScriptの型アノテーションはコンパイル時にのみチェックされることを覚えておいてください!ランタイムで処理またはパースされるデータ(RPC、JSONなど)については、追加の型強制、データ形式、および境界チェックが必要です!この目的のために、MSQは静的型推論を持つTypeScriptファーストのスキーマ検証ライブラリであるzodをエレガントに採用しており、チームにもそのアプローチに従うことをお勧めします。
MSQは、適切な量のコメントによってコードの意図を明確にするという絶妙なバランスを見つけました。この明確さは、セキュリティ研究者がコードベースの「赤い糸」とコアコンセプトを素早く把握するのに役立ちます。理解しやすいコードを書くことで、開発者は迅速なセキュリティレビューの効果を大幅に高めます。
コメントはコードの100%をカバーすることではないと考えています。複雑または不十分に書かれた部分に注釈を付けることが重要です。正規表現、暗号化、文字列操作などの領域は、特に明確なコメントから恩恵を受けます。
例えば、MSQには文字列内のMarkdown制御文字をエスケープする関数があります。その本体は1行のコードですが、正規表現マッチングがあるため、コメントでその機能を説明しています:
ワークフローにAIを取り入れることに抵抗がなければ、ChatGPTはこのようなユーティリティ関数に対して優れたコメントを素早く生成するのに役立ちます(ただし、提供される出力を必ず確認してください)。
Diligenceのコメント セキュリティレビュアーとして、私たちは関数のコメントを未知のコードを通るロードマップとして使用します。コードをレビューする時間には限りがあり、コメントが実装と一致しない場合、それは単に混乱を招くだけでなく、危険信号です。
それらはしばしば、関数またはその説明が仕様から逸脱していることを示し、潜在的な脆弱性を示唆します。関数が約束されたチェックをスキップしたり、データを予期せぬ方法で処理したりすることがあり、深刻な結果につながる可能性があります。
したがって、MSQのコードベースと同様に、コメントを簡潔かつ正確に保ってください。インラインコメントは単なるメモではなく、コードを通じてガイドするビーコンであり、不一致は何かが問題である可能性のある手がかりです。
コードとその複雑さが十分に文書化されたら、次のステップはシステムのアーキテクチャを概説することです。これには、コンポーネント間の相互作用、ソフトウェアが採用するプロトコル、アルゴリズム、データ構造の詳細が含まれます。この層は主に、コードではなくテキストや図などの人間が読めるフォーマットを使用します。
MSQのシステムドキュメントには、アーキテクチャの概要と統合ガイドが含まれています。テキストの説明、例、図が豊富なこれらのドキュメントは、異なるシステム部分がどのように相互作用するかを明確にしています。
シーケンス図はコンポーネントの相互作用を視覚化するのに非常に役立ちます。様々なプロジェクトで汎用性が証明された無料ツール、diagrams.net(draw.io)の使用をお勧めします。
Diligenceのコメント 関数を詳述するインラインコメントとは異なり、システムドキュメントはアプリケーション全体の景観を明らかにする俯瞰的な視点を提供します。この視点は、コードレベルでは見えないことが多いコンポーネント間の問題やユーザーフローの脆弱性を発見するために重要です。
セキュリティレビューをCommand & Conquerのゲームのように考えてみてください。ほとんど隠れたマップから始まります。探索するにつれて、システムドキュメントはスカウトユニットのように機能し、完全なアーキテクチャ(パーミッション、Snap-dAppの相互作用、ユーザーインタラクション)を明らかにします。この展開する概要により、レビュアーはゲームユニットの動きを追跡するように、セキュリティをバイパスする可能性のあるパスを見つけるためにユーザーの旅をトレースできます。
さらに、包括的なシステムドキュメントにはセキュリティ関連の注記が含まれ、理想的にはthreat modelingの演習からの出力も含まれるべきです。主要なコンポーネント、相互作用、リスク、アクター、および典型的なユーザーフローの明確な概要を提供します。これにより、レビュアーは優先度の高い領域に集中し、仕様からの逸脱を発見できます。
開発者にとって、優れたシステムドキュメントは単なる書類作業ではなく、攻撃的および防御的な戦略を導く共有マップであり、セキュリティレビューを盲目的な探索から戦略的な作業へと変換します。
この層には、記事、ランディングページ、ブログ投稿、デモビデオなど、様々な素材が含まれます。
この情報は主にビジネス的な内容ですが、「何を?」という質問に答える上で大きな役割を果たします。一方、以前のすべての層は異なる詳細レベルで「どのように?」という質問に答えていました。
新参者はこのような素材を通じてプロジェクトに出会う可能性が最も高いため、この層をできるだけシンプルで視覚的に保つことが良いアイデアです。また、このような素材は通常、ソフトウェアが実際に動作している様子を示す唯一のものです。ユーザーがソフトウェアを使用して状態Aから状態Bに到達する方法を示します。実際に動作しているのを見ることで、人々はソフトウェアの主要なアイデアを理解し、このソフトウェアが内部でどのように機能しているかを推測できるようになります。
例えば、MSQのランディングページのヒーロースクリーンには大きな文字で「USE THE INTERNET COMPUTER WITH METAMASK」と書かれています。この簡単な一文を読んだ後、読者はおそらく「ああ、これはInternet Computerブロックチェーンのトークンを保存できるwallet Snapなんだ。ICの開発エコシステムの技術を使っているだけで、他のブロックチェーン向けの他のSnapsと同じように機能するんだろう」と推測するでしょう。これは100%正確な推測です。
Diligenceのコメント MSQおよび多数の他のブロックチェーンプロジェクトとの経験から、明確で高レベルのドキュメントはユーザーの採用とセキュリティの両方にとって有益なだけでなく、不可欠であることが一貫して示されています。MSQのSnapのレビュー中、私たちは彼らの多層的なドキュメントアプローチに好印象を受けました。開発者からのビデオウォークスルーにより、すぐに状況を把握できました。コード自体を見る前でも、Snapの機能を素早く理解できました。この高レベルの概要は、期待される動作と典型的なユーザーフローに関するコメントを含むユーザーインターフェースを紹介しました。このような視覚的な補助は非常に価値があり、セキュリティ専門家がアプリケーションにエンコードされた意図された「ハッピーパス」をより速く把握し、これらのパスから外れた場所に隠れることが多い脆弱性を探すことができます。これは、Snapとコードのライブウォークスルーと組み合わせることで、通常セキュリティレビューの理想的なスタートとなります。
この部分はおそらくプロジェクトのセキュリティにとって最も重要です。コードはバグから100%安全であり、インフラは何百万ドルもの様々な対策で保護されているかもしれません。しかし、設計に悪意のある行為者が悪用できる根本的な欠陥が含まれていれば、これらの努力はすべて無意味になります。
具体的な例はユースケースによって異なりますが、いくつかの普遍的なヒントを提供します。
MSQの開始時に、私たちのビジョンに合致するコアセキュリティ原則を確立しました:
MSQチームは何も知らない:鍵素材、認証セッションデータ、アカウント詳細を含む、ユーザーの機密情報を一切収集しません。
暗号化素材はSnapから出ない:保護されたユーザーのMetaMaskエントロピーはSnap内でのみ処理され、必要に応じて生成され、使用後すぐに破棄されます。
MSQは決定論的である:ユーザーは追加の知識なしに、ルートシードフレーズを使用して決定論的にすべての資金、アイデンティティ、鍵ペアを回復できます。
MSQはプライバシーファースト:私たちの取り組みは何よりもユーザーのプライバシーを優先します。
これらの原則はMSQの特定のニーズに合わせて調整されています。ただし、MetaMaskチームもSnap開発者向けのセキュリティガイドラインのセットを提供しており、MSQはそれに準拠しています。こちらから参照できます。
例えば、最小権限の原則があります。これは基本的に、SnapがユーザーにリクエストするPermissionが少ないほど、セキュリティが向上するということです。MSQは4つのPermissionのみをリクエストします:
endowment:rpc
snap_dialog
snap_manageState
snap_getEntropy
MSQはトランザクションの署名のみを担当し、ICへの配信はしないため、endowment: network accessは必要ありません。統合するdappが後者を担当します。
あなたのSnapでも同じことをすべきです。MetaMaskのデフォルトガイドラインを取り、特定のルールで拡張し、それに従ってください。
Diligenceのコメント 私たちはクライアントに「セキュリティは追加する機能ではなく、設計の原則です」と伝えています。MSQがプロジェクト開始時にコアセキュリティ原則を確立したことは、私たちが求めているものです。あまりにも多くのプロジェクトがセキュリティを後付けとして扱い、コアアーキテクチャが設定された後に対策を追加します。このレトロフィットアプローチは必然的に、コードレベルの修正では真に解決できない根本的な欠陥を残します。
Consensys Diligenceでは、セキュリティ専門家サービス、ツール、エンドユーザーの権利を提唱しています。これには、ユーザーの鍵素材がwallet信頼境界内で安全に保たれ、この領域の外に意図せず露出しないようにすることが含まれます。また、ユーザーのプライバシーを保護し、理想的にはメタデータやサイドチャネル情報がサードパーティに漏洩するのを防ぐことにも注力しています。さらに、Snapsが機能に必要な最小限のPermissionのみをリクエストするよう推進しています。これが最小権限の原則です。
MSQの積極的な姿勢はこれらの原則と一致しています。最初からセキュリティを優先することで、脆弱性に対して本質的により強固な基盤を構築しています。
これはメタガイドラインのようなものです。オンラインゲームからバンキングシステムまで、あらゆるソフトウェアに実装されるべき原則です。
MSQにおけるこの最も顕著な例は、アイデンティティ管理へのアプローチです。ご存知のように、大多数のウォレットはユーザーにアイデンティティのセット(アドレス、アカウントなど)を提供します。このセットは、ユーザーの同意を得て、任意のdappからアクセスできます。例えば、いくつかのトランザクションに署名するためです。
これはdapps間の統合に非常に役立ちます。なぜなら、任意のdappがユーザーに代わって他のdappsのスマートコントラクトメソッドを呼び出し、互いの機能を拡張できるからです。例えば、crypto決済プラットフォームはUniswapのスマートコントラクトを呼び出して、買い手のトークンを自動的にスワップし、特定の商品やサービスの支払いとして売り手が受け取ることを期待するものに合わせることができます。
しかし、詐欺サイトが人々を騙して悪意のあるトランザクションに署名させ、ウォレットを空にする可能性があるため、セキュリティには有害です。
これとは対照的に、MSQはidentity scoping techniqueを採用しています。各dapp(各異なるURLオリジン)は、他のdappsのユーザーアイデンティティと相互作用する能力なしに、独自のユーザーアイデンティティのセットを持ちます。これは詐欺サイトの問題を解決するだけでなく、dappsがユーザーを追跡し、ユーザーがどのスマートコントラクト(ICではcanisters と呼ばれる)と相互作用しているかを確認できなくなるため、プライバシーにも大きく貢献します。Internet IdentityとWebAuthn仕様に触発されたこの方法は、セキュリティリスクを大幅に軽減します。
例えば、よく知られたdappが侵害された場合、従来のウォレットはすべてのdappsにわたって脆弱になります。対照的に、MSQのidentity scopingは脅威を侵害されたdappに限定し、より広範な被害を防ぎます。
ただし、この方法はユーザーが各dappで異なるアイデンティティを持つため、dapps間の直接統合を制限します。MSQは、ドメイン名の変更などの状況に役立つ、二重同意によるdapps間のアイデンティティ共有を許可するなど、特定のシナリオに対するソリューションを提供しています。
さらに、MSQはdappがアクセスできるデータが関連するアイデンティティに厳密に結びついていることを保証し、ユーザー情報をさらに保護し、異なるアプリケーション間でプライバシーを維持します。
Diligenceのコメント 直接的なdApp統合が制限されるというトレードオフは、思慮深いものです。リスク評価において、私たちはしばしば「セキュリティバジェット」について議論します。完璧なセキュリティは機能性を妨げる可能性があることを認識しています。MSQはこのバジェットを賢く使っています。dApp間の相互作用を制限することで、最も深刻なリスクの1つ(広範なアイデンティティの悪用)を大幅に削減しながら、コアウォレット機能を維持しています。
ドキュメントについて議論したとき、コードについて少し触れました。ここでは、可読性よりもテクニックに関連するコードの他のいくつかの側面を強調したいと思います。
ここでの「健全」とは、コードが予測可能に動作し、予期されるすべての入力と予期しない入力をカバーすることを意味します。例えば、hexを期待しているときにbase64文字列が与えられた場合、Snapはどのように反応すべきでしょうか?または、メソッドが意図しない順序で呼び出された場合、または未定義のRPCメソッドが呼び出された場合は?
これらの不確実性に対処するには:
明確なエラーハンドリング: コードのすべてのブランチとケースが適切にチェックおよび処理されていることを確認します。MSQのSnapでは、TypeScriptの網羅的なチェックをswitch-case文で使用して、予期しないメソッド呼び出しをキャッチします。以下に示します:
このセットアップは、未知のRPCメソッド識別子が使用されるケースをキャプチャします。
入力のサニタイズ: 入力データを期待される型と形式に対して検証することは複雑ですが、セキュリティには不可欠です。これにはTypeScriptでzodライブラリを使用し、TypeScriptの型システムをランタイムチェックに拡張しています。Zodは詳細なスキーマ定義を可能にし、有効なデータのみが処理されることを保証します。
例えば、メソッドSNAP_METHODS.protected.identity.loginはzodスキーマを使用して入力を厳密に検証します:
ここで、ZOriginとZIdentityIdは単なる文字列や数値ではなく、特別に検証されたサブタイプであり、入力が型だけでなくコンテキスト的にも適切であることを保証します。
zodスキーマをできるだけ正確に定義することで、多くの潜在的な問題を先制的に解決できます。Auditorはより厳格な検証をMSQに実施するよう推奨し、実装後にいくつかのセキュリティリスクが特定され修正されました。
Diligenceのコメント 特定の攻撃シナリオに対する推奨事項に基づいてより厳格な検証を実装することで、他のいくつかのセキュリティリスクが明らかになったとクライアントから聞くのは今回が初めてではありません。これは私たちの経験を正確に反映しており、だからこそ私たちは常に攻撃面を減らすための厳格な入力検証を提唱しています。多くのセキュリティレビューで、私たちは入力検証を精査することから始めます。これを強化することで潜在的な問題が露わになることが多く、1つの脆弱性を修正することで別の脆弱性が明らかになるドミノ効果が生じます。これは、プロジェクトが私たちのフィードバックを真剣に受け止め、システムを反復的に強化していることの明確なシグナルです。攻撃面が縮小されると、攻撃者が弱点を悪用することが段階的に難しくなります。
MSQでは、dapp開発者に直感的なライブラリを提供し、Snapとの正確かつ効率的な相互作用を促進することが私たちの義務だと考えています。これにより、MSQだけでなくサードパーティ開発者もクリーンで健全なコードベースを維持できます。
このようなライブラリはいくつかの理由で有益です:
APIの複雑さを簡素化する: SnapのAPIの複雑さをユーザーフレンドリーなAPIに抽象化します。例えば、MSQのクライアントライブラリはデータエンコーディングにCBORを使用し、JSON-RPCの制約を回避し、開発者が手動でデータをエンコード・デコードする手間を省きます。
安全で直接的な相互作用を保証する: 特定のSnap機能はコンパニオンdapp専用です。これを促進するために、postMessageを介したシームレスなフローを保証しながら、リダイレクトとデータ転送プロセスを管理します。この内部処理により、サードパーティ開発者が明確でわかりやすいAPIを通じてSnapと相互作用することが保証されます。
セマンティックな明確さを高める: クリーンなAPIは単なるツール以上のものです。それはコミュニケーション媒体であり、複雑なエンコード/デコードプロセスや追加の操作層の混乱なしに、コードをより読みやすく理解しやすくします。
これらの側面を優先することで、MSQはSnapと統合するdappsの両方が効率的かつ安全に動作できるエコシステムを作成することを目指しています。
Diligenceのコメント ライブラリを通じたサードパーティコード統合へのMSQのアプローチは、セキュリティを維持しながら開発を簡素化するというコミットメントを示しています。コアとして、セキュリティはSnapコンテキストで厳格に実施される必要がありますが、dapp向けのライブラリはSnapとの通信に便利な方法を提供できます。ただし、dapp開発者はdappのコンテキスト内で使用する際に、Snapとの安全な相互作用とデータの安全なエンコーディングを確保する必要があることを常に念頭に置く必要があります。
最近のXZバックドアは、依存関係の中に悪意のあるコードが入り込むことに対して取り組むことがいかに重要かを改めて強調しました。MSQでは依存関係の管理にpnpmを使用していますが、実際にはどのパッケージマネージャーを好むかに違いはありません。MSQでこのような攻撃ベクトルから保護するために行っている2つのことがあります:
pnpm install --save を使用すると、通常はsemver仕様に従ってパッケージの最新バージョンがインストールされ、破壊的でない新しいバージョンへの自動更新が許可されます。これはpackage.jsonのキャレット(^)記号で示され、許容可能なバージョンの範囲を意味します:
"zod": "^3.22.4" // Installs version 3.22.4 or newer up to 4.0.0ただし、悪意のある更新からのリスクを防ぐために、依存関係を特定のバージョンにロックする方が安全です:
package.jsonからキャレット(^)を削除して各依存関係のバージョンを固定します。既存のロックファイルとnode_modulesを削除し、pnpm installを実行して定義されたバージョンに厳密に合わせます。
将来のインストールには--save-exactフラグを使用します(pnpm install --save-exact )。自動更新を避けるためです。
この決定には信頼が関係します。例えば、MSQでは@metamaskと@dfinityの依存関係ネームスペースを安全と見なし、semver範囲内での更新を許可しています。ただし、そうする際には、推移的な依存関係からの潜在的な脆弱性に注意してください。
Diligenceのコメント プロジェクトを正確な依存関係バージョンに移行することで、数え切れないほどの問題が防止されました:
パッチされた脆弱性がサイレント更新によって再導入されるのを防ぎました。
異なるモジュールが異なるライブラリの動作を見る「バージョンスキュー」を防ぎました。
インシデント後の調査において、正確な環境を再現できるため重要でした。次の更新はどれも悪意のある可能性があります。どのネームスペースでも、どのパッケージでも。使用されているパッケージをレビューし、既知の安全なバージョンのみにバインドして偶発的な更新を防ぐことで、サプライチェーン攻撃の攻撃面がさらに縮小されます。特定のベンダーを信頼することは問題ありませんが、新しいバージョンを使用する前に悪意のあるコードが含まれていないことを手動で確認する限りにおいてです。特に多くのプロジェクトで使用されているよく知られたパッケージは悪意のある行為者の主要なターゲットであり、過去が示すように、このようなコアライブラリは高度なサプライチェーン攻撃に陥る可能性があります(XZバックドア攻撃を参照)。
チーム全体の一貫性を確保し、再現可能なビルドを維持するために、ロックファイルをバージョン管理システムにコミットしてください。MSQではpnpm workspacesとturborepoを活用しており、単一のルートロックファイルpnpm-lock.yamlが必要です。ただし、セットアップによっては複数のロックファイルを維持する必要があるかもしれません。環境の一貫性を保証するために、すべてをバージョン管理する必要があります。
Diligenceのコメント
このプラクティスは、単なる開発の利便性として見落とされることがありますが、実際には安全で安定したコードベースを維持するための重要なコンポーネントです。スマートコントラクト、ブロックチェーンコンポーネント、そして現在はMetaMask Snapsの監査を重ねてきた私たちの経験から、再現可能なビルドは単なる「あれば良いもの」ではなく、基本的なセキュリティ要件であることが繰り返し示されています。ロックファイルをコミットすることは、サプライチェーン攻撃の攻撃面を縮小するためのパズルの1ピースです。npm installがもはや宝くじではなくなると、具体的なバージョンとチェックサムがリポジトリに監査証跡を残し、ビルドがより決定論的になり、「私のマシンでは動く」という議論がなくなります。
これはSnapに直接関係するものではありませんが、Audit結果を効率的に対処する方法を理解することは重要です。
Auditorチームが発見事項を報告したらすぐに、修正に取り掛かるべきです。修正のサイズと複雑さは明らかに発見事項によって異なりますが、可能な限り小さくクリーンにするためのアドバイスがあります。症状ではなく原因を修正することです。
例えば、MSQでは、AuditorがMetaMaskの同意メッセージにMarkdown制御文字を注入することが可能であることを発見しました。コードの異なる部分で複数の変更を加えて各同意メッセージを個別に修正する代わりに、@metamask/snaps-sdkのtext()とheading()要素を再定義し、コンテンツをescapeMarkdown()関数に通してからレンダリングするようにしました。これにより、text()とheading()の各呼び出しを個別に修正する代わりに、同意メッセージを含むすべてのファイルのimport式をカスタム要素に置き換えるだけで済み、はるかにクリーンな修正となりました。
効果的な解決は特定の問題を改善するだけでなく、見えない脆弱性に対しても先制的にセキュリティを強化します。
Diligenceのコメント あまりにも多くのプロジェクトが、根本的な脆弱性クラスを考慮せずに個々の問題が現れるたびにパッチを当てるモグラ叩きアプローチを取っているのを見てきました。問題の根本原因に対処し、脆弱性クラスをグローバルに排除することをためらわないことで、MSQはセキュリティを一連のパッチではなく全体的な規律として理解していることを示しています。セキュリティ専門家として、クライアントには修正を急がず、セキュリティの発見をプロジェクトのセキュリティにポジティブな影響を与えるイベントに変えるために十分な時間を取ることをお勧めします。
以上が、MetaMask Snapsのセキュリティ監査を成功裏に乗り越えるための洞察です。これらのガイドラインに従うことで、MSQチームはDiligenceチームから肯定的なレポートを受け取ることができました。MSQの経験を共有することで、セキュリティ監査の準備において、徹底的かつ効果的なプロセスを確保するお役に立てれば幸いです。
Consensys Diligenceは、ブロックチェーンエコシステム全体にわたる幅広いプロジェクトが、プロトコルのローンチ準備を整え、ユーザーを保護するために構築されていることを確認するのを支援してきました。カスタム監査でこれらおよびその他の脆弱性についてSnapをチェックすることを喜んでお手伝いします。お問い合わせいただき、見積もりを取得してください!
AIによる翻訳です。エラーが含まれている可能性があります。常に情報を確認してください。