BNB チェーンは、Web3 の世界で最も人気のあるブロックチェーンの 1 つであり、そのリーズナブルな手数料、高速なトランザクション、豊富なプロジェクト エコシステムにより、多くのユーザーを魅了しています。他のブロックチェーンと同様に、BNB チェーンの開発者は、開発プロセス中にセキュリティの問題を最初に考慮する必要があります。資金の損失はプロトコルとプラットフォームに対するユーザーの信頼を弱め、セキュリティ侵害とハッカー攻撃は開発者が直面する最大のリスクの 1 つであるためです。
この記事では、開発者がリスクを軽減し、BNB チェーン上でより安全なスマート コントラクトを開発できるように、10 の実用的なセキュリティのヒントを提供します。
01
/ 意味 /
リプレイ攻撃は、リプレイ攻撃やリプレイ攻撃とも呼ばれ、ブロックチェーン環境における一般的なタイプの攻撃です。ネットワークセキュリティにおける「リプレイ攻撃」"」は、有効なデータ送信が悪意を持ってまたは不正に繰り返されたり遅延されたりする一種のサイバー攻撃です。
Web3 とスマート コントラクトのコンテキストでは、これは多くの場合、攻撃者が元のユーザーの許可なしにスマート コントラクト内のトランザクションやアクションを繰り返すことができることを意味します。これは、二重支払いなどのさまざまな形の詐欺につながる可能性があります。
これらの攻撃は、攻撃者が同じ署名を再利用してスマート コントラクト上のすべての資金やその他の資産に不正アクセスできるようになるため、ユーザーや開発者に深刻な結果をもたらす可能性があります。
リプレイ攻撃を防ぐには、開発者はスマート コントラクト コードを慎重に設計して実装し、署名検証と業界最高のセキュリティ標準に従う必要があります。
02
／ 事例分析 ／
次のコード スニペットは、BNB チェーン上のトークンの転送実装プロセスを表しています。このコードはリプレイ攻撃に対して脆弱であり、攻撃者が同じ署名を再利用することを可能にします。
この機能にはノンス保護やリプレイ保護がないため、攻撃者が署名された転送を複数回「リプレイ」する可能性があります。攻撃者は署名済みのトランザクションを傍受し、同じコントラクトまたは別のコントラクトに再送信する可能性があり、コントラクトは引き続きトランザクションを有効と見なすため、攻撃者はこの脆弱性を悪用して資産を盗む可能性があります。
03
／ 改善方法 ／
署名にナンスを追加するか、マッピング変数を使用して署名を記録します。その中の具体的な解決策は、プロジェクトの設計によって異なります。
01
/ 意味 /
再入攻撃は、最初の呼び出しが完了する前に、悪意のあるコントラクトが脆弱なコントラクトを繰り返し呼び出すと発生します。言い換えれば、攻撃者は、脆弱なコントラクトを「だまして」、1 つのトランザクションが完了し、自由に次のトランザクションに進むことができると思わせることができますが、実際にはまだ攻撃者の悪意のあるコードが実行されています。
これにより、攻撃者が予期しない方法で契約の状態を操作し、不正な資金を入手できる可能性があります。
02
／ 事例分析 ／
以下のコード スニペットでは、ユーザーは、引き出し関数を呼び出して引き出したい金額を指定することで、自分のアカウントから資金を引き出すことができます。ただし、withdraw 関数は関数への再帰呼び出しを防止しないため、再入攻撃に対して脆弱です。
攻撃者は、残高が実際にアカウントから引き落とされる前に、引き出し関数を複数回呼び出す悪意のあるコントラクトを作成することにより、この脆弱性を悪用する可能性があります。関数 msg.sender.call は悪意のあるコントラクトに資金を送信し、攻撃者は悪意のあるコントラクトの accept() 関数を使用して、残高がゼロになる前に資金を繰り返し引き出し、それによって被害者のコントラクトの資金をすべて使い果たします。
03
／ 改善方法 ／
状態の更新は、外部呼び出しの前に行われます。
このパターンは「Check-Effects-Interact」パターンと呼ばれ、スマートコントラクトにおけるリエントラント攻撃を防ぐために使用される設計パターンです。このパターンでは、最初に前提条件を確認し、次に外部呼び出しを行う前に状態を更新することで、状態の変更を他のコントラクトへの外部呼び出しから分離します。これにより、外部呼び出しによってコントラクトへのコールバックを試みるコールバックがトリガーされたものの、状態がすでに更新されている場合に、他の予期せぬ影響が防止されます。
このパターンに従うことで、開発者はコントラクトの安全性を高め、再入攻撃に対する脆弱性を軽減できます。
もう 1 つの考えられる修正は、OpenZeppelin の ReentrancyGuard と同様に、修飾子を利用して同じ関数への複数の呼び出しを制限することです。
01
/ 意味 /
オラクルは、スマート コントラクトがブロックチェーンの外部から情報を取得するのに役立ちます。通常、分散型取引所 (DEX) 資産の価格は、DEX の最後に成功したトランザクションからオラクル マシンによって抽出された価格によって決定されます。
しかし問題は、価格が誰でも簡単に操作できるため、スマートコントラクトに問題が生じることです。フラッシュローンでは同じブロック内でローンを返済する限り無担保で巨額の資金を借りることができるため、フラッシュローンを通じて価格を操作するケースがよく見られます。これにより、攻撃者は、偽りの清算、過剰な融資、または不公正な取引から利益を得るために、価格に簡単に影響を与えたり、さらには操作したりすることができます。
02
／ 事例分析 ／
以下は、Oracle 操作に対して脆弱なコード スニペットです。
このコントラクトにより、ユーザーはルーティング コントラクトを使用してトークン A をトークン B に交換できますが、価格を計算するためにトークン A とトークン B のリザーブを取得するには外部オラクル (Uniswap ペア コントラクト) に依存します。攻撃者は Uniswap ペア コントラクトの準備金と getAmountOut 関数を操作することができ、最終的にはスワップが不当な価格で実行されるようになりました。
03
／ 改善方法 ／
この攻撃を防ぐには、開発者は、集中型取引所と分散型取引所のオンチェーンで出来高加重平均価格 (VWAP) または時間加重平均価格 (TWAP) をキャプチャする分散型オラクル ネットワークを使用する必要があります。このようにして、データは複数のソースから広範囲にわたって収集されるため、コードが攻撃や操作に対して脆弱になります。開発者にとって、潜在的な脆弱性を防ぐために、スマート コントラクト内のオラクルを操作する攻撃ベクトルを除去できることが重要です。
01
/ 意味 /
機能の可視性を適切に設定することで、スマート コントラクトのセキュリティと整合性が確保されます。誤った機能可視性設定を使用すると、意図しないユーザーが契約状態を操作できるようになり、資金の盗難や契約機能の制御などの重大な問題が発生する可能性があります。
関数の可視性をプライベートまたは内部に設定すると、開発者が特定の関数に限定的にアクセスできるようになり、許可された関係者のみがこれらの関数を呼び出すことができるようになります。プライベート関数はコントラクト自体からのみ呼び出すことができますが、内部関数は現在のコントラクトを継承して呼び出すこともできます。これにより、開発者は機能へのアクセスの制御を維持しながら、より強力で複雑なコントラクトを作成できます。
02
／ 事例分析 ／
setAdmin() 関数を使用すると、誰でも任意のアドレスを契約管理者として設定できます。アドレスを管理するために契約内で付与されている権限によっては、開発者が契約自体の制御を失ったり、資金を失ったりする可能性があります。
一部の内部契約機能では、機能の可視性を内部に設定することで、特定のユーザーを管理者として設定できる場合があります。
03
／ 改善方法 ／
アクセス修飾子は、コントラクト内の特定の関数または変数に誰がアクセスできるかを決定する重要なセキュリティ機能です。これらの修飾子を使用すると、特定の関数や変数の可視性を特定のロールやアドレスに制限し、悪意のある行為者による不正アクセスやコントラクト状態の操作を防ぐことができます。
たとえば、コントラクトには、コントラクト所有者のみが呼び出すことができる関数や、特定のアドレス セットのみがアクセスできる変数が含まれている場合があります。
可視性修飾子を external に変更し、アクセス修飾子をonlyOwner に設定することで、setAdmin 関数へのアクセスを契約所有者のアドレスに制限できます。これにより、悪意のある外部当事者による特定の特権機能の制御が防止されます。
可視性と制限修飾子を適切に使用すると、コントラクトの管理が容易になり、リエントランシー攻撃 (攻撃者が関数を繰り返し呼び出してコントラクトの状態を操作する) やラン・アヘッド攻撃 (攻撃者が保留中のトランザクションを監視し、コントラクトを操作する) などの一般的な攻撃を軽減できます。正当な取引が実行される前の契約状態）。
これらの機能を適切に使用することで、開発者は契約のセキュリティと信頼性を強化し、不正アクセスのリスクを軽減し、コードの全体的な品質と保守性を向上させることができます。
01
/ 意味 /
将来的に契約をアップグレードするかどうかを決定する場合は、最初の契約設計を慎重に検討する必要があります。コントラクトのアップグレード可能性とは、スマート コントラクトがブロックチェーン上にデプロイされた後に変更または更新できるという特性を指します。アップグレード可能には多くの利点 (バグの修正、効率の向上、新機能の追加など) がもたらされますが、いくつかのリスクも生じます。契約のアップグレードにより、新たな脆弱性が導入されたり、契約が複雑になったり、予期せぬ結果を引き起こしたりする可能性があります。
プロキシ管理者はコミュニティの合意なしに契約をアップグレードできるため、契約のアップグレード可能性は信頼性の問題も引き起こします。開発者は、アップグレード可能性の長所と短所を慎重に比較検討し、プロジェクトにアップグレード可能な契約を導入することが本当に必要かどうかを判断する必要があります。場合によっては、後から変更できるかどうかに依存するよりも、最初から不変になるようにコントラクトを設計する方が安全です。
02
／ 改善方法 ／
契約のアップグレードに関しては、従うべき重要な慣行がいくつかあります。何よりもまず、プロキシ ライブラリを変更しないでください。プロキシ コントラクト ライブラリは、特にストレージ管理とアップグレード メカニズムの点で非常に複雑です。小さな間違いでも、プロキシとロジック コントラクトの動作に大きな影響を与える可能性があります。実際、監査中に見つかったプロキシ関連の重大度エラーの多くは、プロキシ ライブラリへの不適切な変更が原因でした。
契約のアップグレード可能性に関するもう 1 つの重要な実践は、基本契約にストレージの「ギャップ」を含めることです。ロジック コントラクトには、新しいロジック実装をデプロイするときに導入される可能性のある新しい変数を考慮して、コントラクト コードにストレージ ギャップを含める必要があります。新しい状態変数を追加した後は、「ギャップ」のサイズを更新することがより重要になります。これにより、将来のアップグレードが問題なくスムーズに実行されるようになります。
最後に、信頼できないコントラクトに対して selfdestruct() を使用したり、delegatecall()/call() を実行したりすることは避けなければなりません。攻撃者はこれらの関数を悪用して、ロジックの実装を破壊したり、カスタム ロジックを実行したりする可能性があります。これを防ぐには、ユーザーの入力を検証することが重要です。コントラクトが信頼できないコントラクトに対して delegatecall()/call() を実行できるようにしないでください。また、複数のコントラクトにわたるストレージ レイアウトの管理が困難になるため、ロジック コントラクトで delegatecall() を使用することはお勧めできません。これらのプラクティスに従うことで、開発者は契約のアップグレードにおけるバグとリスクを最小限に抑えることができます。
01
/ 意味 /
フロントランニングは常に頑固で解決が容易ではない問題であり、ユーザーはトランザクションの送信とブロックチェーン上での確認の間の遅延を利用して利益を得ることができます。この遅延はメモリプールが原因で発生します。
mempool は、ネットワークにブロードキャストされた未確認のトランザクションの一時ストレージ領域です。ネットワーク内のすべてのノードは、誰でも保留中のトランザクションを確認し、潜在的にそれらを傍受してそこから利益を得ることができるようにするメモリプールを維持します。 mempool は、マイナー (または最大) 抽出可能価値 (MEV) として知られるものを作成し、マイナーが利益を最大化するためにトランザクションを再調整する機会も提供します。
02
／ 事例分析 ／
以下は、前倒しになりやすいオークション入札機能の例です。
この機能により、ユーザーはオークションに入札できるようになりますが、フロントランニング攻撃に対して脆弱になる可能性があります。悪意のあるユーザーがブロックチェーンを監視し、別のユーザーが高額な入札を行ったことを確認した場合、悪意のあるユーザーはすぐに高い入札を提出して優先順位が付けられ、最終的にはオークションで落札されるとします。
次のバージョンでは、ユーザーが不明な入札価格を送信すると、これらの入札はマッピングに保存されます。入札金額は入札期間が終了するまで暗号化されます。
03
／ 改善方法 ／
入札期間の終了時に、ユーザーは元の入札額と秘密の値を送信することで入札を公開できます。契約では、入札金額と秘密ハッシュが保存されている秘密入札と一致することを検証し、入札がオークション期間の終了前に提出されたことを保証します。その入札額が現在の最高入札額よりも高い場合、それが新しい最高入札額となります。この機能は、オークション期間が終了するまで入札額をマスクすることで、前線攻撃を軽減します。
フロントランニングと MEV はブロックチェーン コミュニティの大きな懸念事項となっており、これらの問題に対処するためにトランザクションや公正な注文サービス (FSS) などのさまざまなソリューションが提案されています。トランザクションは、ブロックチェーン上でトランザクションが実行されるまで、トランザクションの詳細を他のユーザーから隠すことで、フロントランニングを防ぐことができます。一方、FSS は、安全なオフチェーン トランザクションの順序付けを通じて、フロントランニング トランザクションと MEV の影響を軽減できます。
緊急のセキュリティインシデントに対処するには、明確かつ包括的な対応計画を策定することが重要です。計画は定期的に見直し、更新し、有効性をテストする必要があります。緊急のセキュリティインシデントに関しては、時間が最も重要です。したがって、計画は事前にカスタマイズし、特定、制御、徐放などの詳細な操作手順を含める必要があります。
計画は効果的に実施され、すべての関係者に常に情報が提供される必要があります。同時に、データの損失を防ぐために、データを定期的にバックアップすることも重要です。この計画では、データとシステムを以前の状態に復元するための回復プロセスの概要を説明します。チームメンバーは、全員が自分の役割と責任を確実に理解できるように、プログラムに関する体系的なトレーニングを受ける必要があります。
十分に準備された対応計画によって問題が解決されるわけではありませんが、インシデントの影響を最小限に抑え、ユーザーや関係者との信頼を維持することができます。
定期的なコード監査は、アプリケーションのセキュリティを維持するために重要です。スマートコントラクトのセキュリティを専門とする専門の監査人と協力することは、開発プロセスにおける重要なステップです。監査人はコード内の脆弱性をチェックし、全体的なセキュリティを向上させるための推奨事項を提供します。
セキュリティを向上するには、特定された問題に優先順位を付けて対処し、監査人とのオープンなコミュニケーションを維持することが重要です。
これに加えて、監査人とのコミュニケーションも重要です。監査人は、発見した問題と脆弱性を詳細に説明し、脆弱性を解決する方法に関するガイダンスと実践的な支援を提供できます。専門の監査機関・担当者と連携することで、セキュリティを「次のレベルに引き上げる」。
BNB チェーンの開発者にとって、定期的な監査の実施は、包括的なセキュリティ戦略の不可欠な部分です。コード内の脆弱性を積極的に特定して対処することで、セキュリティ侵害のリスクを最小限に抑えます。
報奨金プログラムの使用は、ホワイト ハッカーのコミュニティにプロジェクトのコードのセキュリティの脆弱性を報告するよう奨励する効果的な方法です。トークンやその他の報酬などのインセンティブを提供することで、どのプロジェクトでも経験豊富な人々がコードをレビューし、発見した潜在的な問題を報告するよう促すことができます。
明確で透明性のあるバグ報奨金プログラムを用意することが重要です。計画には、どのような種類の脆弱性が報奨の対象となることが判明したか、これらの脆弱性の価値を評価する方法などを含める必要があります。同時に、バグ報奨金プログラムに信頼できる第三者を含めることは、プログラムの円滑な実行と報奨金の公平な分配を確実にするのに役立ちます。
同時に、多様な「賞金稼ぎ」の集団が存在することも重要です。ホワイトハッカーごとに専門分野が異なるため、他の人が見逃す可能性のある問題の発見に重点を置くことができます。
最後に、脆弱性が報告されたら、迅速かつ効率的に対処する必要があります。報奨金プログラムは脆弱性を特定するための効果的なツールですが、問題を実際に修正して有意義なものにするかどうかは開発チーム次第です。
Web3 ユーザーに対するセキュリティ教育は、セキュリティ エコシステムを構築する上で重要なステップです。顧客の安全を守ることは、プラットフォームの安全を保つことにつながります。ユーザーは、自分のアカウントと機密情報を保護するためのベスト プラクティスについて教育される必要があります。
最も重要なことの 1 つは、フィッシング詐欺を回避する方法を学ぶことです。
フィッシング詐欺師は、正規の Web サイトまたはサービスを装ってユーザーを騙し、ユーザーに秘密キーまたはパスワードを漏洩させます。 CertiKはユーザーに対して、情報を受信する際にはメールやソースなどで使用されているWebサイトのURLを必ず再確認し、信頼できないWebサイトでは秘密キーやパスワードを入力しないようにアドバイスしている。
もう 1 つの重要な部分は、安全で強力なパスワードを設定することです。 CertiK はここで、アカウントごとに固有の複雑なパスワードを使用し、異なるサービス間でパスワードを再利用しないようにユーザーにアドバイスします。また、パスワード マネージャーまたはその他の安全な保存メカニズムを使用して、パスワードを安全に保存します。
最後に、秘密キーを保護することは非常に重要です。秘密キーはユーザーのパスワードに相当し、いつでも他人がアクセスできないことが保証される必要があります。ユーザーは秘密キーを他人と共有することを控え、安全な場所に保管する必要があります。
要約する
BNB チェーン上でスマート コントラクトと dApp を構築する開発者は、ユーザーの資金と資産を安全に保つために包括的なセキュリティ アプローチを採用する必要があります。セキュリティ侵害に対処する場合は、事後対応ではなく事前対応することがさらに重要です。セキュリティ侵害が発生したときおよび発生する前に計画を立て、関連するすべてのユーザーと関係者に適切なセキュリティ教育を提供します。上記のすべての対策を組み合わせることで、プロジェクトはセキュリティ侵害やハッキング攻撃のリスクを大幅に軽減できます。
