【入門編】 Server-Side Request Forgery (SSRF) の悪用とメタデータサービス保護 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

こんにちは！インフラや開発の現場に飛び込んだばかりの頃は、覚えることが山積みで大変ですよね。「セキュリティ」と言われても、なんだか難しそうな専門用語ばかりで、どこから手をつけていいか途方に暮れてしまうこともあるかもしれません。

でも、安心してください。今日は、クラウドの世界でよく耳にするちょっと怖い名前の攻撃、「SSRF（サーバーサイド・リクエスト・フォージェリ）」と、その対策について、身近な「お家の防犯」にたとえながら、一歩ずつ優しく紐解いていきたいと思います。

専門知識がゼロでも大丈夫です。最後まで読めば、「なるほど、こういう仕組みだから、こうやって守るんだな！」とスッキリ理解できるようになりますよ。それでは、一緒にセキュリティの冒険に出発しましょう！

—

1. SSRFってなに？家の鍵と「パシリ」にたとえてみよう

まずは、攻撃の名前でもある SSRF（Server-Side Request Forgery）がどんなものか、イメージしやすくするために、私たちの身近な生活に置き換えて考えてみましょう。

あなたが一軒家に住んでいて、リビングのテーブルの上に「合鍵」や「金庫の暗号のメモ」が置いてあるとします。もちろん、見知らぬ他人が勝手に家に入ってきて、そのメモを見ることはできませんよね。玄関の鍵がしっかり閉まっているからです。

ところが、もし「外にいる怪しい人」が、あなたのお家で飼っている「おとなしい犬（またはロボット掃除機）」を上手に言いくるめて、あなたの代わりに金庫のメモを取ってこさせたらどうでしょう？

これがまさに SSRF の手口です。

あなたのお家（Webサーバー）： 外部からのアクセスに対して、色々な機能を提供しているプログラム。
おとなしい犬（サーバーサイドのリクエスト機能）： ユーザーからの「このURLの情報を取ってきて！」というお願いを受けて、インターネット上の別の場所にアクセスしに行くプログラムの機能。
怪しい人（攻撃者）： 直接あなたのお家には入れないけれど、Webサーバーの「リクエスト機能」を悪用して、本来は見せてはいけない秘密のデータ（クラウドの金庫のメモ）をこっそり盗み出そうとする人。

Webサーバー自身は「言われた通りに他の場所へデータを取ってきただけ」なので、セキュリティの隙を突かれやすいという特徴があるんです。

—

2. クラウドの「秘密の金庫」：メタデータサービスとは？

AWSなどのクラウド環境でシステムを動かしていると、プログラムから「今動いているサーバーのIPアドレスは何だっけ？」や「データベースに接続するためのパスワードはどれだっけ？」と確認したくなる場面がたくさんあります。

そのために用意されているのが、「インスタンスメタデータサービス（IMDS）」という便利な仕組みです。これは、サーバー自身からしかアクセスできない「特別なWEBページ（URL）」のようなもので、サーバーのパスポートや重要なお金（一時的な認証情報）がゴソッと保管されている、いわば「クラウド上の秘密の金庫」なんです。

通常、この金庫の場所（URL）は決まっていて、例えば AWS の場合は http://169.254.169.254/ という特別なIPアドレスにアクセスすると中身が見られるようになっています。

もし、ここに SSRF が起きたら……？

もし、あなたが作ったWebアプリケーションに「ユーザーが入力したURLのページを読み込んで表示する機能（例えば、画像の一括取得機能やURLプレビュー機能など）」があったとします。

そこに、攻撃者がこんな意地悪なお願いを仕込んできたらどうなるでしょうか？

「ねえねえ、その機能を使って http://169.254.169.254/latest/meta-data/ のページを見に行って、その結果を私に教えてよ！」

Webサーバーは、特に深く考えずに「お、ユーザーからのお願いだな。行ってくるか！」と、自分の足でメタデータサービス（秘密の金庫）にアクセスし、その中身（重要な認証情報など）をご丁寧に取得して、攻撃者にペロッと教えてしまうのです。

これが、クラウド環境における SSRF の恐ろしいシナリオです。

—

3. 被害を防ぐための第一歩：ネットワークの「お片付け」

では、この泥棒（攻撃者）の手口からシステムを守るには、どうすればいいのでしょうか？対策は大きく分けて2つあります。まずは1つ目の「物理的なお片付け（ネットワーク分離）」から見ていきましょう。

家の防犯にたとえるなら、「リビングに置くべき大切なメモは、鍵のかかった個室の金庫にしまい、ロボット掃除機が勝手に触れないようにエリアを分ける」という対策です。

具体的には、Webアプリケーションから、このメタデータサービスへのアクセスをそもそもできないようにネットワークの経路を制限します。

アプリケーションの実装側でも、ユーザーから受け取ったURLをそのまま信用してアクセスさせるのではなく、厳格なバリデーション（チェック）を行うことが鉄則です。例えば、PHPを使って「特定のIPアドレスやプライベートな宛先へのリクエストを禁止する」コードを書く場合は、次のような仕組みを入れます。

<?php
// ユーザーから入力されたURLを受け取る想定
$targetUrl = $_POST['url'] ?? '';

