| 脅威エージェント / 攻撃ベクトル | セキュリティ弱点 | 影響 |
|---|---|---|
| API固有：悪用可能性 容易 | 普及度 一般的：検出可能性 容易 | 技術的 中程度：特定のビジネスに依存 |
| 攻撃者はクライアントが提供するURIにアクセスするAPIエンドポイントを見つける必要があります。一般的なSSRF（レスポンスが攻撃者に返される場合）は、攻撃が成功したかどうかのフィードバックがないブラインドSSRFよりも容易に悪用できます。 | 現代のアプリケーション開発の概念では、開発者にクライアントが提供したURIにアクセスすることが推奨されています。そのようなURIの欠如または不適切な検証は一般的な問題です。問題の検出には定期的なAPIリクエストとレスポンスの分析が必要です。レスポンスが返されない（ブラインドSSRF）場合、脆弱性を検出するにはより多くの労力と創造力が必要です。 | 成功した悪用は、内部サービスの列挙（例：ポートスキャン）、情報開示、ファイアウォールの回避、またはその他のセキュリティメカニズムに影響を与える可能性があります。一部の場合、DoS攻撃や悪意の活動を隠すためにサーバーがプロキシとして使用されることがあります。 |
APIは脆弱ですか？
サーバーサイドリクエストフォージェリ（SSRF）の欠陥は、APIがユーザーが提供したURLを検証せずにリモートリソースを取得する場合に発生します。これにより、攻撃者はアプリケーションに対して意図しない宛先にクラフトされたリクエストを送信させることができます。それがファイアウォールやVPNに保護されていてもです。
現代のアプリケーション開発の概念により、SSRFはより一般的であり、より危険になっています。
より一般的な事例 – Webhook、URLからのファイル取得、カスタムSSO、およびURLプレビューに基づいて外部リソースにアクセスすることを開発者が推奨しています。
より危険な事例 – クラウドプロバイダーやKubernetes、Dockerなどの現代の技術は、HTTP経由で管理および制御チャンネルを予測可能で知られているパスで公開します。これらのチャンネルはSSRF攻撃の簡単な標的となります。
また、現代のアプリケーションの接続性のために、アプリケーションからのアウトバウンドトラフィックを制限することがより困難になっています。
SSRFリスクは常に完全に排除することができるわけではありません。保護メカニズムを選択する際には、ビジネスリスクとニーズを考慮することが重要です。
攻撃シナリオの例
シナリオ #1
ソーシャルネットワークはユーザーがプロフィール写真をアップロードできるようにします。ユーザーは自分のマシンから画像ファイルをアップロードするか、画像のURLを提供することができます。後者を選択すると、次のAPI呼び出しがトリガーされます：
POST /api/profile/upload_picture
{
"picture_url": "http://example.com/profile_pic.jpg"
}
攻撃者は悪意のあるURLを送信し、APIエンドポイントを使用して内部ネットワーク内でポートスキャンを開始することができます。
{
"picture_url": "localhost:8080"
}
レスポンス時間に基づいて、攻撃者はポートが開いているかどうかを判断できます。
シナリオ #2
セキュリティ製品はネットワークで異常を検出するとイベントを生成します。一部のチームはSIEM（セキュリティ情報およびイベント管理システム）などのより広範なモニタリングシステムでイベントをレビューすることを好む場合があります。この目的で、製品はWebhookを使用して他のシステムと統合を提供します。
新しい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
}
}"
}
]
作成プロセス中、APIバックエンドは提供されたWebhook 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
}
}
}
]
アプリケーションがテストリクエストのレスポンスを表示するため、攻撃者はクラウド環境のクレデンシャルを閲覧できます。
予防方法
- ネットワーク内のリソース取得メカニズムを分離する：通常、これらの機能はリモートリソースを取得することを目的としていますが、内部リソースではありません。
- 可能な限り、以下の許可リストを使用する：
- ユーザーがリソースをダウンロードすることを期待するリモートオリジン（例：Google Drive、Gravatarなど）
- URLスキームおよびポート
- 特定の機能に対する受け入れられるメディアタイプ
- HTTPリダイレクションを無効にする。
- URLパーサの不整合による問題を回避するために、テストされたかつ維持されているURLパーサを使用する。
- すべてのクライアント提供入力データを検証およびサニタイズする。
- クライアントに生のレスポンスを送信しない。