API7:2023 サーバサイド・リクエスト・フォージェリ（Server Side Request Forgery）
| Threat agents / Attack vectors（脅威エージェント／攻撃ベクター） | Security Weakness（セキュリティの弱点） | Impacts（影響） |
|---|---|---|
| API 固有：悪用難易度（Exploitability） 容易 攻撃者は、クライアントが指定した URI にアクセスする API エンドポイントを見つける必要がある。応答が攻撃者に返る 基本的な SSRF の方が、成否のフィードバックがない ブラインド SSRF より悪用しやすい。 |
蔓延度（Prevalence） 一般的 ： 検出可能性（Detectability） 容易 近年の開発手法は、クライアント提供の URI へのアクセスを促す。こうした URI の 検証の欠如／不備 は一般的。通常は リクエスト／レスポンスの分析 で検出できるが、応答が返らないブラインド SSRF の検出には より多くの工夫 が要る。 |
技術的影響（Technical） 中程度 ： ビジネス影響（Business） ケース依存 成功すると、内部サービスの列挙（ポートスキャン）、情報漏えい、ファイアウォール等の回避 が可能になる。場合によっては DoS や、サーバを プロキシとして悪用 して不正行為を隠蔽することにもつながる。 |
API は脆弱か？
SSRF（Server-Side Request Forgery）は、ユーザー提供の URL を検証せず に API がリモートリソースを取得する際に起こる。これにより、ファイアウォールや VPN で保護されていても、アプリケーションに 想定外の宛先へ細工したリクエスト を送らせることができる。
近年のアプリ開発の考え方により、SSRF は より一般的かつ危険 になっている。
- 一般的になった要因：Webhooks、URL からのファイル取得、カスタム SSO、URL プレビューなど、ユーザー入力に基づき外部リソースへアクセス する設計が広まっている。
- 危険になった要因：クラウド、Kubernetes、Docker などが 管理・制御チャネルを HTTP 上の既知パス に公開しており、SSRF の容易な標的 となる。
また、モダンなアプリは外部連携が多く、送信（アウトバウンド）トラフィックの制限が難しい。
SSRF リスクは 完全に排除できない場合 もある。防御策を選定する際は、事業リスクと要件 を考慮すること。
攻撃シナリオ例
シナリオ #1
SNS がプロフィール画像のアップロードを提供。ユーザーはローカルからのアップロードか、画像 URL の指定 を選べる。後者を選ぶと次の API 呼び出しが発生する：
POST /api/profile/upload_picture
{
"picture_url": "http://example.com/profile_pic.jpg"
}
攻撃者は悪意ある URL を送って、内部ネットワークのポートスキャン を API 経由で実行できる：
{
"picture_url": "localhost:8080"
}
応答時間 に基づき、ポートが開いているかどうかを推測できる。
シナリオ #2
あるセキュリティ製品はネットワーク異常を検知するとイベントを生成し、Webhooks で SIEM など外部監視に連携できる。新規 Webhook 作成の一環で、SIEM API の URL を含む GraphQL ミューテーションを送る：
POST /graphql
[
{
"variables": {},
"query": "mutation {
createNotificationChannel(input: {
channelName: \"ch_piney\",
notificationChannelConfig: {
customWebhookChannelConfigs: [
{
url: \"http://www.siem-system.com/create_new_event\",
send_test_req: true
}
]
}
}){
channelId
}
}"
}
]
作成処理では、バックエンドが 指定 URL にテストリクエスト を送り、その応答をユーザーに表示 する。
攻撃者はこのフローを悪用し、クラウドメタデータサービス のような機密リソースへ API にリクエストさせる：
POST /graphql
[
{
"variables": {},
"query": "mutation {
createNotificationChannel(input: {
channelName: \"ch_piney\",
notificationChannelConfig: {
customWebhookChannelConfigs: [
{
url: \"http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm\",
send_test_req: true
}
]
}
}) {
channelId
}
}
}
]
アプリが テストリクエストの応答を表示 するため、攻撃者は クラウド環境の資格情報 を閲覧できてしまう。
防止方法（How To Prevent）
- リソース取得機構をネットワーク上で分離 する：これらの機能は通常 外部リソース取得専用 であり、内部向けではない想定で設計する。
-
可能な限り 許可リスト（Allow List） を用いる：
-
ユーザーがリソースを取得することが想定される リモートオリジン（例：Google Drive、Gravatar など）
- URL スキームとポート
-
機能ごとに 受け入れるメディアタイプ
-
HTTP リダイレクトを無効化 する。
- 実績ある URL パーサ を用いて、パースの不一致による問題を回避する。
- クライアント入力を検証・サニタイズ する。
- 生の応答をクライアントへ返さない。