SSRFとは

SSRFは、攻撃者がWebアプリケーションやAPIを操作して内部リソースにリクエストを送信させることで発生するセキュリティ上の欠陥の一種であり、不正アクセス、データ漏えい、システム侵害、リモートコード実行につながる可能性があります。攻撃者は入力検証を回避し、ファイアウォールや仮想プライベートネットワーク（VPN）ソリューションで保護されている場合でも、アプリケーションに悪意のあるWeb上の宛先へアクセスさせます。

SSRF攻撃とは何か、どのように機能するのか

SSRF攻撃では通常、攻撃者はサーバー側のHTTPリクエストの送信先URLを指定するために使用される入力を操作します。これは、アプリケーションがリモートリソースからデータを取得する前に、ユーザーが入力したURLを検証またはサニタイズしない場合に発生する可能性があります。攻撃者は標的のサーバーに任意の宛先へのリクエストを実行させることができ、その結果、さまざまなセキュリティリスクが生じる可能性があります。

このような攻撃は、標的となるリソースがクラウドメタデータサービスやバックエンドAPIなどの他のシステムと信頼関係にある場合にも発生する可能性があります。攻撃者は、その信頼されたサービスにリクエストを送信し、機密情報を抽出したり、不正な操作を実行したりできるようになります。

最新のWebアプリケーションでは、エンドユーザー向けの便利な機能が提供されるようになり、URLからリソースを取得する処理が一般的になっています。その結果、SSRFの発生件数が増加しています。また、APIやクラウドサービスの普及に加え、コンピューティングアーキテクチャの分散化と複雑化が進むにつれて、SSRFの深刻度も高まっています。

SSRFは、広く認知されている最も重大なWebアプリケーションセキュリティリスクの一覧である「OWASP Top 10 Application Security Risks」の1つです。また、SSRFは、OWASP Top Tenのセキュリティリスクのうち、アプリとAPIの両方に共通するものの1つでもあり、セキュリティソリューションを実装する際には特に考慮する必要があります。

SSRF攻撃の仕組みは次のとおりです。

• アプリケーションでは、ユーザー入力によってサーバー側リクエストの送信先URLまたはリソースを指定できます。この入力は、URL内のパラメーター、フォームフィールドへのユーザー入力、その他のデータソースから取得される場合があります。
• 攻撃者は、特別に細工したリクエストを送信し、アクセスまたは悪用しようとするリソースを指すように入力を操作します。このリソースには、内部サーバー、バックエンドサービス、API、またはファイアウォールの内側にあり外部ネットワークからアクセスできないその他の内部システムなどが考えられます。
• サーバーはユーザーからの悪意のある入力を処理し、指定されたURLへのリクエストを生成します。このリクエストはユーザーのブラウザではなくサーバーから送信されるため、サーバーサイドリクエストとなります。
• 標的のサーバーが内部ネットワーク内にある場合、攻撃者は内部リソースにアクセスして機密情報を取得し、そのデータを攻撃者が管理する外部の場所へ流出させようとする可能性があります。また、SSRFは内部システムのポートスキャンにも使用でき、攻撃者が潜在的な弱点や脆弱性を特定するのに役立ちます。
• SSRF攻撃は、インスタンスが機密性の高いメタデータサービスにアクセスできる可能性があるクラウド環境では、特に懸念されます。
• SSRF攻撃は、機密データやサービスへの不正アクセス、内部システムの悪用、さらにはクラウド環境全体の侵害に至るまで、深刻な影響を及ぼす可能性があります。

SSRF攻撃の例

実際にSSRF攻撃がどのように行われるのかを見てみましょう。

