サーバー側リクエスト・フォージェリ
主な洞察
サーバーサイドリクエストフォージェリとは？
サーバーサイドリクエストフォージェリ(SSRF)は、攻撃者がサーバーを騙して内部または外部のリソースに意図しないリクエストをさせることができる脆弱性です。これらのリクエストはサーバー自身から行われるため、クライアントサイドのリクエストに比べてより多くの権限やアクセスを持つことができます。SSRFを悪用することで、内部システムへのアクセスや機密データの抜き取り、組織内のネットワーク内でのさらなる攻撃が可能になります。
サーバーサイド・リクエスト・フォージェリ攻撃の仕組み
SSRF攻撃は通常、以下のステップを踏む：
- 脆弱性の特定：攻撃者は、ユーザから提供された URL を処理する、あるいは HTTP リクエストを行うウェブアプリケーション機能を特定する。
- 悪意のあるリクエストの作成：攻撃者は、内部リソースまたは機密リソースへの URL を含むリクエストを作成する。
- 脆弱性を悪用する：サーバーは悪意のあるリクエストを処理し、指定されたURLにリクエストを行う。
- 機密データへのアクセス：サーバーのリクエストが内部システムからデータを取得し、それが攻撃者に送り返され、データ漏洩や不正アクセスにつながる。
サーバーサイドリクエストフォージェリ攻撃の実例
- Capital Oneのデータ漏洩（2019年）：攻撃者はSSRFの脆弱性を悪用してAWSのメタデータサービスから機密情報にアクセスし、1億件以上の顧客記録が流出した。
- GitHub SSRF の脆弱性 (2020年)：GitHub のリポジトリミラーリング機能に脆弱性があり、攻撃者が内部リクエストをトリガーすることで、内部サービスが公開される可能性がありました。
サーバーサイドリクエストフォージェリ攻撃の指標
- 異常な送信トラフィックパターン：サーバーから内部IPアドレスまたは予期しない外部ドメインへの予期しない送信リクエストを監視することは、SSRF攻撃を示す可能性があります。
- 予期せぬアクセスログ：外部からはアクセスできないはずの内部サービスやリソースへのリクエストを示すアクセスログは、赤信号です。
- サーバー応答の異常：内部メタデータまたは機密情報を含むレスポンスがユーザーに返される。
サーバーサイドリクエストフォージェリ（SSRF）とCross-Site Request Forgery （CSRF）の違い
サーバサイドリクエストフォージェリ(SSRF)とCross-Site Request Forgery (CSRF)は、悪用されると深刻な結果を招きかねない、2 つの重大なウェブセキュリティ脆弱性です。どちらのタイプの攻撃も、ウェブ・アプリケーションの振る舞いを操作するものですが、基本的に異なる方法で動作し、 ウェブ・アプリケーションの異なる側面を狙います。SSRFとCSRFの違いを理解することは、SOCチームが適切なセキュリティ対策を実施し、システムを効果的に保護するために不可欠です。
以下は、SSRFとCSRFの主な違いを強調した詳細な比較表である：
効果的な予防戦略
1.入力検証とサニタイズ：
- すべてのユーザー入力を検証し、サニタイズし、許可されたURLとドメインのみが許可されるようにする。
- サーバーがリクエストできるURLを厳密にホワイトリスト化し、意図しない送信先を防ぐ。
2.ネットワークのセグメンテーションと分離：
- ネットワークをセグメント化し、ウェブサーバーが適切なセキュリティチェックを経ずに内部サービスに直接アクセスできないようにする。
- ファイアウォールとアクセス制御リスト（ACL）を使用して、機密性の高い内部リソースへのサーバーアクセスを制限する。
3.セキュリティ・ヘッダとプロトコルの使用：
- コンテンツ・セキュリティ・ポリシー（CSP）のようなセキュリティ・ヘッダを実装して、アプリケーションによってロードされたりリクエストされたりするリソースを制限する。
- サーバーと外部リソース間の暗号化通信を保証し、データ傍受のリスクを軽減するためにHTTPSを強制する。
4.モニタリングとログ
- 発信トラフィックを継続的に監視し、特に内部IPアドレスや予期しないドメインへのサーバー側リクエストをすべてログに記録する。
- 異常検知システムを使用して、SSRFの試みを示す可能性のある異常なリクエストパターンを特定する。
5.定期的なセキュリティ監査と侵入テスト：
- SSRFの脆弱性を特定し、対処するために、定期的なセキュリティ監査と侵入テストを実施する。
- OWASP ZAP、Burp Suite、SSRF 専用のスキャナのような自動化ツールを使用して、潜在的な SSRF の弱点を検知 。
6.最小特権の原則：
- 最小特権の原則を適用し、Web アプリケーションがその機能を実行するために必要な最小限の権限しか持たないようにします。
- サーバーの機能を制限し、絶対に必要な場合にのみ外部からのリクエストを行うようにする。
WebアプリケーションがSSRF攻撃に対して安全であることを保証することは、データの整合性を維持し、機密情報を保護するために不可欠です。アプリケーションのSSRF脆弱性にお悩みなら、Vectra AIのチームがお手伝いします。 Vectra AI Platformの無料ツアーをご利用いただき、SSRFやその他のサイバー脅威に対する防御を強化するためにどのようなお手伝いができるかをご確認ください。
サイバーセキュリティの基礎知識
よくあるご質問(FAQ)
サーバーサイドリクエストフォージェリ（SSRF）とは？
SSRFは、攻撃者がサーバーに内部または外部リソースへの意図しないリクエストを実行させることができる脆弱性であり、不正アクセスやデータ漏洩につながる可能性がある。
SSRF攻撃はどのように機能するのか？
SSRF攻撃は通常、サーバー側のリクエストを操作することによって、多くの場合、ユーザーが提供する入力を通して、サーバーに内部サービスや攻撃者がコントロールする外部サーバーのような、意図しない場所にリクエストを送らせることで機能する。
SSRF攻撃の一般的な指標は？
指標としては、異常な発信トラフィック・パターン、内部リソースへの予期せぬアクセス・ログ、不正なデータ取得を示唆するサーバー・レスポンスの異常などがある。
SSRF攻撃にはどのような例がありますか？
例えば、内部APIへのアクセス、クラウドサービスからのメタデータの取得、内部ネットワークサービスとのやり取りなどがあり、機密データの漏洩や不正行為につながる可能性がある。
SSRFはどうすれば防げるのか？
予防策には、ユーザー入力の検証とサニタイズ、信頼できる宛先へのアウトバウンド・リクエストの制限、ネットワーク・セグメンテーションの実装、ファイアウォール・ルールを使った不正アクセスのブロックなどがある。
SSRFの脆弱性の影響は？
その影響は、データの盗難や内部サービスへの不正アクセスから、リモート・コード実行などのさらなる悪用まで、ターゲットやサーバーの権限によってさまざまだ。
入力バリデーションはSSRFの防止にどのように役立つのか？
入力検証は、ユーザーが提供したデータに、サーバー側のリクエストを操作する悪意のあるペイロードが含まれていないことを保証し、それによってSSRFのリスクを軽減する。
SSRFの緩和において、ネットワークのセグメンテーションはどのような役割を果たすのか？
ネットワーク・セグメンテーションは、サーバーがセンシティブな内部リソースとやりとりする能力を制限し、SSRFエクスプロイトが利用可能な攻撃対象領域を減少させる。
セキュリティ・ヘッダはSSRFの軽減にどのように役立つのか？
コンテンツ・セキュリティ・ポリシー（CSP）のようなセキュリティ・ヘッダは、アプリケーションが相互作用できるリソースを制限し、SSRF攻撃に対する防御のレイヤーを追加することができます。
SSRFの脆弱性を検知 ためにどのようなツールが使えるか？
Burp Suite、OWASP ZAP、SSRF 専用のスキャナのようなツールは、ウェブアプリケーションの SSRF 脆弱性を特定し、分析するのに役立ちます。