CertiK：ブロックチェーンエクスプローラーはどのようにしてDoS攻撃から防御するのか？
TechFlow厳選深潮セレクト
CertiK：ブロックチェーンエクスプローラーはどのようにしてDoS攻撃から防御するのか？
要約情報を入力してください。ブロックチェーンエクスプローラーは、ブロックチェーンの検索エンジンであり、ユーザーはこのツールを使用してブロックチェーン上の特定の情報を検索できます。
Web3業界の深掘り報道に専念し潮流を洞察ブラウザといえば、皆さんの頭に浮かぶのは「百度一下、你就知道」「上网从搜狗开始」といった、誰もが知っている、おじいさんでも口にするような有名なブラウザでしょう。
こうした広く知られたブラウザはインターネットの顔であり、まさにインターネットへの入り口です。
しかし、現代においてインターネットと肩を組んで歩んでいる技術といえば、間違いなく注目を集めるブロックチェーン技術でしょう。
インターネットが生活を変え、ブロックチェーン技術はインターネットそのものを変えるのです。そして言うまでもなく、インターネットの入口であるブラウザもまた、ブロックチェーン技術と切り離せない関係にあるのです。こうして生まれたのが「ブロックチェーンブラウザ」であり、これは今や誰もが知る定番の実用製品として、ブロックチェーンユーザーに大きな利便性を提供しています。
ブロックチェーンブラウザの安全性とは
ブロックチェーンブラウザはブロックチェーンの検索エンジンであり、ユーザーはこのツールを使ってブロックチェーン上の特定情報を検索できます。
例として、Etherscanはイーサリアムのブロックチェーンブラウザです。これを使えば、イーサリアム上のブロック、アドレス、トランザクション、その他の活動情報を簡単に取得できます。つまりブロックチェーンブラウザは、ブロックチェーン公式の情報照会サイトのようなものだと言えるでしょう。
では、現在多くのブロックチェーンアプリケーションがセキュリティ脅威に直面している状況下で、ブロックチェーンブラウザ自体の安全性はどうなのでしょうか？
ブロックチェーンブラウザアプリケーションの攻撃対象箇所は比較的少ないです。理由は以下の通りです。
認証・認可を必要としないため、個人情報を漏らすリスクがない；
VueやReactといったWebフレームワークの普及により、XSS（クロスサイトスクリプティング）の発生可能性が低下している；
これにより、ブロックチェーンブラウザは攻撃を受けないということでしょうか？
それとも、攻撃されても問題ないのでしょうか？
答えは：No
ブロックチェーンブラウザにおける攻撃タイプの分類
まず、ブロックチェーンブラウザがどのような攻撃を受ける可能性があるのかを見てみましょう。
ブロックチェーンブラウザのほとんどの機能は、バックエンドデータベースからのデータ検索、またはブロックチェーンノードからの直接照会に関わっています。検索機能について考えるとき、一般に想定される脆弱性は次の2つです：
SQLインジェクション；
DoS（Denial-of-service、サービス拒否攻撃）；
しかし、CertiKの技術チームが複数のブラウザを調査した結果、SQLインジェクションの事例はわずか1件のみ見つかり、一方で50%以上のブロックチェーンブラウザがDoS攻撃の危険にさらされていることが判明しました。
DoS攻撃とは何か
わかりやすい例を挙げます。ある白ひげのおじいさんは、ピエロ風のオヤジが経営するチキン屋がどんどん繁盛しているのを見て、腹を立ててチンピラたちを送り込みました。彼らは注文カウンターに陣取り、「他に何がありますか？」「値段は？」「どうやって作ってるの？」などと延々と質問を繰り返し、店員は混乱して2時間経っても注文が決まりません。空腹の客は待てずに次々と帰ってしまい、店は大打撃を受けます。さらに、もしこの店のスタッフが元々気性が荒ければ、外部の圧力で一触即発となり、店内は大乱闘…。
DoS：Denial of Serviceの略で、日本語では「サービス拒否」。この攻撃行為をDoS攻撃と呼び、合法的なユーザーに対するサービス提供を妨害することを目的とします。
サーバーの世界では、クライアントがHTTPリクエストを送信するのは簡単ですが、サーバー側はその処理と応答に大量のリソースを消費することがあります。アプリケーション層のDoS攻撃は、まさにこの性質を利用して行われます。
一般的には、DoSの攻防はどちらがより多くのリソースを持っているかの勝負になります。しかし、バックエンドコードにバグがあれば、たった1つのリクエストでサーバーがクラッシュすることもあります。
本稿では、DoS攻撃の実例、影響、およびアプリケーションを守るための対策についてご紹介します。
DoS攻撃の事例分析
サーバーに対するDoS攻撃の手法は多様です。一般的に攻撃者は以下のいずれかを狙います：
CPUおよびメモリリソースをすべて使い果たす；
すべてのネットワーク接続を占有する；
以下に、DoS攻撃可能なサーバーの事例を紹介します。一部はコード実装の誤りによるもの、他は設定ミスによるものです。
1. リソースアクセスAPIに数量制限がない
https://fake.sample.com/api/v1/blocks?limit=10
上記のリクエストは、「limit」パラメータで指定された数だけブロック情報を取得します。「limit」が10の場合、最新の10ブロックの情報を返します。小さな数値であれば正常に動作します。
しかし、バックエンド側で「limit」パラメータに上限が設けられていない場合があります。CertiKの技術チームが「limit」を9999999に設定してリクエストを送信すると、長時間処理後に「504 gateway time-out」エラーが返されました。このリクエスト処理中、他のAPIの応答速度も著しく低下しました。
なお、9999999は当該チェーンのブロック総数を超えています。
推測では、バックエンドがブロックチェーン内のすべてのブロックデータを取得しようとしている可能性があります。攻撃者が多数の高「limit」パラメータを持つリクエストを送れば、サーバーは通常のリクエストに応答できず、あるいは完全にクラッシュする恐れがあります。
2. 入子構造のGraphQLクエリ
調査中に、CertiKの技術チームはいくつかのGraphQLを使用するブロックチェーンリソースに遭遇しました。GraphQLはAPI用のクエリ言語であり、従来のREST APIのように複数回のリクエストを行うのではなく、一度のリクエストで必要なすべてのデータを取得できます。GraphQLの利用率は高いですが、適切な保護策を講じなければセキュリティリスクが生じます。
ブロックチェーンブラウザのテスト中に、CertiKの技術チームは、あるブラウザがGraphQLインターフェースを使用しており、2つの型が相互に包含する関係にあることを発見しました。これにより、ユーザーが非常に複雑な入子クエリを構築できるようになります。
このような入子クエリを送信すると、サーバーのCPU使用率が急激に上昇する可能性があります。通常、数個のこうしたリクエストでCPU使用率が100％を超えて、サーバーが通常ユーザーのリクエストに応答できなくなることがあります。
このようなGraphQLリクエスト処理時のCPU使用率
下図の「dos_query」は、入子構造のGraphQLクエリの例を示しています。
悪意のあるGraphQLリクエストがサーバーに与える影響は、クエリの複雑さとサーバーの性能に依存します。時間がかかるものの最終的に応答できる場合もあれば、CPU使用率の急上昇によりサーバーがクラッシュする場合もあります。GraphQLのセキュリティについて詳しく知りたい方は、本文末尾の参考リンク1をご覧ください。
3. 直接公開されたCosmos RPC API
https://fake.cosmos.api.com/txs?message.action=send&limit=100&tx.minheight=1
上記のCosmos APIは、ブロック1から100件の送金取引を検索します。現時点でのCosmosメインネットのブロック数は2,712,445に達しています。CosmosHubでRPC APIノードが公開されている場合、上記リクエストを処理できるノードは見つかりませんでした。リクエストを受けたサーバーはしばらくして「502 Bad Gateway」エラーを返し、リクエスト失敗を示しました。
RPCサーバーが数秒以内に数百件の同様の検索リクエストを受け取ると、すべてのAPIリクエストに対して以下のようなエラーを返します。一部のノードは自動復旧可能ですが、他は再起動が必要です。
読者の方々に上記の問題をより理解していただくため、CertiKの技術チームは完全同期済みのCosmosフルノードを構築し、「https://fake.cosmos.api.com/txs?message.action=send&limit = 100＆tx.minheight = 1」というクエリで攻撃をシミュレーションしました。
Grafana CPU使用率パネル
このグラフは3つの段階に分けられます：
ノードが起動し正常稼働中。システムのCPU使用率は35％
ノードがDoS攻撃を受け、CPU使用率が97％に達する
ノードがクラッシュし、Grafanaへの新規データ送信ができなくなる
このグラフは、DoS攻撃によってサーバーが数分以内にクラッシュしたことを示しています。サーバーがダウンした後はSSH接続も不可能になり、管理者は再起動を余儀なくされました。
4. 不備のあるリクエストハンドラ
https://fake.sample.com/api/v1?feature=Always_time_out
CertiKの技術チームは、ずっと読み込み続けた後タイムアウトになるAPIに遭遇しましたが、複数のリクエストを送っても他のAPIの応答時間に影響はありませんでした。当初の推測では、この特定のAPI処理はCPUやメモリをほとんど使わないと思われます。ただし、このブロックチェーンブラウザはオープンソースではないため、APIコードの実装情報は得られず、名前からもその用途を特定できません。
このAPIを攻撃してもサーバーをクラッシュさせるのは難しいかもしれませんが、攻撃者は「常に停止しタイムアウトする」リクエストを送ることで、すべてのネットワーク接続を占有し、他のユーザーがAPIにアクセスできないようにできます。
例えば、「sleep_to_handle_request」関数は、CPUやメモリをほとんど使わず、長い時間ロードし続けることでネットワーク接続を占有する状況を模擬しています。
他の3つのケース（サーバー完全クラッシュまたは長時間の復旧）と比べ、このケースのサーバーは攻撃終了後すぐに復旧しました。
DoS攻撃の影響
DoS攻撃を受けた脆弱なサーバーは、通常のユーザー要求に応答できなくなります。攻撃が停止すれば、一部のサーバーはすぐにまたは一定時間後に復旧しますが、他は完全にクラッシュして再起動が必要になります。
ブロックチェーンブラウザが利用できないことはユーザーにとって大きな不便です。ユーザーはチェーン上の活動情報を簡単に取得できなくなるだけでなく、Cosmos系チェーンでは、ノードがDoS攻撃を受けると、接続されたブラウザがデータを取得できなくなるだけでなく、APIを通じてトークン送信やバリデーターへのステーキング操作もできなくなります。
提言
どんなアプリケーションもDoS攻撃の脅威にさらされています。完璧に防御できる万能の解決策は存在しません。しかし、攻撃コストを高めることで、潜在的な攻撃者を抑止し、ブロックチェーンブラウザアプリケーションの脆弱性を減らすことは可能です。
ここに、CertiKの技術チームがまとめた、アプリケーションの攻撃リスクを最小限に抑えるための提言を示します。
1. レート制限
バックエンドAPIの実装が安全であっても、大量のリクエストを送ることで攻撃される可能性があります。そのため、いかなる場合でもAPIにはレート制限を設け、悪意のあるIPを一時的または永続的に遮断すべきです。
レート制限は完全な解決策ではありませんが、導入が比較的簡単であり、DoS攻撃に対する第一線の防御手段となります。
2. 設計と実装の改善
優れた設計とコード実装は、同じハードウェア条件下でもより高いパフォーマンスを発揮します。特にデータベース検索やデータ処理機能ではその効果が顕著です。しかし、パフォーマンス以前に、まずコードにバグがないことを確認しなければなりません。
したがって、APIを本番環境に展開する前に、単体テストに時間をかけることは非常に重要であり、期待通りに動作することを保証します。
3. 入力検証とパラメータ制限
ユーザーが提供する変数を検証・制限しない場合、攻撃者はAPIを悪用できます。
コードが期待通りに動作することを確認した後は、不正な入力によってAPIが悪用されないよう対策を講じるべきです。例えば、9999999個のブロックデータを取得したり、1000階層のGraphQLクエリを処理するようなリクエストは許可すべきではありません。
したがって、すべてのユーザー入力は信頼できないものと見なし、サーバーは処理前に検証を行うべきです。
前述の事例では、GraphQL APIは最大深さを制限することで循環クエリによるDoS攻撃を防ぎ、ブロックデータ取得APIは最大ブロック数を50程度の妥当な値に制限できます。
開発者はコード実装と設計に基づき、自アプリに最適な入力検証・制限方法を確立すべきです。
4. ノードRPCを公開しない
すべてのAPIコードの実装が開発者の管理下にあるわけではありません。
例えば、Cosmos RPC APIのコードを改変することは推奨されていません。Cosmos SDKの一部の検索クエリのパフォーマンスは高くありません。どうすればよいでしょうか？
一つの解決策：Cosmos RPC APIの外側にラッパーAPIを設け、ノードからブロックチェーンデータを同期するデータベースを作成します。外部のラッパーAPIが一般公開され、ユーザーのリクエストを受けて処理し、その後Cosmos RPCまたはバックエンドデータベースにリクエストを渡します。これにより、ユーザーが直接ノードのRPC APIとやり取りするのを防げます。データベースはノードが検索クエリで overwhelmed されるのを防ぎ、開発者は自由にデータベースを最適化できます。
Cosmosフォーラムでは、ユーザー「kwunyeung」も別の提案をしています：NginxやCaddyなどのHTTPプロキシを使ってRPCポートを保護する。いずれにせよ共通する主張は、RPCポートは一般公開せず、保護措置を講じるべきだということです。
5. 提言されるハードウェア要件を満たす
上記のすべての防御策を導入しても、APIサーバーやTendermint（参考リンク2参照）のような安定ノードの最低ハードウェア要件を満たしているか注意が必要です。普通のユーザーのアクセスリクエストに対処するだけでサーバーが苦戦しているなら、管理者はハードウェアのアップグレードを検討すべきです。
まとめ
DoS攻撃により、ブロックチェーンブラウザのようなアプリケーションがクラッシュする可能性があり、これは多くの企業にとって致命的な脅威です。
CertiKの専門セキュリティチームは、アプリケーションの脆弱性評価、Solidity、RUST、Goなど各種言語のコード監査、イーサリアム、Cosmos、Substrateなどのプラットフォームのセキュリティ維持において、豊富な経験と専門知識を持っています。
ブロックチェーンブラウザ、ウォレット、取引所、スマートコントラクト、さらには基盤となるブロックチェーンプロトコルの実装に至るまで、ブロックチェーン関連業務全般の包括的なセキュリティ監査が必要な場合、CertiKは長年の実戦経験と最先端の形式的検証技術を駆使して、あなたに最も信頼されるセキュリティパートナーとなるでしょう。
付録
以下は、CosmosノードがDOS攻撃に対して脆弱かどうかをテストするサンプルスクリプトです。「url」変数を変更することで異なるアプリケーションをテストできます。
無許可のアプリケーションに対して実行しないでください。
import requestsimport threading import urllib3 urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) #Modify the url url ="https://fake.cosmos.api/txs?message.action=send&limit=100&tx.minheight=1"def dos_thread(): while(1): response = requests.request("GET", url, verify=False) print(response.text.encode('utf8')) if __name__ == "__main__": for i in range(300): t = threading.Thread(target=dos_thread) t.start()
参考リンク：
1. https://www.apollographql.com/blog/securing-your-graphql-api-from-malicious-queries-16130a324a6b/
2. https://github.com/tendermint/tendermint/blob/master/docs/tendermint-core/running-in-production.md#hardware
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
