AIにURLを読ませる前に。SSRFから内部ネットワークを守る実務対策

こんにちは、Ryohei（@ityryohei）です！

AIに「このURLを読んで要約して」と頼む。記事作成や問い合わせ対応では便利な機能ですが、URLの取得を自社サーバーが代行しているなら、文章の正確さとは別に確認すべきことがあります。その取得処理は、社内サービスやクラウドの管理用情報にも接続できる状態になっていないでしょうか。

問題になるのがSSRF（Server-Side Request Forgery）です。AIだけに固有の脆弱性ではなく、従来の画像取り込みやリンクプレビューにも存在する設計上の弱点です。本記事では攻撃事件の速報ではなく、AI連携を導入するWeb運営者向けに、URL取得の境界を点検する方法を解説します。

情報確認日：2026年10月14日。以下は同日に確認した公式技術資料に基づく解説と、本サイトからの運用上の提案です。資料の確認日を新たな事件の発生日や各資料の公開日として扱うものではありません。特定のサイトや製品が侵害されたと主張する記事でもありません。

SSRFは「サーバーに代わりにアクセスさせる」問題

MITREのCWE-918：SSRFは、サーバーが受け取ったURLなどの内容を取得する際、期待する接続先であることを十分に確認しない弱点として整理しています。外部の利用者からは直接届かない場所でも、取得を代行するサーバーからは届く可能性があります。

例えば、公開サイトの要約機能が社内管理画面と同じネットワークで動いている構成を考えます。利用者が渡したURLを無条件で取得すると、その処理が公開ページ以外にも接続する余地が生まれます。管理画面が「内部からの通信だから」と認証を弱めていれば、取得処理が意図しない橋渡しになり得ます。これは説明用の仮想例であり、実際に起きた事件の記述ではありません。

影響は到達先と権限に左右されます。レスポンスを読めるか、認証情報を付けるか、GET以外の操作を許すかによって危険度は変わります。「URLを渡せる」というだけで機密流出を断定できません。一方、内容を利用者に返さない取得処理でも、不要な内部通信が発生していないかは確認対象です。

AI連携で確認すべきは、モデルより取得ツール

AIが外部ページを読んだ結果、別のURLを取得するよう誘導される場面も考えられます。OWASPのAI Agent Security Cheat Sheetは、外部入力による行動の誘導、過剰なツール権限、ツール呼び出し経由の情報流出をリスクとして挙げています。ここで重要なのは、最終的に通信を実行するプログラム側の制約です。

「内部URLにはアクセスしないで」とシステムプロンプトに書いても、HTTPクライアントの接続能力が変わるわけではありません。モデルが選んだURLも、ユーザーが入力したURLも、取得ツールでは信頼しない入力として扱う必要があります。AIの回答が安全そうであることと、その途中の通信が安全であることは別です。

まず構成図に、URLを決める人・モデル、実際に接続するサービス、結果の保存先を書き出すことを提案します。SaaS側で取得するのか、自分のWordPressサーバーで取得するのか、別のワーカーで取得するのかを区別してください。自社側に取得機能がないなら、サーバー設定だけを変更してもSaaS側の接続制御にはなりません。提供元の仕様や契約で確認する問題になります。

「公式サイトだけ」と「任意のURL」では設計が違う

OWASPのSSRF Prevention Cheat Sheetは、接続先を既知の信頼できる相手に限定できる場合と、任意の外部サイトに接続する場合を分けています。前者では許可リストを使えます。後者では、入力されたドメイン名の見た目だけを確認しても十分ではありません。

実務では、汎用ブラウジングを作る前に用途を狭める方が点検しやすくなります。例えば「指定した提供元のリリースノートを読む」機能なら、提供元を選ぶ識別子だけを受け取り、通信先や必要なパスはアプリ側で組み立てる設計を検討できます。ユーザーが任意のURL、ポート、認証ヘッダーを渡せる機能にする必要があるのかを先に決めましょう。

任意の公開ページを読むことが必須なら、制約をなくすのではなく、専用の取得サービスに仕事を分けることを提案します。公開ページの収集担当に、社内管理APIへの接続や本番データベースの資格情報まで与えない構成です。社内文書の取得は、認可済み文書を読む別の機能として設計し、同じ自由入力のURL取得ツールに混ぜない方が責任範囲を説明できます。

URLの文字列検査と、実際の接続先をそろえる

ドメイン名はDNSでIPアドレスへ変換されます。また、最初にアクセスしたページが別の場所へリダイレクトすることもあります。OWASPは、許可したドメインでも名前解決後の宛先を確認し、検証済みの宛先に実際に接続すること、未検証の再解決や再試行で制約が抜けないことを求めています。リダイレクトの自動追従を止める対策も示しています。

