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

こんにちは！日々の開発やインフラの管理、本当にお疲れ様です。「セキュリティの勉強を始めなきゃいけないけれど、専門用語が多くて何から手をつければいいか分からない…」そんな風に悩んでいませんか？

今回は、Webアプリケーションの裏側を狙うちょっぴり怖い攻撃「SSRF（サーバーサイドリクエストフォージェリ）」と、クラウド環境を守るための強力な盾について、身近な例えを交えながら一歩ずつ優しく紐解いていきたいと思います。

難しく考えず、まずは「家と泥棒」のストーリーから覗いてみましょう！

—

1. 「SSRF」ってなぁに？身近な例えで仕組みを知ろう

突然ですが、みなさんのご自宅を想像してみてください。

頑丈な玄関の鍵を閉めて、郵便受けの隙間から「外にいるお友達に手紙を出して！」と、あなたの代わりに家族や執事（お使い係）にお願いしてポストへ投函してもらうとします。この「お使い係」は、外の世界と自由にお話ができますよね。

さて、もしここに悪意を持った泥棒がやってきて、郵便受けの隙間からこんな風にお願いしてきたらどうなるでしょうか？

「ねえ、そのお使い係さん。私の代わりに、『家の中にある金庫の暗証番号』をこっそり見てきてよ！」

お使い係は何も疑わずに、家の中の金庫へ近づき、その中身を覗き見して泥棒に教えてしまいました……。これが、まさに SSRF（Server-Side Request Forgery：サーバーサイドリクエストフォージェリ） の正体です。

Webの世界に置き換えてみましょう

Webアプリケーションには、ユーザーが入力したURLの画像やデータを取得して表示する便利な機能（例えば、プロフィール画像に他のサイトのURLを指定して読み込む機能など）がよくあります。

攻撃者はこの機能を利用して、本来なら外部の人がアクセスできないはずの「社内システム」や「クラウドの秘密の管理画面」のURLを、Webサーバー（お使い係）にしれっと読み込ませます。

サーバーは「主人（ユーザー）の命令だから」と信じ込み、内緒でその場所へアクセスして機密情報を拾い上げ、攻撃者に返してしまうのです。これが、SSRFが恐れられている理由です。

—

2. 攻撃者はどこを狙うのか？クラウドの心臓部「メタデータ」

現代のシステムは、AWS、Google Cloud、Microsoft Azureといった「クラウド環境」の上で動いていることがほとんどですよね。

これらのクラウド上にあるサーバーには、「メタデータサービス」という、いわばサーバー自身の「身分証や合鍵が入ったロッカー」のような特別な仕組みが備わっています。

例えば、AWSというクラウドでは http://169.254.169.254/ という特別なIPアドレスにアクセスすると、そのサーバーがクラウド上でどんな権限を持っているか、どんなパスワード（認証情報）を使っているかといった、門外不出の超機密データが取得できるようになっています。

もし、あなたの作ったWebアプリにSSRFの脆弱性があると、攻撃者はこのロッカーの場所を突き止め、クラウドの管理者権限を丸ごと乗っ取ってしまうかもしれないのです。恐ろしいですよね……！

—

3. 脆弱性のあるコードってどんなもの？（PHPの例）

百聞は一見にしかず。なぜSSRFが起きてしまうのか、脆弱なコードの例を見てみましょう。次のPHPコードは、ユーザーが入力したURLの画像データをそのままダウンロードして表示するプログラムです。

<?php
// 【危険な実装例】ユーザーからの入力をそのまま信用してしまっています
$user_url = $_GET['url'];

// ユーザーが入力したURLに対して、サーバーが直接リクエストを送る
// ここで攻撃者が 「http://169.254.169.254/...」 などを入力すると……？
$image_data = file_get_contents($user_url);

// 取得したデータをブラウザに表示する
header('Content-Type: image/jpeg');
echo $image_data;
?>

上記のコードの何がいけないか分かりますか？そう、「サーバーが外部から渡されたURLを全くチェックせずに、そのままアクセスしている点」です。これではお使い係が泥棒の言いなりになってしまいます。

