用語辞典
SSRF（サーバーサイドリクエストフォージェリ）とは
SSRF（Server-Side Request Forgery）は、サーバーに『本来アクセスさせたくない宛先』へリクエストさせる脆弱性です。URLを受け取って取りに行く機能（プレビュー生成・Webhook・診断ツール等）で起きやすく、クラウドの内部メタデータ窃取から大規模漏えいにつながることも。仕組み、どんな機能で起きるか、検証で外しがちな落とし穴、そして機能を作る側の防御を、図と表で解説します。
「URLを入れたら、その中身を取ってくる」——ありふれた便利機能が、最悪の場合クラウドの鍵を奪われる入口になります。それがSSRFです。仕組みと防御をゼロから解説します。
何が起きているのか
普通のアクセスは「利用者 → 外部サイト」。SSRFは、サーバーを代理に仕立てて「内側」を叩かせます。サーバーは外部から見えない内部ネットワークや、クラウドの認証情報提供先に手が届くため、そこを間接的に覗かれてしまいます。
169.254.169.254（クラウド認証情報）クラウドでは、この内部宛先（メタデータ提供先）から 一時的な認証情報が取れることがあります。SSRFでそこに到達されると鍵を奪われ、ストレージ全体の持ち出しに連鎖します。これは実際に大規模事故になりました。→ Capital One — SSRFから1億人分が漏れた話
どこに潜むか
「ユーザーが入れたURLをサーバーが取りに行く」機能はすべて候補です。
| 機能 | ありがちな実装 |
|---|---|
| OG/リンクプレビュー生成 | 貼られたURLをサーバーが取得してサムネ生成 |
| Webhook送信 | ユーザー指定の宛先へサーバーがPOST |
| 画像・ファイル取り込み | 「URLから画像を取得」 |
| サイト診断ツール | 入力されたサイトにサーバーがアクセスして検査 |
検証で外しがちな落とし穴
「内部IPを弾けばOK」では不十分です。次の抜け道を塞ぐ必要があります。
単純なブロックでは漏れる
- リダイレクト追従：許可ドメインが
302で内部アドレスへ飛ばす。 - DNS再解決（rebinding）：検証時は外部IP、取得時に内部IPへ切り替わる。
- IP表記の揺れ：10進・8進・短縮表記などで内部アドレスを偽装。
- 別スキーム：
file://やgopher://など想定外のスキーム。
機能を作る側の防御
SSRFは「機能の作り方」で防ぎます。ITDがセキュリティ製品として自分の診断機能に課しているルールでもあります。
宛先を許可リスト方式に
スキーム（http/https）とホストを許可したものだけに限定。「内部を弾く」より「許可だけ通す」が堅い。
内部宛を遮断
127.0.0.1 / 10.x / 192.168.x / 169.254.169.254（メタデータ）等への到達を拒否。
所有確認したドメインだけ（診断系）
利用者が所有を証明したドメインのみを対象にする。第三者サイトを叩かせない。
抜け道とメタデータを塞ぐ
リダイレクトの最終到達先も検証、DNS再解決を考慮。クラウドは IMDSv2 等でメタデータをトークン必須にする。
ITDは「秘密を預からない」「所有確認したものだけ診断」「爆発半径を最小化」を設計の土台にしています（→ ITDについて）。
次に読む
- 事故：Capital One — SSRFが入口になった大規模漏えい
- 用語：RCE とは / CVE とは
- 入門：セキュリティ超入門
よくある質問
Qどんな機能でSSRFが起きやすい？
『ユーザーが入れたURLをサーバーが取りに行く』機能です。OGプレビュー生成、Webhook送信、画像取り込み、サイト診断ツールなど。便利機能ほど注意が必要です。
QなぜSSRFはクラウドで特に危険？
クラウドの仮想マシンには内部限定の『メタデータ提供先』があり、そこから一時的な認証情報が取れることがあるためです。SSRFでそこに到達されると鍵を奪われ、ストレージ全体の持ち出しに連鎖します（Capital One事故の経路）。
QSSRFをどう防ぐ？
宛先を許可リストで厳格に検証し、内部IP（127.0.0.1、10.x、169.254.169.254 等のクラウドメタデータ）への到達を遮断します。診断系なら『所有を確認したドメインだけ』に限定し、リダイレクト追跡やDNS再解決の抜け道も塞ぎます。