はじめに：SSRF（サーバーサイド・リクエスト・フォージェリ）とは？

Webアプリケーションのセキュリティにおいて、近年注目度が高まっているのがSSRF（Server-Side Request Forgery）という脆弱性です。これは、攻撃者がWebアプリケーションのサーバーに対して、意図しないURLへリクエストを強制的に送信させることで、内部ネットワークのリソースや外部システムへの不正アクセスを試みる攻撃です。

一見するとバックエンド寄りの脆弱性に見えるかもしれませんが、フロントエンドエンジニアが開発・運用に携わるツールやCI/CD環境、あるいはAPI設計の段階で、SSRFに繋がるURL検証の甘さが生まれてしまう可能性は十分にあります。今回は、Budibaseというオープンソースのローコード開発プラットフォームで発見されたSSRF脆弱性を通じて、その危険性と対策を考えていきましょう。

BudibaseのSSRF脆弱性 (CVE-2026-45061) の概要

今回焦点を当てるのは、Budibaseのセルフホスト版（バージョン3.34.11以下）に存在する高深刻度なSSRF脆弱性（CVE-2026-45061 / GHSA-xh5j-727m-w6gg）です。この脆弱性は、特にプラグインのURLアップロード機能（<code>/api/plugin</code>）におけるURL検証の不備によって引き起こされます。これにより、最悪の場合、AWSの認証情報や内部データベースの機密情報が漏洩するリスクがあります。

脆弱性の具体的な仕組みと「甘い」URL検証

この脆弱性の核心は、Budibaseが提供されたURLを検証する際の基準の甘さにあります。プラグインをURLからアップロードする際、Budibaseは、単にURLの中に「<code>.tar.gz</code>」という文字列が含まれているかどうかのみをチェックします。このチェックは非常に単純で、URLのどの部分（パス、クエリ文字列、フラグメントなど）に<code>.tar.gz</code>が含まれていても「有効なURL」として判断されてしまいます。

例えば、攻撃者は「<code>http://169.254.169.254/.tar.gz</code>」のようなURLをBudibaseに渡すことができます。このURLは、Amazon Web Services (AWS) のインスタンスメタデータサービス (IMDS) のデフォルトIPアドレスを指しており、末尾に<code>.tar.gz</code>が含まれているため、Budibaseの検証をすり抜けてしまいます。一度検証を通過すると、ホスト名やプロトコル、パスの適切性といった追加のチェックなしに、そのままBudibaseサーバーからリクエストが送信されてしまうのです。

Budibaseにはデフォルトで内部IPアドレス範囲へのアクセスをブロックするブラックリスト機能がありますが、URL検証層の脆弱性がこれをすり抜ける可能性があり、セキュリティ境界として機能しないケースが発生する、と報告されています。

悪用シナリオ：あなたのシステムにも潜む危険

この脆弱性は、プラグインロード機能が有効な全てのBudibaseインスタンス（デフォルトで有効）に影響します。悪用には「Global Builder」という権限が必要ですが、これはセルフホスト環境では開発者によく付与される権限です。

もし、<code>BLACKLIST_IPS</code>バイパス脆弱性など、他の報告されている脆弱性によって内部IPアドレスへのアクセスをブロックするブラックリストが無効になっている場合、攻撃者はこのURL検証の不備と組み合わせることで、極めて危険なSSRF攻撃を実行できます。

具体的には、AWS IMDSのようなクラウド環境のインスタンスメタデータサービスへアクセスし、IAM認証情報などの機密情報を窃取したり、内部のCouchDBやRedisといったデータベースからアプリケーションデータやセッション情報を不正に取得したりする恐れがあります。これは、開発環境やCI/CDパイプラインをクラウド上で運用している日本の多くのフロントエンド開発チームにとっても他人事ではありません。

デフォルトのBudibase設定（ブラックリストが有効な場合）でも、攻撃者が制御する外部サーバーが内部IPアドレスへのリダイレクトを返すように設定されている場合、Budibaseのサーバーがそのリダイレクトを自動的に追跡し、意図せず内部リソースへアクセスしてしまう可能性があります。

フロントエンドエンジニアが理解すべき対策と学び

この脆弱性への対応は緊急度が高いと判断されています。Budibaseユーザーであれば速やかなアップデートと設定の見直しが推奨されます。また、私たちフロントエンドエンジニアも、同様の脆弱性を生み出さないための学びを得るべきです。

単なる文字列チェックではなく、URLを適切にパースし、プロトコル、ホスト名、パスなどを厳密に検証することが不可欠です。フロントエンドでの入力検証はもちろん重要ですが、悪意あるユーザーはクライアントサイドの検証を容易に突破できるため、サーバーサイドでの厳格な検証が必須です。

推奨される対策としては、プロトコルが<code>https:</code>であること、およびパスの末尾が<code>.tar.gz</code>であることを厳密に検証するように修正することです。URLパースライブラリを適切に利用し、期待するフォーマットと異なるURLはすべて拒否するようにしましょう。

サーバー側で外部URLへのリクエストを行う際には、リダイレクトが発生した場合の挙動を慎重に制御する必要があります。外部URLから内部URLへのリダイレクトを自動で追跡しない設定にするか、リダイレクト先のURLも再度ブラックリストやホワイトリストでチェックするメカニズムを導入することが重要です。

プラグインのダウンロード元となるサーバーなど、外部リソースへのアクセスを許可する場合、アクセス可能なドメインを信頼できるものに限定するホワイトリスト形式のオプション（例: <code>PLUGIN_ALLOWED_HOSTS</code>）を導入することで、許可されていない外部からのアクセスリスクをさらに低減できます。

利用しているツールやライブラリ、フレームワークは常に最新の状態に保つことが、包括的なセキュリティ対策として最も基本的かつ重要なことです。脆弱性が修正されたバージョンがリリースされたら、速やかにアップデートを適用しましょう。

まとめ

BudibaseのSSRF脆弱性は、一見単純なURL検証の不備が、AWS認証情報の漏洩や内部DBへの不正アクセスといった重大なリスクにつながることを示しています。フロントエンドエンジニアとしても、入力値の検証はサーバーサイドと連携して厳格に行うべきであること、そして自身が関わるアプリケーションや利用する開発ツールのセキュリティにも常に意識を向けることの重要性を再認識させられます。

安全なシステムを構築するためには、バックエンド・フロントエンドの境界を越えて、常にセキュリティのベストプラクティスを追求していく姿勢が求められます。