ここを独自の短い正規表現だけで実装することは勧めません。URLの解析、IPv4・IPv6、転送先、再試行を含めて、利用するライブラリとネットワーク制御が何を保証するのかを開発担当者に確認しましょう。検証済みIPへ接続する設計でも、元のホスト名に対するTLS証明書の検証を無効にしてよいわけではありません。

運用上の受け入れ条件としては「転送したら成功した」だけでなく、「禁止先への転送は拒否される」を含めることを提案します。HTTPクライアントを更新したとき、プロキシを追加したとき、IPv6を有効にしたときも同じ条件を再確認します。アプリの入口と通信の出口で判定が食い違うなら、安全だと判断する材料にはなりません。

WordPressではsafe系APIと例外設定を点検する

WordPressで外部の任意URLをGET取得する独自機能を作る場合、公式のwp_safe_remote_get()が点検の起点になります。公式説明では、URLとリダイレクト先を検証し、対応プロトコルをHTTPとHTTPSに限定しています。通常のHTTP取得関数が使われていたら直ちに脆弱だと断定するのではなく、周囲に同等の制約があるかを確認します。

wp_http_validate_url()の公式リファレンスには、内部向けIPや通常と異なるポートの扱いと、それを変更するフィルターが示されています。「接続できないから」という理由だけで例外を広げると、想定した境界を弱めるおそれがあります。また、資料に掲載されたコードと、稼働中のWordPressのバージョンやプラグインの実装が同一とは限りません。

サイト運営者から開発担当者へは、画像のURL取り込み、OGP生成、外部記事の自動要約、Webhookの接続確認という機能名で質問すると伝わりやすくなります。コアのHTTP APIを通るのか、プラグイン独自の通信ライブラリを使うのかも確認してください。safeという名前の関数を使っていることだけで、サイト全体の通信経路が保護されているとは判断しないでください。

EC2ではメタデータを別の境界として扱う

AWS EC2で取得サービスを動かしている場合は、インスタンスメタデータサービスも点検対象です。AWS公式：IMDSの利用方法では、IMDSv2がセッショントークンを使う仕組みと、IMDSv2だけを受け付けるよう設定できることを説明しています。トークンを必須にすると、有効なトークンのない要求は拒否されます。

ただし、IMDSv2はURL取得機能全体の安全性を保証するものではありません。内部管理画面への接続制限とは別に扱い、メタデータの利用設定、取得ワーカーが持つクラウド権限、ネットワークの到達性をそれぞれ確認することを提案します。設定変更前にはSDKや既存処理への影響を検証し、可用性を壊さない手順にします。

これはEC2を管理している場合の話です。共有レンタルサーバー上のWordPress運営者が、そのまま同じ設定を変更できるとは限りません。ホスティング事業者には、外部URL取得処理から内部ネットワークや管理用サービスへの通信をどのように制限しているかを確認しましょう。設定権限がない部分は、提供元の対応範囲を把握することが実務上の対策になります。

Web運営者が進める点検の優先順位

以下は、本サイトからの実施順序の提案です。大規模な仕組みを一度に作るのではなく、不要な通信経路を減らし、必要な機能について検証できる形にすることを目標にします。

最優先：URL取得機能を棚卸しする。機能名、入力の出所、実行場所、利用者、持っている資格情報、接続可能なネットワークを一組として記録する。
次に：不要な自由入力を減らす。固定の情報源で足りる処理は許可した接続先に限定し、認証ヘッダーやCookieを任意の取得先へ渡す設計を避ける。
実装確認：初回接続だけでなく、名前解決、転送、再試行も制約の対象かを確認する。ネットワーク側でも取得担当の到達先を絞る。
負荷と記録：取得時間、応答サイズ、回数に上限を設け、拒否理由を記録する。ログに機密トークンや個人情報入りURLを丸ごと保存しない。
変更管理：通信ライブラリやプラグインの更新後に、許可した取得が動き、禁止した取得が止まることを再確認する。

テストは許可された検証環境で行います。運営していないサイトや本番の管理サービスを探査して確認する必要はありません。開発担当者と、通常の取得、許可外の接続先、転送、接続失敗、上限超過のケースを決め、期待する結果を記録してください。禁止先へ実際に届いてからエラーになるのではなく、接続自体を防ぐことを合格条件にします。

WAFやAIの見直しだけでは埋まらない部分

受信するWebリクエストを検査するWAFと、取得ワーカーから出ていく通信の制御は、確認すべき場所が違います。WAFにSSRF向けの機能があっても、利用中の構成でどこまで検査できるかを確かめずに代替対策とみなすべきではありません。生成した記事を後から人が読んでも、すでに行われた接続を取り消すことはできません。

逆に、内部宛ての接続を止めても、公開サイトから取得した内容の真偽や、プロンプトインジェクションまで解決するわけではありません。取得先の制御、取得した情報の扱い、公開内容の推敲は別々に必要です。AIの性能を信頼する話ではなく、URLを受け取ったプログラムにどの通信を許すかという設計の話として点検すると、具体的な改善につながります。