SSRF（Server-Side Request Forgery、サーバーサイドリクエストフォージェリ）は、攻撃者が指定し&#x305FURLに対して、サーバー自身がリクエストを送ってしまう脆弱性です。たとえばチャットツールでURLを貼ると自動的にタイトルや画像が表示される「リンクプレビー」機能、画像を外部URLから取り込む「画像インポート」機能、PDF生成のために外部ページを読み込も機能など、「サーバーに代わり&#x306BURLへアクセスしてもらう」機能は驚くほど多くのサービスに存在します。

通常はこの機能で取得した内容を、ユーザーがそのまま受け取れるだけです。ところがサーバーが取得先&#x306EURLを十分に検証していないと、ユーザーは「外部&#x306EWebページ」だけでなく、「サーバー自身からしか到達できない内部ネットワークのアドレス」を指定できてしまいます。サーバーは内部ネットワークの一部として扱われているため、外部のファイアウォールでは防げない、内側からのアクセスが成立してしまうのです。

2019年に大手金融機関で発生し&#x305F1億人規模の顧客情報漏洩事件は、WAF（Web Application Firewall）の設定ミスを悪用し&#x305FSSRFが起点でした。攻撃者&#x306FSSRFを使ってクラウドの内部メタデータサービスに到達し、そこから強い権限を持つ認証情報を盗み出し、最終的に大量のデータが保存されたストレージへのアクセス権を獲得しました。本話で体験する攻撃の流れは、この事件の構造を学習用に再現したものです。

クラウド環境（AWS&#x30FBAzure&#x30FBGCPなど）では、サーバー（インスタンス）が安全に認証情報を取得できるよう、特別な「メタデータサービス」という仕組みが用意されています。AWSではこれを「インスタンスメタデータサービス（IMDS）」と呼び、169.254.169.254という特別なアドレスにアクセスすると、そのサーバーに割り当てられた一時的&#x306AIAM認証情報を、パスワードなしで取得できます。

169.254.169.254は「リンクローカルアドレス」と呼ばれる特殊な範囲&#x306EIPで、インターネットからは到達できず、そのサーバー自身からしかアクセスできません。本来は「サーバー自身しかアクセスできない」という前提に守られた、安全な仕組みです。ところがSSRFを使うと、攻撃者は「サーバー自身になりすまして」このアドレスにアクセスさせることができてしまいます。

SSRF対策としてよくあるのが、「169.254.169.254や127.0.0.1、localhostといった文字列が含まれていたらブロックする」というブロックリスト（denylist）方式です。一見もっともらしい対策ですが、IPアドレスには複数の「別の書き方」が存在するため、文字列の完全一致や単純な部分一致だけでは簡単に回避されてしまいます。

本話のチャレンジでは、このうち最も基本的な「10進数表記」を使ったバイパスを体験します。サーバーのブロックリストは169.254.169.254という文字列だけをチョックしているため、同じ宛先を指す2852039166という数字をブラウザやHTTPクライアントに渡すと、ブロックリストをすり抜けて本来の宛先に到達してしまいます。

架空のクラウドサービス「やさいクラウド」には、チャットのリンクプレビー機能を模した&#x300CURL先読みラボ」があります。URLを入力すると、サーバー（のふりをしたこのページ）が代わりにアクセスして、結果を表示します。ただし「内部アドレスとして有名な文字列」はブロックされます。

SSRFは「サーバーにリクエストを代行させる機能」自体をなくすことが難しいため、複数の対策を重ねる多層防御が基本です。

• 許可リスト方式：到達可能な宛先を明示的に絞る
• メタデータサービス側の対策：IMDSv2の強制（AWSではアカウント単位で設定可能）
• ネットワーク分離：サーバーから内部管理用ネットワークへの経路自体を制限する
• リダイレクトの検証：最初&#x306EURLだけでなく、リダイレクト先も毎回検証する

第2話では、SSRFという新しい脆弱性クラスを使って、ブロックリストの回避からクラウドメタデータサービスからの認証情報窃取まで一気に体験しました。次回はSSTI（テンプレートインジェクション）という、コード実行にもつながる脆弱性クラスを扱います。