SSRFとは？仕組みと被害、許可リストを軸にした対策を解説

SSRF（サーバーサイドリクエストフォージェリ）は、Webアプリケーションのサーバーを悪用して、内部ネットワークや外部、サーバー自身へ意図しないリクエストを送らせる攻撃です。外部から直接は届かない内部のサービスに、サーバーを経由して届いてしまう点が問題です。対策の基本は、接続先を許可リストで絞り、通信経路そのものも制限することです。

SSRFとは

通常、社内のAPIやデータベースの管理画面はインターネットから直接アクセスできません。しかしWebサーバーはそれらと同じネットワークにあることが多く、サーバーが出すリクエストは届きます。SSRFはこの関係を利用する攻撃です。

OWASPのチートシートは、起点の多くはURLの扱いの不備だとして、次のような機能を例に挙げています。

対象はHTTPに限りません。OWASPは file:// など他のスキームも使われうること、XXE（XML外部実体参照）がSSRFにつながることも挙げています。

OWASP Top 10では、2021年版で独立したA10だったSSRFが、2025年版ではA01「Broken Access Control」に統合されました（CWE-918）。全体の変更点はOWASP Top 10の解説にまとめています。

起こりうる被害

OWASPのコミュニティページは、影響の例として次を挙げています。クラウド環境では、メタデータサービスから認証情報やアクセストークンを盗む目的でよく使われるとチートシートも説明しています。

接続先が決まっている場合の対策

OWASPは、接続先が事前に分かっている場合と、任意の外部へ接続する必要がある場合に分けて対策を示しています。まず、機能を見直して前者にできないかを確認します。

接続先が決まっているなら、URL全体を入力として受け取らず、サーバー側でURLを組み立てます。次の例では、利用者が指定できるのは画像のIDだけです。

const imageIdPattern = /^[a-z0-9-]{1,64}$/;

const fetchImage = async ({ imageId }) => {
  if (!imageIdPattern.test(imageId)) {
    throw new Error("画像のIDが正しくありません");
  }

  return fetch(`https://images.example.com/${imageId}`, {
    redirect: "error",
  });
};

redirect: "error" は、リダイレクトの応答が返ったときにリクエストを失敗させるFetch APIの指定です。既定値は follow で、リダイレクト先まで自動で取りに行きます。OWASPは、リダイレクトが入力値の検証をすり抜ける手段になるとして、HTTPクライアントのリダイレクト追従を無効にするよう勧めています。

任意の外部に接続する場合の対策

Webhookのように宛先を事前に決められない機能では、次を組み合わせます。

1. 解決後のIPアドレスを確かめる

   ドメイン名だけでなく、名前解決した結果のIPアドレスがプライベート・ローカル・リンクローカルの範囲でないかを確かめ、確かめたアドレスにだけ接続します。名前解決の確認と接続を別々に行うと、その間に結果を変えられるおそれ（DNSリバインディング）があります。

2. プロトコルと送る内容を限定する

   プロトコルは許可リスト（HTTPまたはHTTPS）で確かめます。OWASPは、接続先へ渡すパラメータ名やトークンの形式も送信前に検証する方法を示しています。

3. 接続先に正当性を確かめさせる

   接続先のアプリケーションが発行したランダムなトークンを、POSTで受け取って確かめる方法です。

4. リダイレクトを追わない

   検証を通ったURLから別の宛先へ転送されないように、追従を無効にします。

ネットワークとクラウド側の対策

アプリケーションの検証は、1か所漏れると破られます。OWASPは通信経路の制限も重ねるよう勧めています。

AWSのIMDSv2は、PUTリクエストでセッション用のトークンを作り、以後のリクエストにそのトークンを付けるセッション方式です。AWSの設定により、IMDSv2の呼び出しだけを受け付けるようにできます。OWASPは、これを一部のSSRFを和らげる多層防御の一つとしており、完全な解決策ではないとしています。

よくある質問