Cobo セキュリティチーム:ブロックチェーンセキュリティ取引ガイド
著者:Cobo セキュリティチーム
前言
ビットコイン ETF の承認に伴い、ブロックチェーン市場が再び活気を取り戻し始めました。コイン価格の回復は、業界がかつての繁栄を徐々に取り戻すことを可能にしています。一方で、ハッカーの活動も活発化しています。Cobo セキュリティチームは、ここ1、2ヶ月の間にフィッシング事件の発生頻度が増加していることを観察しました。
最近、Restaking、BTC L2 などの新しいアプリケーションのホットスポットが現れ、オンチェーン取引は Web3 ユーザーの日常生活に欠かせない部分となり、ますます多くのユーザー資金がオンチェーンに移動しています。
取引所などの中央集権的なアプリケーションとは異なり、オンチェーンアプリケーションのアカウントセキュリティはユーザー自身によって保証される必要があります。安全にブロックチェーン取引を行うことは、Web3 のネイティブにとって最も基本的な能力です。多くのインフラストラクチャ(ブラウザプラグインウォレットやブラウザ自体など)はフィッシングに対する一定のリスク警告を提供していますが、ユーザーが安全でない取引によって資産を失う事件は依然として発生しています(例:秘密鍵の漏洩、署名フィッシングなど)。
Cobo セキュリティチームは、オンチェーン取引プロセスにおける一般的なリスクポイントを整理し、取引の安全性に関する実行基準を作成しました。これは、ユーザーが取引中にリスクを回避し、資金の安全を確保し、フィッシング攻撃を防ぐことを目的としています。
紹介を始める前に、Cobo セキュリティチームは安全な取引の核心原則を以下にまとめました:
1、盲目的な署名を拒否し、理解できない取引やメッセージには署名しない;
2、面倒がらずに、繰り返し確認する。
安全な取引の方法
完全な DApp 取引プロセスは、ウォレットのインストール、DApp へのアクセス、ウォレットの接続、メッセージの署名、取引の署名、取引後の処理 など、複数のステップを含みます。それぞれのステップには一定のセキュリティリスクが存在し、以下に実際の操作における注意点を順次紹介します。
注:この記事は主にイーサリアムおよび各 EVM 互換チェーンにおける安全なインタラクションプロセスを紹介しており、他の非 EVM チェーンで使用されるツールや具体的な技術的詳細は異なる場合があります。
ウォレットのインストール
現在、DApp の主流な使用方法はブラウザプラグインウォレットを使用してインタラクションすることです。EVM チェーンで使用される主流のウォレットには Metamask や Rabby などがあります。
Cobo セキュリティチームは、リスク警告の観点から深く体験した結果、主要なオンチェーンインタラクションウォレットとして Rabby プラグインウォレットの使用を推奨しています。その理由は、Metamask ウォレットと比較して、Rabby ウォレットは取引データの解析、取引のシミュレーション実行、取引リスクの警告、承認の確認、履歴署名データの確認などの機能を提供し、フィッシング防止において Metamask ウォレットよりも大きな利点を持つからです。
Chrome プラグインウォレットをインストールする際は、Chrome ウェブストアからダウンロードしてインストールすることを確認し、第三者のウェブサイトからウォレットをインストールしないようにして、バックドアのあるウォレットソフトウェアをインストールしないように注意してください。
条件が整っているユーザーには、ハードウェアウォレットを併用することをお勧めします。これにより、秘密鍵の保管において全体的なセキュリティを大幅に向上させることができます。
DApp へのアクセス
ウェブフィッシングは Web3 攻撃の一般的な手法であり、典型的なケースはエアドロップの名目でユーザーをフィッシング DApp アプリケーションに誘導し、ユーザーがウォレットを接続した後にトークンの承認、送金取引、またはトークン承認の署名を行わせ、ユーザーの資産が損失することです。
したがって、DApp にアクセスする際は、ユーザーは警戒を保ち、ウェブフィッシングの罠に入らないようにする必要があります。
DApp にアクセスする前に、DApp の URL の正確性を確認するべきです。推奨事項:
Google での検索結果の1位から直接アクセスしないようにする。フィッシング攻撃者は広告スペースを購入することで自分のフィッシングサイトを検索結果の上位に表示させることができるため、1位が公式サイトであるとは限りません。
x.com や各種ソーシャルメディアの他のユーザーのコメントやメッセージに掲載された URL を直接クリックしないようにする。このような URL はフィッシングリンクである可能性が高いです。
DApp の URL の正確性を繰り返し確認した後にアクセスする。DefiLlama などの DApp 市場、プロジェクトの公式 X アカウント、Google の検索結果などで複数回確認することができます。
安全なウェブサイトはブラウザのお気に入りに追加し、今後はお気に入りから直接アクセスする。
DApp ウェブページを開いた後も、アドレスバーの安全チェックを行う必要があります:
ドメイン名、URL を確認します。通常、DApp は比較的シンプルなドメイン名と URL を使用します。例えば https://app.uniswap.org/;特に長いドメイン名(例: https://zk-polyhedra.network-8jb.xyz/)や有名なウェブサイト名に似たドメイン名(例: https://pufffer.fi(f が1つ多い))に遭遇した場合、ログインしているフィッシングサイトである可能性が高いため、すぐに退出するべきです。ドメイン名を識別する際には、1il、oO0 などの形が似た文字にも特に注意が必要です。
ブラウザの https リンクの状況を確認します。現在の主流の DApp は https リンクを使用しており、ブラウザは🔒のアイコンを表示するべきです。もし https リンクでない場合やブラウザが証明書の異常を警告する場合、アクセスしているのは公式サイトでないか、ハイジャック攻撃に遭っている可能性があるため、すぐにアクセスを停止するべきです。
現在市場に出回っている主流のブラウザプラグインウォレットは、すでに一定のリスク警告機能を統合しています。例えば Metamask や Phantom などです。ブラックリストに載っているリスクのあるウェブサイトにアクセスする際、ブラウザプラグインウォレットや Chrome ブラウザ自体が強力なセキュリティ警告を表示することがあります(下の画像を参照)。
ウォレットの接続
DApp に入ると、自動的にまたは「Connect」をクリックすることでウォレット接続の操作がトリガーされることがあります。プラグインウォレットは、現在の DApp に対していくつかのチェックや情報表示を行います。
以下は Rabby ウォレットが提供するウェブページの審査情報で、DApp の真偽を判断するのに役立ちます。
ウォレットを接続した後、通常、ユーザーが他の操作を行わない限り、DApp はプラグインウォレットを自動的に呼び出しません。もしウェブサイトがログイン後に DApp を頻繁に呼び出して署名メッセージや取引の署名を要求し、拒否した後も署名を求め続ける場合、それはフィッシングサイトである可能性が高く、慎重に対処する必要があります。
メッセージの署名
極端な場合、攻撃者がプロトコルの公式ウェブサイトを攻撃したり、フロントエンドをハイジャックするなどの攻撃を行い、ページの内容を置き換えた場合、普通のユーザーはこのようなシーンでウェブサイトの安全性を識別することが難しいです。
この時、プラグインウォレットの署名はユーザーが自身の資産を守るための最終的な防壁です。悪意のある署名を拒否することで、自身の資産を守ることができます。ユーザーは、メッセージや取引に署名する際には、署名内容を慎重に確認し、盲目的な署名を拒否すべきです。
技術的には、現在イーサリアムで一般的な署名タイプは3種類あります:
ハッシュ署名 eth_sign :特定のデータの元のハッシュに対して署名します。ハッシュの元データはメッセージやイーサリアム取引である可能性があります。
メッセージ署名 personal_sign :データのプレーンテキストに対して署名します。ユーザーのログイン確認や許可プロトコルの確認時に最も一般的です。
構造化データ署名 eth_signTypedData(EIP-712) :DeFi プロトコルで使用されるデータオブジェクトに対する署名で、ERC20 Permit の承認署名や NFT のリスティング署名などが一般的です。
メッセージ署名のリスク判別に関して、ユーザーは以下の原則に従うことができます:
自然言語の署名は通常許可されます。この種の署名は通常 personal_sign で、ログイン確認や製品の確認に使用されるため、大段の自然言語の記述(数字や16進数などの形式ではなく)を含んでいます。このようなメッセージは自然言語を含むため、文字列が比較的複雑で、スマートコントラクトの処理が難しいため、通常はオンチェーン認証には使用されず、単にウェブサイトがアドレスの身元を確認するために使用されます。したがって、リスクは比較的低いです。
16進数の元のハッシュを直接署名することは禁止します。この種の署名は通常 ethsign 署名であり、最も危険です。なぜなら、ユーザーはハッシュの元のデータ内容が何であるかを判断できないからです。したがって、大部分のウォレットは元のハッシュ(16進数データ)署名機能を無効にしています。Metamask ウォレットでは、設定 -> 高度な設定 -> Ethsign リクエストタブでその設定がオフになっていることを確認できます。Rabby ウォレットでは、関連設定はデフォルトで無効になっており、追加の設定は不要です。
構造化データ署名は署名内容を慎重に確認します。例えば ERC20 Permit の承認署名では、spender アドレスが期待通りであるかを確認します。EOA アドレスであれば、フィッシング署名をクリックした可能性が高いため、すぐに拒否すべきです。
メッセージ署名に関して特に注意すべき点は、ブラウザプラグインウォレット内で ethsign 操作がデフォルトで禁止されているにもかかわらず、ウォレットは personalsign を通じてハッシュタイプのデータに署名することができるということです。この種の署名は permit の承認や取引の開始を引き起こすことはありません。しかし、一部のプロトコル(例えば一部の AA ウォレット)は personal_sign 署名を使用して認証を行う可能性があります。損失を避けるために、原則として16進数データに署名しないことが推奨されます。この種の署名の効果は以下の通りです:
取引の署名
署名取引は盲目的な署名をしない原則に従うべきです。 現在、多くのプラグインウォレットは署名待ちのメッセージをデコードして関連内容を表示します。以下は Rabby ウォレットによる DEX 取引の解析例です:
ユーザーは取引の対象アドレスに関するいくつかの関連情報(EOA アドレスかどうか、アドレスの残高、コントラクトの展開時間など)を確認できます。ユーザーはこれらの情報を基に署名する取引のリスクを判断できます。例えば、インタラクションするアドレスが EOA アドレスである場合や、インタラクションするコントラクトの展開時間が7日未満である場合、その操作は大きなリスクを持つと考えられ、十分に調査した後に操作を行うべきです。
オープンソースプロトコルに対して、主流のブラウザプラグインウォレットは取引データの解析をサポートしており、ABI デコード後の取引内容を確認することで、現在何を操作しているのかをより明確に理解できます。コントラクト呼び出しの関数名は、その機能の参考を提供します:approve、swap、transfer、deposit、withdraw など。
Rabby や imToken ウォレットはシミュレーション実行機能も統合しており、ユーザーは取引確認前に取引実行結果を直接見ることができます。取引のシミュレーション実行を通じて、ユーザーは現在の取引が引き起こすさまざまな資金移動の状況を確認できます。ユーザーは慎重に確認し、期待される実行結果に合わない場合は署名を拒否すべきです。
一定の技術的な知識を持つユーザーは、自動化ツールが取引をうまく解析できない場合、以下の一般的な手動チェック方法を使用することもできます:
インタラクション対象のコントラクトアドレスをブロックチェーンエクスプローラー(例:etherscan)にコピーして審査し、主にコントラクトがオープンソースであるか、最近大量の取引があったか、Etherscan がそのアドレスに公式ラベルや悪意のあるラベルを付けているかを確認します。
プラグインウォレットが取引を認識できない場合、元の取引データ(raw_data、16進数データで表示)から最初の8桁の数字を手動でコピーして https://openchain.xyz/signatures でクエリを行い、元の関数名を取得して取引の行動を大まかに特定します。
Phalcon、Tenderly、Dedaub などの取引シミュレーションツールを使用してシミュレーション実行し、取引の具体的な実行詳細を確認します。
取引後の処理
フィッシングウェブページや悪意のある署名を回避したからといって、すべてがうまくいくわけではありません。取引後もリスク管理を行う必要があります。
取引後は、取引のオンチェーン状況を迅速に確認し、署名時の期待される状態と一致しているかを確認します。異常を発見した場合は、迅速に資産の移転や承認の解除などの損失防止操作を行うべきです。
ERC20 承認管理も非常に重要です。いくつかのケースでは、ユーザーが特定のコントラクトに対してトークンの承認を行った後、数年後にこれらのコントラクトが攻撃を受け、攻撃者が攻撃されたコントラクトのトークン承認額を利用してユーザーの資金を盗むことがありました。
このような状況を避けるために、Cobo セキュリティチームはユーザーに以下の基準に従ってリスク防止を行うことを推奨します:
承認を最小限にする。トークンの承認を行う際は、取引のニーズに応じて相応のトークン数量を制限するべきです。例えば、ある取引で100 USDTの承認が必要な場合、その承認数量は100 USDTに制限し、デフォルトの無制限承認を使用しないようにします。
不要なトークン承認を迅速に撤回する。Rabby ウォレットの承認機能を使用するか、revoke.cash にログインして対応するアドレスの承認状況を確認し、長期間インタラクションがないプロトコルの承認を撤回し、プロトコルに後続の脆弱性が存在することによってユーザーの承認額が利用されて資産損失を引き起こすのを防ぎます。
その他のテクニック
上記の取引プロセスにおけるリスクに加えて、特定のツールに統合された機能を合理的に利用することで、いくつかのリスクを回避することもできます。
一部のウォレットにはウォレットインポート機能(例:Rabby)が内蔵されています。他のモバイルウォレットのアドレスをインポートすることで、取引時に強制的な二重確認(ウォレットを呼び起こし、QRコードをスキャンし、パスワードを入力して確認)を行い、フィッシングリスクを軽減できます。同時に、モバイルウォレットの取引安全チェック(ホワイトリスト、シミュレーション実行、フィッシング警告など)を享受できます。
一部のウォレットはインポート可能なオブザーバーウォレット(例:Rabby、OneKey、TokenPocket、imToken など)をサポートしており、オブザーバーウォレットを通じて不明なウェブサイトにアクセスすることができます。この場合でも、メッセージ署名や取引のページが正常に呼び出されるため、署名待ちの内容を慎重に確認できます。また、秘密鍵がないため、誤操作による確認の心配はありません。
Rabby ウォレットの承認機能を使用してアドレスの承認状況を確認し、高リスクの承認を迅速に撤回します。ヒント:Rabby はこの機能で複数の次元(履歴承認リンクの総額/24時間内の承認キャンセル数/承認時間/承認資産数量)を使用して承認リスクを評価しており、ユーザーが承認リスクを識別するのにより効果的に役立ちます。
誤操作で署名した後、Rabby ウォレットの署名記録機能を使用して、自分が署名した取引やテキストデータを迅速に確認し、承認リスクを排除します。
リスク意識を持ち、十分なリスク防止策を講じた場合でも、効果的な資金隔離を行い、極端な状況下で資金の損失程度を低減する必要があります。Cobo セキュリティチームは、資金の保管に以下の方法を使用することを推奨します:
Gnosis Safe マルチシグウォレットまたはコールドウォレットを使用して大きな資金を保管する;
ブラウザウォレットで生成されたアドレスまたは他の EOA ウォレットを使用して小額資金のユーザーインタラクションを行い、定期的にホットウォレットアドレスを変更する。
もし不注意でフィッシングに遭った場合、損失を減らすために以下の操作を直ちに実行できます:
Revoke.cash で迅速に承認をキャンセルする;
フィッシング permit メッセージに署名し、資金が移動されていない場合は、すぐに新しいメッセージに署名し、permit 呼び出しを行ってフィッシングメッセージの nonce を無効にする;
必要に応じてアカウント資金を移転する。
安全にエアドロップを受け取る方法
エアドロップの配布は、現在プロジェクトがユーザーを引き付けるための一般的な方法であり、同時にユーザーがフィッシング攻撃を受けるリスクが高い地域でもあります。これに基づき、上記の安全取引原則に基づいて、Cobo セキュリティチームはオンチェーンエアドロップを受け取るための安全なインタラクションプロセスを整理しました:
まず Rabby オブザーバーウォレットを使用してインタラクションプロセスをテストし、トークン承認やトークン送金の取引がないことを確認します。
エアドロップを受け取る過程で Permit タイプのメッセージ署名を行わない。Approve コントラクト呼び出しを行わない。
できるだけ「小号」を使用してエアドロップを受け取る。
エアドロップ取引のシミュレーション実行結果を確認し、トークンが転出しないことを確認します。
プラグインツールの選択
ブロックチェーンセキュリティガイドラインの内容は多岐にわたり、毎回のインタラクションで詳細なチェックを行うことが難しい場合があります。そのため、リスク判断を補助するための使いやすいブラウザプラグインは存在するのでしょうか?
Cobo セキュリティチームは、市場で主流の取引リスクチェックプラグインを体験し、「フィッシングウェブサイトのブロック」、「悪意のある承認アドレスのチェック」、「オープンソースかどうか」の3つの次元から整理した表を作成しました。皆さんは自身の状況に応じて使用を選択できます。以下の通りです: