サーバサイド・リクエストフォージェリ(別名:サーバ側リクエスト偽造攻撃、、略称:SSRF)は、ウェブアプリケーションの脆弱性を悪用し、攻撃者が指定した不正なリクエストをサーバ自身に送信させることで、通常は外部に公開されていないサーバ上の処理を実行させる攻撃手法である。この攻撃は、ユーザーのブラウザを介するのではなく、攻撃者が公開サーバに悪意のある入力を送ることで、公開サーバをプロキシ(踏み台)として機能させ、内部ネットワークのリソースにアクセスするように仕向ける。
概要 サーバサイド・リクエストフォージェリ(SSRF)は、ウェブアプリケーションがユーザーからの入力(URLなど)に基づいて、サーバ側で外部リソースへのリクエストを動的に生成する機能に存在する。例えば、URLのプレビュー機能や、指定されたURLからデータをインポートする機能などがこれに該当する。開発者が外部ネットワークへのアクセスのみを想定し、内部ネットワークのプライベートIPアドレスなど、意図しない宛先へのリクエストを厳格に制限していない場合にSSRFの脆弱性が生まれる。
攻撃者はこの不備を利用し、公開サーバを踏み台として、通常は直接アクセスできない内部の非公開サーバ(データベース、社内システムなど)に対してリクエストを送信させる。これにより、組織のファイアウォールを迂回して、内部リソースに到達することができる。機密情報の窃取、内部サービスの不正利用、さらなる攻撃の足がかりといった深刻な被害につながる可能性がある。さらに、SSRFは、内部システムのポートスキャンにも利用され、攻撃者がさらなる攻撃を仕掛けるための潜在的な弱点や脆弱性を特定にも悪用される。
この攻撃の特に危険な点は、内部ネットワークにおいてサーバ間の通信は信頼されていることが多く、ファイアウォールなどの境界防御を容易に迂回してしまうことにある。SSRFは、こうしたシステム設計におけるサーバ間の「暗黙の信頼関係」を悪用する攻撃といえる。システム全体を俯瞰し、内部のサーバ間でも通信の必要性を最小限に抑え、必要な通信には厳格なアクセス制御を適用する「ゼロトラスト・セキュリティモデル」の考え方が、SSRF対策において重要であると認識されている。
SSRFは、しばしばクロスサイト・リクエストフォージェリ (CSRF) と比較される。両者は正規の第三者(エンティティ)を介してリクエストを偽造(フォージェリ)する点で共通しているが、攻撃の主体と悪用する権限が根本的に異なる。CSRFが正規ユーザー(クライアント)の認証情報を悪用して意図しない操作を実行させるクライアントサイドの攻撃であるのに対し、SSRFは正規サーバが持つアクセス権限を悪用して内部システムなどに不正なリクエストを送信させるサーバサイドの攻撃である。
攻撃の詳細なメカニズム SSRFは、ウェブアプリケーションがユーザーからの入力を受け付け、その入力によってサーバ側のリクエストのターゲットURLやリソースが動的に決定される場合に発生する。この入力は、URLのパラメータ、フォームフィールド、あるいはその他のデータソースから取得される可能性がある。例えば、画像取得APIやファイルダウンロード機能、URLプレビュー機能などが、SSRFの攻撃ベクトルとなりやすい機能である。これらの機能が、外部からの入力値を厳格に検証せずにそのままリクエストの送信先として使用すると、攻撃者はこの入力値を操作して、悪意のあるリクエストを内部サーバに送信させることが可能となる。 サムネイル|SSRFのフロー図
代表的な攻撃手法 SSRF攻撃は、悪意のあるリクエストをサーバに送信させるために、様々な手法が用いられる。
URLスキーマ(`file://`、`gopher://`、`dict://`など)の悪用 `file://`スキーマを利用することで、サーバのローカルファイルシステムにアクセスを試みることができる。これにより、`file:///etc/passwd`のような機密性の高いシステム設定ファイルの内容を窃取される可能性がある。 `dict://`や`gopher://`といったスキーマを利用すると、FTPやSMTPなどのサービスポートに直接リクエストを送信することも可能となり、より深刻な攻撃の起点となり得る。
リダイレクト機能の悪用 攻撃者は、正規の外部URLが設定されているウェブアプリケーションに対して、リダイレクトを利用して内部ネットワークへのアクセスを試みる手法も用いる。 例えば、公開サーバにリクエストされたURLが内部ネットワークのアドレスにリダイレクトされるように細工することで、間接的に内部リソースにアクセスする。
DNSリバインディングを利用した内部ネットワーク探索 DNSリバインディングは、DNSサーバの応答を悪用して、ウェブブラウザが外部サーバにアクセスした後、同じドメイン名で内部ネットワークのアドレスに再接続するように仕向ける攻撃である。 これにより、攻撃者は外部からのアクセス制御を回避し、内部ネットワークを探索することが可能になる。
クラウドメタデータサービス(IMDS)の悪用 外部画像URLの読み込み機能やWebhook送信機能などを悪用し、クラウド環境の内部メタデータエンドポイント(例: AWSの `http://169.254.169.254/latest/meta-data/`)にリクエストを送信させる手法。サーバに割り当てられたIAMロールのアクセスキーやセッショントークンなどのクレデンシャルを窃取される危険がある。攻撃者にこれらの認証情報を悪用された場合、オブジェクトストレージ内の重要データ閲覧や権限昇格など、クラウドアカウント全体の侵害へ繋がる。
SSRF攻撃の類型 SSRF攻撃は、攻撃者がサーバからの応答をどのように利用するかによって、いくつかのタイプに分類される。
標準的なSSRF攻撃 このタイプの攻撃では、サーバからのリクエストに対する応答が攻撃者に直接返される。
ブラインドSSRF攻撃 ブラインドSSRFでは、攻撃者はサーバからの応答を直接受信しない。代わりに、アプリケーションの動作の変化(応答時間の違い、エラーメッセージ、その他の副作用)を間接的に観察することで、攻撃の成否を推測する。
タイム・ベースドブラインドSSRF これはブラインドSSRFの一種で、特定の動作(例えば、無効なポートへの接続)が引き起こす応答時間の遅延を利用して、内部のサービスやポートの存在を推測する手法である。
SSRF攻撃の事例
Capital One情報漏洩事件(2019年) 2019年7月、米金融大手Capital Oneは、不正アクセスにより1億人を超える個人情報が流出したと発表した。この事件の根本原因は、Web Application Firewall (WAF) の設定ミスに起因するSSRF攻撃であった。攻撃者はこの脆弱性を悪用し、AWS EC2のインスタンスメタデータへの接続に成功。SSRFを介して窃取されたAWS S3ストレージの認証情報が、顧客データベースへのアクセスと情報窃取に悪用されたことが確認されている。
Ivanti Connect Secureのゼロデイ脆弱性 2024年1月、Ivantiが提供するリモートアクセス製品に、SAMLコンポーネントに存在するSSRF脆弱性(CVE-2024-21893)が発見され、JPCERTコーディネーションセンター (JPCERT/CC) が注意喚起を行った。この脆弱性は、認証を必要とせずに特定の制限されたリソースへのアクセスを可能にするものであり、CVSS v3スコアで9.1を記録した脆弱性も報告されている。この脆弱性は、公開される前からゼロデイ攻撃としてすでに悪用されていたことが確認されている。JPCERT/CCは、本脆弱性を悪用したとみられる攻撃が国内組織に対しても行われた可能性があることを確認し、注意を促している。
SSRF脆弱性の検出と対策
脆弱性診断ツールの活用 Webアプリケーション診断では、SSRFを検出する機能を備えた自動化されたツールが一般的に使用されている。しかし、自動診断ツールだけではすべての脆弱性を網羅的に検出することは難しく、特にビジネスロジックに潜む複雑な脆弱性や、後述するブラインドSSRFのような特殊なケースは、専門家による手動診断やペネトレーションテストによって補完する必要がある。
OAST(Out-of-band Application Security Testing) ブラインドSSRFについては、サーバからの応答が攻撃者に直接返されないため、通常の診断方法では検出が困難である。このタイプの脆弱性を特定するためには、OAST(Out-of-band Application Security Testing)技術が有効である。
OASTでは、対象となるWebアプリケーションに対し診断用のエクスプロイトを仕掛ける。Webアプリケーションから外部(アウトオブバンド)への通信を試行させる。あらかじめ用意した外部サーバでは、対象アプリケーションからの通信があったかどうかを記録し、エクスプロイトが有効か、脆弱性が存在するかを確認する。
アローリスト(Allowlist)の導入 SSRF対策の最も堅牢な方法は、リクエストの送信先を厳格に制限する「アローリスト(許可リスト)方式」を導入することである。対照的に、悪意のあるURLを一覧化して拒否する「ブラックリスト方式」は、巧妙な回避策によって容易に迂回されるため、効果的な対策とは言えない。
技術的な防御策 厳格な入力検証とサニタイズ: ユーザーからの入力値は、リクエストの送信先として使用する前に、その形式、プロトコル、ドメイン、IPアドレスなどを厳格に検証し、無害化(サニタイズ)する必要がある。 ネットワーク分離とファイアウォールによるアクセス制御: 外部に公開されたサーバと内部の非公開サーバの間で、ネットワークを論理的に分離し、ファイアウォールによって通信を制御することが重要である。特に`localhost` (127.0.0.1) や、クラウド環境のメタデータサービスにアクセスできる特定のIPアドレスに対するリクエストは厳しく制限する。 サービス連携における最小権限の原則: サーバが外部リソースとの連携に必要な権限は、必要最小限に限定する「最小権限の原則」を徹底する。 Web Application Firewall (WAF) の活用と適切な設定: WAFは、SSRF攻撃を検知し、ブロックする有効な手段となり得る。
関連項目
エクスプロイト クロスサイト・リクエストフォージェリ - クライアントの認証情報を悪用して意図しない操作を実行させる
脚注