- サーバーをプロキシにして内部リソースやクラウドのメタデータへ不正アクセスさせるSSRFの驚異
- IAMロールの認証情報奪取を防ぐIMDSv2の有効化と、アクセス先URLの厳格なホワイトリスト管理
- プロトコル制限やDNSリバインディング対策など、リクエスト送信機能をセキュアに保つ実装の鉄則
SSRF（サーバーサイドリクエストフォージェリ）とは？
SSRFは、攻撃者がサーバーに対して「外部からはアクセスできない内部リソース」へのリクエストを強制させる脆弱性です。
サーバーがプロキシ（代理）として動作し、攻撃者の代わりに内部ネットワーク上のデータベースや管理パネル、あるいはクラウドのメタデータサーバーへアクセスしてしまうことで発生します。
脆弱性が発生する仕組み
「URLを入力して画像をプレビューする」ような機能が典型的な狙い所です。
// 脆弱な実装例
const imageUrl = req.query.url;
const response = await fetch(imageUrl); // 入力URLをそのままフェッチ
攻撃者が url=http://169.254.169.254/latest/meta-data/ （クラウドのメタデータエンドポイント）を指定すると、サーバーは内部でこれを実行し、IAMロールの認証情報などの機密情報を攻撃者に返してしまいます。
根本的な対策：宛先のホワイトリスト化
最も確実な対策は、サーバーがアクセスできる**「宛先ホスト（IP/ドメイン）」を厳格に制限すること**です。
対策のポイント（仕様まとめ）
| 対策手法 | 実装の方向性 | エンジニアとしての所感 |
|---|---|---|
| 宛先ホワイトリスト | 許可したドメイン以外へのアクセスをアプリケーション層で遮断する | 自由なURL入力を許さないことが、最大の防御です。 |
| IMDSv2の利用 | クラウドのメタデータアクセスにセッショントークンを必須化する | AWS等で推奨される対策。SSRFによる認証情報の奪取を困難にします。 |
| ネットワーク分離 | 踏み台となるサーバーから内部DB等への経路をFWで絞る | アプリの脆弱性が突かれても、ネットワーク的に遮断する多層防御です。 |
2026年3月の現場感: 「URL取得機能」はほぼ全部 SSRF 候補
2026年3月の Reddit やクラウド運用者の議論を見ていると、SSRF は「画像プレビュー」だけの話ではなく、Webhook テスター、OGP 取得、URL インポート、PDF 変換、AI エージェントの外部 fetch、Slack 連携の検証機能まで含めて考えるのが普通になっています。つまり「ユーザーが多少でも URL を触れる」機能は、ほぼすべて監査対象です。
また AWS 周辺では、IMDSv2 への移行が進んだことで「もう SSRF で認証情報は取られない」と安心する声もありますが、現場ではそう単純ではありません。IMDSv2 未対応の古いツールや、コンテナ運用で hop limit 設定に依存している構成が残っていると、セキュリティ強化が運用破綻を招き、結果として設定を緩めるという本末転倒が起こりがちです。2026年時点で強い構成は、IMDSv2 にすること自体ではなく、そもそもメタデータへ触らなくて済む権限設計まで持っていくことです。
私なら、URL取得機能を見つけた時点で次を確認します。
- 許可ドメイン方式にできるか
- リダイレクト後の再検証をしているか
- タイムアウトとレスポンスサイズ上限があるか
- メタデータIPやプライベートレンジを二重に遮断しているか
トラブルシューティング：セキュアなプロキシ機能の実装手順
外部リソースを取得する機能を実装する際は、以下のステップを遵守します。
1. プロトコルの制限
http, https のみに制限し、 file:// や gopher:// などの危険なプロトコルを無効にします。
2. プライベートIPの遮断
名前解決後のIPアドレスをチェックし、 127.0.0.1 や 10.0.0.0/8 などのプライベートレンジである場合は接続を拒否します。
3. DNSリバインディング対策
IPチェックと実フェッチの間にDNSが書き換えられる攻撃を防ぐため、名前解決した結果のIPアドレスを固定して接続します。
4. リダイレクトとレスポンスサイズを制限する
SSRF は「最初の URL は安全そうだが、途中で危険な宛先へ飛ぶ」ケースが厄介です。自動リダイレクトは無制限に追わず、回数上限を置き、遷移先ごとに再度 allowlist / IP 判定をかけてください。合わせてレスポンス上限を決めておくと、巨大ファイル取得による DoS も抑えられます。
5. 権限設計でメタデータ依存を減らす
EKS なら IRSA、ECS なら Task Role のように、インスタンスメタデータへ直接依存しない認証方式へ寄せると、SSRF の被害半径をかなり縮められます。IMDSv2 は重要ですが、最終的には依存箇所そのものを減らす方が堅いです。
実務で効く確認ポイント
| 確認項目 | 合格ライン | 注意点 |
|---|---|---|
| 宛先制限 | 自由入力ではなく許可ドメイン制 | 「一部だけ自由入力」が最も事故を生みやすい |
| IP遮断 | ループバック、RFC1918、リンクローカル、メタデータIPを拒否 | DNS結果と実接続先の両方を見る |
| リダイレクト | 上限あり、各段で再判定 | 初回だけの判定では不足 |
| 実行制御 | timeout、max body、メソッド制限 | SSRF は情報漏えいだけでなく負荷事故にもつながる |
| クラウド構成 | IMDSv2、有効なロール境界、不要な内部到達性なし | アプリだけ直してもネットワークが広いと危険 |
よくある質問（FAQ）
Q: クラウド環境以外ではSSRFは怖くありませんか？
A: いいえ、社内LANのファイル共有サーバーや管理ポータルなどが狙われるリスクがあり、依然として重大な脅威です。
Q: WAFでSSRFは防げますか？
A: 一部の既知の攻撃パターン（メタデータIPなど）は防げますが、カスタムなパスやDNS経由の攻撃を完全に防ぐのは困難です。アプリ側での実装が必須です。
Q: IMDSv2 を有効化していれば SSRF 対策は十分ですか？
A: いいえ。IMDSv2 はクラウドメタデータの保護として強力ですが、内部 API、Redis、社内管理画面、Webhook 先など別の内部到達先は残ります。SSRF は「どこへ到達できるか」の問題なので、URL取得機能そのものの制御が中心です。
自分が踏んだ落とし穴と回避策
書いている内容は、私が実際に踏んだトラブルとその回避策が中心です。対処手順だけ書いて終わるのではなく、『なぜ最初の選択肢を捨てたか』『どのログを見て判断したか』も残すようにしています。製品アップデートで前提が変わったときに、この記事を読み直して自分でも辿り直せる形にしておくのが目的です。
