GHSA-hv85-774v-26fgに学ぶ！LLM連携におけるSSRF脆弱性とフロントエンドへの影響
はじめに：なぜフロントエンドエンジニアがSSRFを知るべきか？
LLM（大規模言語モデル）の普及により、フロントエンドからLLMを介してバックエンドのツールを操作する機会が増加しています。一見、フロントエンドとは無関係に見えるサーバーサイドの脆弱性も、フロントエンドからのユーザー入力がトリガーとなることで、深刻な影響を及ぼす可能性があります。特に今回のGHSA-hv85-774v-26fgは、外部からのURL指定がサーバー内部リソースへの不正アクセスを引き起こすSSRF（Server-Side Request Forgery）の典型例であり、システム全体のセキュリティを考える上で非常に重要です。
脆弱性 GHSA-hv85-774v-26fg の概要と危険性
この脆弱性は、サーバーサイドのツール（本件では具体的な名前は示されていませんが、`download_media`や`auth_fetch`といった機能を持つツールを想定）が、外部から受け取ったURLを適切に検証せずに処理してしまうことに起因します。これにより、攻撃者はサーバーが通常アクセスできないはずの内部ネットワークリソースにHTTPリクエストを送信させたり、その応答内容を不正な場所に書き込ませたりすることが可能になります。
この脆弱性の深刻度は「High」と評価されています。特にLLM連携システムにおいて、ユーザーがプロンプトを通じてこれらのツールを呼び出す場合、意図しない形で内部情報が窃取されるリスクが非常に高く、迅速な対応が不可欠です。
具体的な攻撃メカニズムと影響
このツールは、指定されたURLリストからファイルをダウンロードし、ユーザーが指定した出力ディレクトリに保存する機能を持っています。しかし、URLと出力ディレクトリのどちらにも適切な検証が行われていません。これにより、悪意のあるユーザーは「`http://169.254.169.254/latest/meta-data/`」のようなクラウド環境のメタデータサービス（AWS EC2など）や、内部ネットワークのプライベートIPアドレスを指示できます。ダウンロードした内容が指定パスにファイルとして書き込まれるため、サーバー内部の機密情報漏洩や、システム上の任意の場所にファイルを生成されるリスクがあります。
このツールは、ユーザーが指定したURLのWebページにPlaywrightのようなブラウザ自動化ツールを使ってアクセスし、そのページの内容を抽出して返す機能を持っています。ここでもURLの検証が不足しています。`download_media`と同様に、攻撃者は内部ネットワークのリソースにアクセスさせることが可能です。さらに、ページの内容がツールからの応答として直接返されるため、内部情報の直接的な漏洩に繋がります。
フロントエンドから送られるプロンプトがLLMを介してこれらのツールを呼び出す場合、巧妙なプロンプトインジェクションによって、攻撃者はLLMに内部ネットワークリソースへのアクセスを誘導させることができます。例えば、AWS EC2のメタデータサービスから一時的な認証情報（アクセスキーなど）を窃取され、攻撃者がクラウド環境全体へのアクセスを許してしまうといった、極めて深刻な事態に発展する可能性があります。
フロントエンドエンジニアが知るべき対策と防御策
根本的な対策はサーバーサイドで実施されますが、フロントエンドエンジニアもシステム全体のセキュリティを理解し、安全なAPI設計や入力検証の意識を持つことが重要です。バックエンドチームとの連携を密にしましょう。
HTTPリクエストを送信する前に、URLが安全なものであるかを厳格にチェックする仕組みが不可欠です。これは最も基本的なSSRF対策です。
1. **URLスキームの確認**: `http:`または`https:`のみを許可し、`file:`などのローカルファイルアクセスや、未知のスキームを拒否します。
2. **IPアドレスのホワイトリスト/ブラックリスト**: ホスト名をIPアドレスに解決し、それがループバックアドレス（`127.0.0.1`など）、プライベートIPアドレス範囲（例: `10.0.0.0/8`、`172.16.0.0/12`、`192.168.0.0/16`）、リンクローカルアドレス（`169.254.0.0/16`など）に該当しないことを確認します。可能であれば、許可されたドメインのみをホワイトリスト化することが最も安全です。
`output_dir`パラメータがユーザー制御可能である場合、サーバー側の固定されたルートディレクトリ（例: `/var/app/downloads/`）配下に限定し、`../`のようなパスエスケープシーケンスを使って指定されたディレクトリから抜け出せないよう、パスのサニタイズを徹底します。
LLMへの入力（プロンプト）に対するフィルタリングや、LLMが出力するツール呼び出しパラメータの追加検証を導入することで、プロンプトインジェクションによるSSRF攻撃を防ぎます。LLMからのレスポンスを直接信用せず、常に検証する体制が必要です。
まとめ
GHSA-hv85-774v-26fgは、サーバーサイドリクエストフォージェリ（SSRF）がLLM連携システムにおいていかに危険であるかを示す重要な事例です。フロントエンドエンジニアとしては、直接サーバーサイドのコードを書かずとも、APIの入力検証の重要性、そしてユーザー入力がシステム全体に与える影響を深く理解し、バックエンドチームと連携してセキュアなシステム設計に貢献していくことが求められます。常に最新の脆弱性情報をキャッチアップし、安全なアプリケーション開発を心がけましょう。