サーバサイド・リクエストフォージェリ

サーバサイド・リクエストフォージェリ（SSRF）は、ウェブアプリケーションがユーザーからの入力（URLなど）に基づいて、サーバ側で外部リソースへのリクエストを動的に生成する機能に存在する。例えば、URLのプレビュー機能や、指定されたURLからデータをインポートする機能などがこれに該当する^[2]。開発者が外部ネットワークへのアクセスのみを想定し、内部ネットワークのプライベートIPアドレスなど、意図しない宛先へのリクエストを厳格に制限していない場合にSSRFの脆弱性が生まれる。

攻撃者はこの不備を利用し、公開サーバを踏み台として、通常は直接アクセスできない内部の非公開サーバ（データベース、社内システムなど）に対してリクエストを送信させる。これにより、組織のファイアウォールを迂回して、内部リソースに到達することができる。機密情報の窃取、内部サービスの不正利用、さらなる攻撃の足がかりといった深刻な被害につながる可能性がある^[3]。さらに、SSRFは、内部システムのポートスキャンにも利用され、攻撃者がさらなる攻撃を仕掛けるための潜在的な弱点や脆弱性を特定にも悪用される^[4]。

この攻撃の特に危険な点は、内部ネットワークにおいてサーバ間の通信は信頼されていることが多く、ファイアウォールなどの境界防御を容易に迂回してしまうことにある^[3]。SSRFは、こうしたシステム設計におけるサーバ間の「暗黙の信頼関係」を悪用する攻撃といえる。システム全体を俯瞰し、内部のサーバ間でも通信の必要性を最小限に抑え、必要な通信には厳格なアクセス制御を適用する「ゼロトラスト・セキュリティモデル」の考え方が、SSRF対策において重要であると認識されている。

SSRFは、しばしばクロスサイト・リクエストフォージェリ (CSRF) と比較される。両者は正規の第三者（エンティティ）を介してリクエストを偽造（フォージェリ）する点で共通しているが、攻撃の主体と悪用する権限が根本的に異なる^[2]。CSRFが正規ユーザー（クライアント）の認証情報を悪用して意図しない操作を実行させるクライアントサイドの攻撃であるのに対し、SSRFは正規サーバが持つアクセス権限を悪用して内部システムなどに不正なリクエストを送信させるサーバサイドの攻撃である。

SSRFは、ウェブアプリケーションがユーザーからの入力を受け付け、その入力によってサーバ側のリクエストのターゲットURLやリソースが動的に決定される場合に発生する^[4]。この入力は、URLのパラメータ、フォームフィールド、あるいはその他のデータソースから取得される可能性がある^[4]。例えば、画像取得APIやファイルダウンロード機能、URLプレビュー機能などが、SSRFの攻撃ベクトルとなりやすい機能である。これらの機能が、外部からの入力値を厳格に検証せずにそのままリクエストの送信先として使用すると、攻撃者はこの入力値を操作して、悪意のあるリクエストを内部サーバに送信させることが可能となる。

SSRF攻撃は、悪意のあるリクエストをサーバに送信させるために、様々な手法が用いられる。

• URLスキーマ（`file://`、`gopher://`、`dict://`など）の悪用
  • `file://`スキーマを利用することで、サーバのローカルファイルシステムにアクセスを試みることができる。これにより、`file:///etc/passwd`のような機密性の高いシステム設定ファイルの内容を窃取される可能性がある^[5]。
  • `dict://`や`gopher://`といったスキーマを利用すると、FTPやSMTPなどのサービスポートに直接リクエストを送信することも可能となり、より深刻な攻撃の起点となり得る^[5]。

• リダイレクト機能の悪用
  • 攻撃者は、正規の外部URLが設定されているウェブアプリケーションに対して、リダイレクトを利用して内部ネットワークへのアクセスを試みる手法も用いる^[6]。 例えば、公開サーバにリクエストされたURLが内部ネットワークのアドレスにリダイレクトされるように細工することで、間接的に内部リソースにアクセスする。

• DNSリバインディングを利用した内部ネットワーク探索
  • DNSリバインディングは、DNSサーバの応答を悪用して、ウェブブラウザが外部サーバにアクセスした後、同じドメイン名で内部ネットワークのアドレスに再接続するように仕向ける攻撃である^[6]。 これにより、攻撃者は外部からのアクセス制御を回避し、内部ネットワークを探索することが可能になる。

SSRF攻撃は、攻撃者がサーバからの応答をどのように利用するかによって、いくつかのタイプに分類される^[4]。

• 標準的なSSRF攻撃
  • このタイプの攻撃では、サーバからのリクエストに対する応答が攻撃者に直接返される^[4]。

• ブラインドSSRF攻撃
  • ブラインドSSRFでは、攻撃者はサーバからの応答を直接受信しない^[4]。代わりに、アプリケーションの動作の変化（応答時間の違い、エラーメッセージ、その他の副作用）を間接的に観察することで、攻撃の成否を推測する^[4]。

• タイム・ベースドブラインドSSRF
  • これはブラインドSSRFの一種で、特定の動作（例えば、無効なポートへの接続）が引き起こす応答時間の遅延を利用して、内部のサービスやポートの存在を推測する手法である^[4]。

2019年7月、米金融大手Capital Oneは、不正アクセスにより1億人を超える個人情報が流出したと発表した^[2]。この事件の根本原因は、Web Application Firewall (WAF) の設定ミスに起因するSSRF攻撃であった^[2]。攻撃者はこの脆弱性を悪用し、AWS EC2のインスタンスメタデータへの接続に成功^[2]。SSRFを介して窃取されたAWS S3ストレージの認証情報が、顧客データベースへのアクセスと情報窃取に悪用されたことが確認されている^[7]。

2024年1月、Ivantiが提供するリモートアクセス製品に、SAMLコンポーネントに存在するSSRF脆弱性（CVE-2024-21893）が発見され、JPCERTコーディネーションセンター (JPCERT/CC) が注意喚起を行った^[8][9]。この脆弱性は、認証を必要とせずに特定の制限されたリソースへのアクセスを可能にするものであり、CVSS v3スコアで9.1を記録した脆弱性も報告されている^[10]。この脆弱性は、公開される前からゼロデイ攻撃としてすでに悪用されていたことが確認されている^[9]。JPCERT/CCは、本脆弱性を悪用したとみられる攻撃が国内組織に対しても行われた可能性があることを確認し、注意を促している^[8]。