—

4. 救世主登場！クラウドを守る「IMDSv2」の仕組み

「じゃあ、クラウドの身分証ロッカーをどうやって守ればいいの？」という疑問が湧きますよね。

昔のバージョン（IMDSv1）では、先ほどのようにURLを指定するだけで簡単に機密情報が取れてしまいましたが、現在の主流である 「IMDSv2」 では、泥棒をシャットアウトするための厳重な「合言葉（トークン）」の仕組みが導入されました。

例えるなら、「ロッカーを開けるには、まず受付で『今日だけの特別な整理券（トークン）』を発行してもらい、その整理券を提示しないと中身を見せない」というルールに変更されたのです。

IMDSv2の仕組み（リクエストのステップ）

1. 整理券の要求（PUTリクエスト）：
サーバーは、まず特別なヘッダー（例: X-aws-ec2-metadata-token-ttl-seconds）をつけて、専用の受付（URL）に「整理券をください」と頼みます。
2. 整理券のゲット：
受付は、正当な手順を踏んだサーバーにだけ「整理券（セッショントークン）」を発行します。
3. 機密情報の取得：
その整理券をしっかりと持っていること（ヘッダーに含めること）を証明して初めて、メタデータ（機密情報）にアクセスできます。

悪意ある攻撃者がSSRFを使って外から適当なURLを叩こうとしても、この「最初の整理券を発行する手順（PUTメソッドや特殊なヘッダーの付与）」を攻撃者のブラウザから直接コントロールするのは非常に難しいため、クラウドの内部情報をガッチリ守ることができるというわけです。

—

5. 実務で今すぐ実践できる防御・対策ステップ

「うちはクラウドを使っているから大丈夫かな？」と不安になったそこのあなた！以下のチェックリストをもとに、今日からできる対策を確認していきましょう。

① クラウドの設定を確認する（IMDSv2を必須にする）

AWSなどのクラウド環境を利用している場合、古いバージョンのメタデータ（IMDSv1）を無効化し、IMDSv2を強制（必須化）しておきましょう。これだけでSSRFによる悪意ある情報取得リスクを劇的に下げることができます。

② アプリケーション側でURLを厳しくホワイトリスト管理する

ユーザーからURLを受け取る必要がある場合は、何でもかんでもアクセスさせるのではなく、許可されたドメイン（例: https://example.com/images/ のみ許可）だけをブラックボックス的に許可する「ホワイトリスト方式」を採用しましょう。

<?php
// 【安全な実装例のイメージ】
$user_url = $_GET['url'];

// 許可されたドメインのリスト（ホワイトリスト）
$allowed_domains = ['images.example.com', 'cdn.example.net'];

// パースしてホスト名を取得
$parsed_url = parse_url($user_url);
$host = $parsed_url['host'] ?? '';

// ホワイトリストに含まれているか厳密にチェックする
if (!in_array($host, $allowed_domains, true)) {
    // 許可されていないドメインの場合は処理を中断する
    die('エラー: このURLへのアクセスは許可されていません。');
}

// チェックを通過したものだけ安全に処理する
$image_data = file_get_contents($user_url);
// ... 続く
?>

③ 内部IPアドレスへのアクセスをブロックする

プライベートIPアドレス（例: 10.0.0.0/8, 192.168.0.0/16）や、先ほど登場したクラウドメタデータのIPアドレス（169.254.169.254）など、「外部からアクセスされてはいけない宛先」へのリクエストをコードやネットワーク（ファイアウォール）のレベルで事前に弾くように設定しましょう。

—

さいごに

セキュリティの勉強は、最初は聞きなれない言葉が多くて難しく感じるかもしれません。でも、「家と泥棒」「お使い係と合言葉」のように身近なものに置き換えて考えてみると、攻撃が起きる仕組みも、それを防ぐためのルールもスッと頭に入ってきませんか？

一歩ずつ、焦らずに知識を身につけていけば、あなたも必ず頼りになる堅牢なシステムを作れるようになります。今日の学びを、ぜひ明日からの開発やインフラ設計に役立ててみてくださいね！