処理対象の画像をユーザーがアップロードでき、処理したい画像のURLを指定する機能を備えた、セキュリティ対策が不十分なWebアプリケーションを想像してください。攻撃者は正規の画像URLを指定する代わりに、内部ファイルやバックエンドデータベースなど、アプリケーションサーバー上の内部リソースを指す悪意のあるURLを含む、巧妙に細工した入力を送信します。アプリケーションサーバーはその悪意のあるURLを無条件に処理し、攻撃者の入力に従ってURLで指定された内部リソースにリクエストを送信します。これにより、機密データを取得したり、データベースにクエリを実行したりして、そのデータを攻撃者に返します。

サーバーが侵害されると、攻撃者は外部システムへのリクエスト送信、脆弱性の探索、またはサーバーがアクセス可能なサービスとの通信も行えるようになります。SSRF攻撃の影響は、システムのアーキテクチャや、侵害されたサーバーに付与されている権限によって異なります。攻撃により、データへの不正アクセス、サービスの中断、内部システムの侵害につながる可能性があります。

SSRF攻撃の3つの基本タイプ

SSRF攻撃は、攻撃者がサーバーとやり取りして情報を抽出する方法に基づいて、複数のタイプに分類できます。

標準的なSSRF攻撃

標準的なSSRF攻撃では、攻撃者がユーザー入力の一部として悪意のあるURLを挿入し、指定したリソースへのリクエストをサーバーに送信させます。攻撃者はサーバーからのレスポンスを直接確認し、データの取得方法やアクセス可能なサービスの特定など、内部ネットワークに関する情報を収集できます。

ブラインドSSRF攻撃

ブラインドSSRF攻撃では、攻撃者はサーバーからのレスポンスを直接受信しません。代わりに、アプリケーションの動作の変化を観察することで、SSRF攻撃の成否を間接的に確認します。

攻撃者は細工した入力を送信し、サーバーに外部または内部のリソースへのリクエストを強制的に実行させます。次に、エラーメッセージや応答時間の違い、その他の副作用など、アプリケーションの動作に現れる観測可能な変化を探します。攻撃者は応答を直接確認できなくても、こうした情報からSSRFが成功したかどうかを推測できます。

時間ベースのブラインドSSRF攻撃

時間ベースのブラインドSSRF攻撃では、サーバーの応答遅延を悪用し、応答を直接確認することなくSSRFの成否を推測します。

他のSSRF攻撃と同様に、攻撃者は悪意のある入力を送信し、サーバーから外部または内部のリソースへのリクエストを発生させます。攻撃者は、アプリケーションが応答するまでの時間を観察します。応答時間の遅延は、SSRFが成功した可能性を示します。攻撃者はペイロードを繰り返し調整しながら遅延時間を監視し、内部ネットワークやリソースに関する情報を抽出します。

SSRF攻撃から保護する方法

SSRF攻撃から保護するには、以下を含む複数の予防的なサイバーセキュリティ対策を組み合わせて実施します。

• 入力検証。ユーザーが入力したデータを厳格に検証し、サニタイズします。特に、アプリケーションが外部リソースにリクエストを送信する場合は徹底してください。URLの許可リストを実装し、アプリケーションがアクセスする必要のある信頼済みドメインまたは特定のURLのみを許可します。httpやhttpsなど、想定されるプロトコルのみが許可されていることを確認し、SSRF攻撃で悪用されることの多いfile://やftp://など、潜在的にリスクのあるプロトコルは許可しないでください。また、ユーザーが指定したURLが想定されるパターンや形式に準拠していることを検証し、悪意のあるURLが挿入される可能性を低減します。
• ホストとIPアドレスの許可リスト。アプリケーションによる通信が許可されているホストとIPアドレスの許可リストを管理します。これにより、リクエスト先を信頼できる意図した宛先に限定し、SSRFの攻撃対象領域を縮小できます。
• 内部リソースへのアクセスを制限する。内部リソースの露出を抑えるため、ネットワークセグメンテーションを実装します。外部公開サーバーから内部システムやサービスへのアクセスは、必要最小限に抑えてください。アプリケーションサーバーからの外部接続を制限するため、Webアプリケーションファイアウォール（WAF）とアクセス制御を設定します。必要かつ事前定義された接続のみを許可し、不要な外向きトラフィックをブロックしてください。アプリケーションと外部リソースの仲介役として、リバースプロキシを導入します。アプリケーションがアクセスできる外部リソースを制御するようプロキシを設定し、制御レイヤーを追加します。