// URLが空でないか、形式が正しいかチェック
if (filter_var($targetUrl, FILTER_VALIDATE_URL)) {
    
    // パースしてホスト名やIPアドレスを抽出する
    $parsedUrl = parse_url($targetUrl);
    $host = $parsedUrl['host'] ?? '';

    // 【重要】危険な内部IPアドレスやメタデータのIPアドレス（169.254.169.254）が含まれていないかチェックする
    $blockedIps = ['169.254.169.254', '127.0.0.1', 'localhost'];
    
    if (in_array($host, $blockedIps, true)) {
        // 危険な宛先の場合は処理をストップ！
        die('エラー: その宛先へのリクエストはセキュリティ上、許可されていません。');
    }

    // 安全が確認できた場合のみ、外部へのリクエストを実行する（例: cURLを使用）
    $ch = curl_init($targetUrl);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    $response = curl_exec($ch);
    curl_close($ch);

    echo "取得結果: " . htmlspecialchars($response, ENT_QUOTES, 'UTF-8');
} else {
    echo "有効なURLを入力してください。";
}
?>

このように、プログラムの入口で「変な宛先に行こうとしていないか」をしっかり見張ることが大切なんですね。

—

4. さらに強力なガードマン！「IMDSv2」という合言葉の仕組み

ネットワークの制限に加えて、クラウド側でも進化を遂げた強力な防衛策が用意されています。それが、AWSなどで標準になりつつある 「IMDSv2（インスタンスメタデータサービスバージョン2）」 です。

従来のバージョン（IMDSv1）は、先ほどお話しした通り、URLを指定するだけで簡単にメタデータを覗き見ることができました。いわば、「合言葉なしで誰でも開けられる郵便受け」のような状態だったのです。

しかし、IMDSv2では、メタデータにアクセスする手順に「厳格な合言葉のやり取り（セッショントークンの取得）」というステップが追加されました。

IMDSv2の仕組みを覗いてみよう

攻撃者が SSRF を使ってメタデータを盗もうとしても、IMDSv2が有効な環境では、以下のステップを踏まないとデータを引き出すことができません。

1. セッションの予約（PUTリクエスト）： まず最初に、特別なコマンド（HTTPの PUT メソッド）を使って「今からデータを見たいので、一時的な合言葉（トークン）をください」と要求する必要があります。
2. 合言葉の発行： 正当なサーバーであれば合言葉が発行されますが、SSRFを悪用した通常のWebリクエスト（主に GET メソッドしか使えないことが多いです）では、この最初の「合言葉をもらうステップ」をうまくクリアできません。
3. データの取得： ゲットした合言葉をリクエストのヘッダーに含めて初めて、メタデータの情報にアクセスできるようになります。

この仕組みのおかげで、仮にアプリにSSRFの脆弱性が残っていたとしても、攻撃者が簡単にメタデータを盗み出すことができないようになっているのです。

—

5. 実務で設定してみよう：IMDSv2の強制とAWS CLIの活用

それでは、実際にクラウドインフラを構築・管理する際に、どのように IMDSv2 を有効に設定すればよいかを見ていきましょう。

これから新しいサーバー（EC2インスタンスなど）を立ち上げる際や、既存の環境を見直す際には、「IMDSv1を禁止し、IMDSv2を必須にする（Required）」設定を行います。

AWSのコマンドラインツール（AWS CLI）を使う場合、以下のようなコマンドで設定状況を確認したり、変更したりすることができます。

# 現在のインスタンスのメタデータオプション（IMDSv2の設定）を確認する
aws ec2 describe-instances \
    --instance-ids i-0123456789abcdef0 \
    --query "Reservations[*].Instances[*].[InstanceId, MetadataOptions]"

# 【重要】IMDSv2を「必須（required）」に変更し、古いIMDSv1を無効化するコマンド
aws ec2 modify-instance-metadata-options \
    --instance-ids i-0123456789abcdef0 \
    --http-tokens required \
    --http-endpoint enabled

--http-tokens required: ここで「合言葉（トークン）を絶対に必須にする」と指定しています。これがIMDSv2を強制するキモの部分です！
--http-endpoint enabled: メタデータサービス自体は有効にしつつ、上記のエンドポイント保護を効かせます。

もしお使いのTerraformなどのIaC（コードによるインフラ管理）ツールを使っている場合でも、metadata_options ブロックで http_tokens = "required" を指定するだけなので、ぜひ今のプロジェクトのコードをチェックしてみてくださいね。

—

まとめ：一歩ずつ、安全なシステムを作っていこう

今回は、SSRFの仕組みからメタデータサービスの危険性、そしてネットワーク対策や IMDSv2 による防御までを、お家の防衛にたとえながら解説してきました。

SSRFとは： 外部からのリクエスト機能を悪用されて、サーバーが意図しない内部の秘密情報を覗き見してしまう攻撃。
ネットワーク対策： アプリケーション側で許可されていない宛先（プライベートIPやメタデータIP）へのアクセスをしっかり弾く。
IMDSv2の導入： 合言葉（トークン）のやり取りを必須にすることで、万が一SSRFが起きてもメタデータを守り抜く。

セキュリティの対策は、一度にすべてを完璧にするのは難しいものです。でも、「今回はアプリケーションのバリデーションを見直してみよう」「次はクラウドの設定で IMDSv2 が有効になっているか確認してみよう」と、一歩ずつ確実に進めていくことが何よりも大切です。

日々の開発やインフラのお仕事の中で、今回の知識が少しでもあなたの心強い味方になれば嬉しいです。一緒に安全で頼もしいシステムを作っていきましょう！