【入門編】 SSRF(Server-Side Request Forgery)によるクラウドメタデータ取得 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

こんにちは！Webアプリケーションの開発やインフラの管理、毎日お疲れ様です。

「セキュリティ対策ってなんだか難しそう……」「専門用語が多くて、どこから手をつけたらいいかわからない！」そんな風に感じていませんか？大丈夫です。セキュリティは、私たちの日常生活にある「ちょっとした防犯」の考え方とほとんど同じなんですよ。

今回は、Web開発の現場でこっそり、そして大きな被害をもたらす「SSRF（サーバーサイド・リクエスト・フォージェリ）」という攻撃と、その対策について、身近な例えを交えながら一歩ずつ優しく紐解いていきたいと思います。

一緒にしっかりと学んでいきましょう！

—

1. 身近な例えで理解する「SSRF」の正体

まずは、攻撃者が何をしようとしているのか、私たちの「家」に置き換えて考えてみましょう。

想像してみてください：あなたの家と「宅配ボックス」

あなたは、ネットショッピングが大好きで、自宅に便利な「宅配ボックス」を設置しました。この宅配ボックスは、あなたが直接外に出なくても、配達員さんが荷物を入れてくれる非常に便利なシステムです。

ここで、セキュリティ上の問題が生まれる可能性があります。もし、この宅配ボックスが「どこからの指示でも無条件に従う仕組み」になっていたらどうなるでしょうか？

悪意ある泥棒がやってきて、宅配ボックスに向かってこう命令します。
「私の代わりに、あの銀行の金庫の鍵を開けて、中の宝物をこのボックスに持ってきて！」

宅配ボックス（＝サーバー）は、あなた（＝開発者）からの指示ではなく、外の泥棒からの悪知恵のついた手紙に騙されて、うっかり銀行の金庫（＝クラウドの内部システム）にアクセスしてしまう……。これが、SSRF（Server-Side Request Forgery：サーバー側偽装リクエスト）の基本的な仕組みです。

—

2. クラウドの心臓部を狙う！メタデータ取得の恐怖

現代のWebサイトの多くは、AWS（Amazon Web Services）、GCP（Google Cloud Platform）、Azureといった「クラウド環境」の上で動いています。

これらのクラウドには、「メタデータサービス（IMDS）」という非常に便利な機能が用意されています。これは、サーバー自身が「自分は今、どのリージョンにいるのか」「どんな権限を持っているのか」を確認するための、いわばサーバー専用の「身分証明書の発行窓口」です。

攻撃者はどうやってクラウドを乗っ取るのか？

もし、あなたの作ったWebアプリに「ユーザーが入力したURLの画像やデータを、サーバーが代わりに取得して表示する機能（例えば、プロフィール画像のインポート機能など）」があったとします。

ここで開発者がうっかり、「外部のURLなら何でも自由にアクセスしていいよ！」というプログラムを作ってしまっていると、攻撃者は次のようなURLをあなたのサーバーに入力します。

http://169.254.169.254/latest/meta-data/iam/security-credentials/

*※「169.254.169.254」という数字の並びは、世界中のほとんどのクラウドで「メタデータサービス（身分証の窓口）」を指す特別な共通の住所になっています。*

あなたのサーバーは、ユーザー（攻撃者）に言われるがまま、この特別な住所にアクセスしてしまいます。そして、返ってきたサーバーの「強力なマスターキー（管理者権限の認証情報）」を、攻撃者にそのままペロッと見せてしまうのです。

これが、クラウド環境におけるSSRFの恐ろしいシナリオです。鍵を盗まれたサーバーは、もはや攻撃者の自由自在になってしまいます。

—

3. 泥棒を防ぐ！「許可リスト」と「ネットワーク分離」の基本

では、どうすればこの泥棒（SSRF）からサーバーを守ることができるのでしょうか？実務で使える具体的な対策を2つ、見ていきましょう。

対策①：URLの「許可リスト（ホワイトリスト）」を作る

一番確実なのは、「誰からのどんなお願いでも聞く」のをやめることです。
例えば、アクセスしていい宛先をガチガチに制限した「許可リスト」を作ります。

PHPを例に、安全なURLのチェック方法を見てみましょう。必ずマークダウンのコードブロックで囲んで記述しますね。

<?php
// ユーザーから送信されたURLを取得
$user_url = $_POST['target_url'];

// 1. URLのパース（分解）を行う
$parsed_url = parse_url($user_url);

// 2. 許可されたドメイン（信頼できる宛先）のリストを定義する
$allowed_hosts = [
    'api.example.com',
    'images.example.com'
];

// 3. ホスト名が許可リストに含まれているか厳密にチェックする
if (isset($parsed_url['host']) && in_array($parsed_url['host'], $allowed_hosts, true)) {
    
    // 安全が確認できた場合のみ、リクエストを実行する
    $response = file_get_contents($user_url);
    echo "データを正常に取得しました。";
    
} else {
    // 許可されていない宛先の場合は、処理をブロックする
    http_response_code(403);
    echo "エラー: そのURLへのアクセスは許可されていません。";
}
?>

このように、$allowed_hosts という「身元が確かなお友達リスト」を作り、それ以外の場所（内部のメタデータ用IPなど）へのアクセスを完全に遮断するのが鉄則です。

対策②：最新のクラウド環境では「IMDSv2」を強制する

AWSなどのクラウドを利用する場合、先ほどお話ししたメタデータサービスをより安全にする仕組みが用意されています。それが「IMDSv2」です。

古い仕組み（IMDSv1）は、ただ住所（URL）を指定するだけで情報が取れてしまいましたが、IMDSv2では、アクセスする際に「セッションのトークン（合言葉）」を発行し、それをヘッダーに含めないと情報を返さない仕組みになっています。

SSRF攻撃をする攻撃者は、通常、この「合言葉」を事前に持っていないため、メタデータにアクセスすることができなくなるのです。

インフラ（Terraformなど）を構築する際は、以下のように設定して古い仕組みを無効化（IMDSv2を必須化）しましょう。

# AWS EC2インスタンスの設定例
resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  # メタデータサービスのセキュリティ設定（IMDSv2を必須にする）
  metadata_options {
    http_endpoint               = "enabled"
    http_tokens                 = "required" # ←ここが「required」であることが超重要です！
    http_put_response_hop_limit = 1
  }
}

このように、インフラの初期設定の段階で「合言葉がないと中身を見せない」ようにガードしておくことが、エンジニアの強力な盾になります。

—

まとめ：一歩ずつ、安全な開発を

今回は、SSRFの仕組みと、クラウドメタデータの危険性、そして具体的な対策についてお話ししました。

SSRFは、外部からの指示でサーバーに「内緒の場所」へアクセスさせてしまう攻撃であること。
クラウドのメタデータ（169.254.169.254）は絶対に外に漏らしてはいけない重要情報であること。
アプリケーション側では「許可リスト」で宛先を厳しく制限し、インフラ側では「IMDSv2」を有効にして合言葉を求めること。

セキュリティの対策は、一度にすべてを完璧にするのは難しいものです。ですが、「ユーザーからの入力をそのまま信じない」「サーバーから外部へアクセスする機能には厳重に鍵をかける」という意識を持つだけで、あなたの作るWebアプリケーションは劇的に安全になります。

焦らず、一歩ずつ、安全なインフラとコードを作っていきましょう！応援しています。