これらの予防策は、SSRF攻撃の防止にどのように役立つのでしょうか。仮想的なシナリオで見てみましょう。

オンラインコンテンツ管理システムでは、ユーザーがURLを入力し、外部画像を投稿に埋め込むことができます。このシステムは、適切な入力検証を行わずにユーザー指定のURLを処理します。入力検証が不十分であることを把握した攻撃者は、内部APIエンドポイントやデータベースサーバーなどの内部リソースを指す悪意のあるURLを指定し、システムの悪用を試みます。しかし、アプリケーションのセキュリティチームはシステムの入力検証を強化し、受け入れるURLに厳格なルールを適用します。システムは、ユーザーが指定したURLが想定されるパターンに準拠しているかを検証するようになり、チームは外部リソースに対して許可するドメインのホワイトリストを実装します。

攻撃者は、SSRFの脆弱性を悪用するために細工したURLを含む投稿を送信しますが、入力検証によって悪意のあるURLが検出されます。処理中にこのURLが拒否されるため、攻撃者が指定した内部リソースにアプリケーションがリクエストを送信することはありません。強化された入力検証によってSSRF攻撃が阻止され、内部リソースへの不正なリクエストが防止されるため、内部システムの完全性とセキュリティが維持されます。

入力検証を実装することで、アプリケーションは悪意のある入力を拒否または無害化し、不正なリクエストを防止して、SSRF攻撃のリスクを軽減できます。

F5が支援できること

SSRF攻撃は、攻撃者がファイアウォールやアクセス制御などの従来のネットワークセキュリティ対策を回避し、通常は組織の内部ネットワーク内で保護され、インターネットから直接アクセスされることを想定していない機密情報やリソースにアクセスできるようにするため、危険です。SSRF攻撃はデータとシステムの両方の機密性、完全性、可用性に重大なリスクをもたらすため、組織はSSRF脆弱性の脅威を軽減し、悪用の可能性から保護するために、WAF、適切な入力検証、アクセス制御、ネットワークセグメンテーションなど、堅牢なセキュリティ対策とベストプラクティスを実施する必要があります。

F5 WAFソリューションは、SSRFを含むOWASP Top 10に起因する幅広いリスクをブロックし、軽減します。F5 WAFソリューションは、シグネチャベースおよび振る舞いベースの保護に加え、F5 Labsの脅威インテリジェンスと機械学習（ML）によるセキュリティの自動化を組み合わせ、進化する脅威に対応します。クラウド、オンプレミス、エッジ環境全体でアプリケーションを一貫して保護する際の負担と複雑さを軽減し、複数の導入オプションから選択できます。BIG-IP Advanced WAFは、アプリケーションをSSRF攻撃から保護し、ソフトウェアの脆弱性に対する重要な暫定対策となる堅牢なソリューションです。一方、F5 Distributed Cloud WAFは、使いやすいas-a-Service型セキュリティプラットフォームを通じて運用を大幅に簡素化し、あらゆる場所のアプリケーションを保護します。

F5 Web Application and API Protection (WAAP)ソリューションは、WAF、APIセキュリティ、L3～L7のDDoS緩和、悪意のある自動化や自動化された脅威に対するボット防御など、包括的な保護機能により、最新アプリケーションの攻撃対象領域全体を防御します。分散型プラットフォームにより、アプリケーションとAPIの環境全体で、ホスティング先を問わず一貫したポリシーを容易に導入し、セキュリティを拡張できます。また、APIライフサイクルやより広範なエコシステムにセキュリティを統合できます。