はじめに：`@bytebase/dbhub` とは？

`@bytebase/dbhub`は、Bytebaseが提供するデータベース管理と連携のためのツールです。主に、複数のデータベースツールやサービス間でのデータ連携や管理を容易にすることを目的としています。今回の脆弱性は、特にそのHTTP transportモード（`--transport http`オプションで起動した場合）において、ブラウザからの不正アクセスを許してしまう危険なものです。

DNS Rebinding攻撃とは？

DNS Rebindingは、Webブラウザの同一生成元ポリシー（Same-Origin Policy）を回避するために使われる攻撃手法です。通常、ブラウザは異なるオリジン（プロトコル、ホスト、ポートの組み合わせ）へのJavaScriptからのアクセスを制限します。しかし、この攻撃はDNSの名前解決の仕組みを悪用します。

攻撃の流れは以下の通りです：

1. ユーザーが悪意のあるウェブサイト（例: `http://attacker.example`）にアクセスします。このサイトは、被害者のローカルネットワーク上のサービス（例: `http://localhost:8080`で稼働するDBHub）をターゲットにします。

2. 攻撃サイトは、`attacker.example`というドメインのIPアドレスを問い合わせるJavaScriptを実行します。最初のDNS解決では、`attacker.example`は攻撃者のサーバーのIPアドレスを返します。

3. その後、DNSのTTL（Time To Live）が切れるのを待って、再度`attacker.example`のIPアドレスを問い合わせます。この時、攻撃者はDNSサーバーの設定を変更し、`attacker.example`が被害者のローカルホスト（例: `127.0.0.1`）のIPアドレスを返すようにします。

4. ブラウザは、`attacker.example`というオリジンからのリクエストとして、実際には被害者のローカルホストで動作しているサービスにアクセスします。これにより、同一生成元ポリシーが回避され、攻撃者はローカルサービスと通信し、その応答をJavaScriptで読み取ることが可能になります。

`@bytebase/dbhub` の脆弱性の詳細 (CVE-2026-61742)

この脆弱性（GHSA-fm8p-53ww-hf6w / CVE-2026-61742）は、`@bytebase/dbhub`のバージョン`0.21.2`のHTTP transportモード (`--transport http`で起動した場合) に存在します。DBHubのHTTPサーバーは、ブラウザからのアクセスを保護するために以下のチェックを行っていました。

リクエストヘッダーの`Origin`フィールドのホスト名と、`Host`フィールドのホスト名が一致するかどうかを検証。一致する場合、`Access-Control-Allow-Origin`ヘッダーに`Origin`の値を反映し、`Access-Control-Allow-Credentials: true`を設定。

この検証は、一見するとCORSの保護のように見えますが、DNS Rebinding攻撃に対しては不十分でした。攻撃が成功すると、`Host`ヘッダーと`Origin`ヘッダーの両方に攻撃者が制御するホスト名が含まれるため、DBHubはこれを正当なリクエストと判断してしまいます。

さらに問題なのは、DBHubの`/mcp`エンドポイントが認証なしでJSON-RPCツールコールを受け付ける点です。これにより、DNS Rebindingによって確立されたブラウザからの接続を通じて、悪意のあるJavaScriptがDBHubの提供するツール（例：`execute_sql`）を呼び出し、SQLクエリの実行（データの読み取り、列挙、設定によっては書き込み）を指示できてしまいます。

フロントエンドエンジニア視点での影響

フロントエンドエンジニアが直接`@bytebase/dbhub`を使用する機会は少ないかもしれませんが、この種の脆弱性は開発環境やCI/CDパイプラインなど、ローカルやプライベートネットワーク内で動作するサービス全般に当てはまる可能性があります。もしDBHubがあなたのマシンや開発環境でHTTP transportモードで稼働していて、悪意のあるウェブサイトを訪問してしまった場合、以下のような影響が考えられます。

1. **データベース操作の実行**: DBHubが接続しているデータベースに対し、SQLクエリが実行される可能性があります。これにより、機密データの読み取り、改ざん、削除が行われる危険性があります。

2. **機密情報の漏洩**: SQLクエリの結果がブラウザのJavaScriptから読み取られ、外部の攻撃者サーバーに送信される可能性があります。

3. **認証不要**: この攻撃は認証トークンやCSRFトークンを必要としません。DBHubがブラウザから到達可能であるだけで攻撃が成立します。

特に、デモ環境や開発環境で不用意にDBHubが起動されている場合、それがインターネットに直接露出していなくても、あなたのブラウザ経由で攻撃を受ける可能性があることに注意が必要です。

開発者が取るべき対策

この種の脆弱性から保護するためには、バックエンドとフロントエンドの両面からの対策が重要です。フロントエンドエンジニアとして、バックエンドチームと協力して以下の点を検討しましょう。

1. **バインディングアドレスの制限**: HTTP transportはデフォルトで`127.0.0.1`などのループバックアドレスにバインドし、`0.0.0.0`や非ループバックホストへのバインドは明示的なオプトインを要求すべきです。

2. **厳格な許可ホスト/オリジンポリシー**: 任意の`Host`や`Origin`を受け入れるのではなく、明示的に許可されたホストやオリジンのリストを設定し、それ以外を拒否するべきです。

3. **認証・認可の導入**: `/mcp`などの機密性の高いエンドポイントには、APIトークンやCSRFトークン、セッション認証などの仕組みを導入し、認証されたユーザーのみがアクセスできるようにすべきです。

4. **ブラウザオリジンリクエストの拒否**: `Host`が設定されたループバックホスト名またはデプロイホスト名ではないブラウザオリジンリクエストを拒否することを検討します。

1. **不審なリンクのクリックに注意**: 普段からフィッシングサイトや信頼できないウェブサイトへのアクセスを避けることが重要です。

2. **開発環境の隔離**: ローカルで重要なサービスを動かす際は、必要に応じてVPNやファイアウォールでアクセスを制限するなど、環境の隔離を検討しましょう。

3. **セキュリティアップデートの適用**: 使用しているパッケージやツールは常に最新の状態に保ち、既知の脆弱性への対策を怠らないようにしましょう。

まとめ

今回の`@bytebase/dbhub`におけるDNS Rebinding脆弱性は、ブラウザセキュリティの複雑さと、サーバーサイドのサービスがブラウザからの攻撃にどう晒されうるかを示す良い例です。フロントエンドエンジニアとしては、直接サーバーサイドのコードを修正することは少なくても、DNS Rebindingのような攻撃がどのように成立し、自身の開発環境やプロジェクトにどのような影響を与えうるかを理解しておくことが重要です。

サーバーとクライアントの境界を越える攻撃は常に進化しており、CORS設定の厳格化、適切な認証機構の導入、そしてセキュリティ意識の向上によって、これらの脅威から私たち自身とユーザーを守りましょう。