SSRF とは何ですか?

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

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

最近の Web アプリケーションはエンドユーザーに便利な機能を提供するため、URL の取得は一般的なシナリオになっています。 その結果、SSRFの発生率が増加しています。 また、API やクラウド サービスが普及し、コンピューティング アーキテクチャがより分散化され複雑になるにつれて、SSRF の深刻度も増大します。

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

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

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

SSRF 攻撃が現実世界でどのように発生するかを説明します。

ユーザーが処理する画像をアップロードでき、処理したい画像の URL をユーザーが提供できる機能を備えた、セキュリティ保護されていない Web アプリケーションを想像してください。 ただし、攻撃者は正当な画像 URL を提供する代わりに、内部ファイルやバックエンド データベースなどのアプリケーション サーバー上の内部リソースを指す悪意のある URL を含む、巧妙に作成された入力を送信します。 アプリケーション サーバーは悪意のある URL を盲目的に処理し、攻撃者の入力に従って、URL で指定された内部リソースに要求を送信して機密データを取得したり、データベースを照会してデータを攻撃者に返したりします。

サーバーが侵害されると、攻撃者は外部システムにリクエストを送信したり、脆弱性を調査したり、サーバーがアクセスできるサービスとやり取りしたりすることもできます。 SSRF 攻撃の影響は、システムのアーキテクチャと侵害されたサーバーの権限によって異なります。 攻撃により、不正なデータアクセス、サービスの中断、内部システムの侵害が発生する可能性があります。

SSRF 攻撃は、攻撃者がサーバーと対話して情報を抽出する方法に基づいて、さまざまなタイプに分類できます。

標準的な SSRF 攻撃では、攻撃者はユーザー入力の一部として悪意のある URL を挿入し、サーバーが指定されたリソースへのリクエストを行うようにトリガーします。 攻撃者はサーバーからの応答を直接観察し、データの取得方法やアクセス可能なサービスの識別方法など、内部ネットワークに関する情報を収集できます。

ブラインド 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 攻撃のリスクを軽減できます。

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

F5 WAF ソリューションは、 SSRF を含むOWASP Top 10に起因する幅広いリスクをブロックし、軽減します。 F5 WAF ソリューションは、 F5 Labsの脅威インテリジェンスや機械学習 (ML) による自動化されたセキュリティなど、シグネチャと動作に基づく保護を組み合わせて、新たな脅威に対応します。 クラウド、オンプレミス、エッジ環境全体でアプリケーションを一貫して保護するための負担と複雑さを軽減し、さまざまな展開オプションから選択できます。 BIG-IP Advanced WAF は、アプリケーションを SSRF 攻撃から保護し、ソフトウェアの脆弱性に対する重要な一時しのぎを提供できる堅牢なソリューションです。一方、 F5 Distributed Cloud WAF は、使いやすいサービスとしてのセキュリティ プラットフォームを通じて大幅に簡素化された操作で、あらゆる場所のアプリケーションを保護します。  

F5 Web アプリケーションおよび API 保護 (WAAP) ソリューションは、 WAF、 API セキュリティ、L3-L7 DDoS 軽減、悪意のある自動化や自動化された脅威に対するボット防御などの包括的な保護により、最新のアプリの攻撃対象領域全体を防御します。 分散プラットフォームにより、ホストされている場所に関係なく、一貫したポリシーを簡単に導入し、アプリと API の資産全体にわたってセキュリティを拡張し、API ライフサイクルとより広範なエコシステムにセキュリティを統合できます。