サーバサイド・リクエストフォージェリ
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2025/09/12 02:43 UTC 版)
サーバサイド・リクエストフォージェリ（別名：サーバー側リクエスト偽造攻撃、英語：Server-Side Request Forgery、略称：SSRF）は、ウェブアプリケーションの脆弱性を悪用し、攻撃者が指定した不正なリクエストをサーバー自身に送信させることで、通常は外部に公開されていないサーバー上の処理を実行させる攻撃手法である[1]。この攻撃は、ユーザーのブラウザを介するのではなく、攻撃者が公開サーバーに悪意のある入力を送ることで、公開サーバーをプロキシ（踏み台）として機能させ、内部ネットワークのリソースにアクセスするように仕向ける[2]。
概要
サーバサイド・リクエストフォージェリ（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://`など）の悪用
- リダイレクト機能の悪用
- 攻撃者は、正規の外部URLが設定されているウェブアプリケーションに対して、リダイレクトを利用して内部ネットワークへのアクセスを試みる手法も用いる[6]。 例えば、公開サーバーにリクエストされたURLが内部ネットワークのアドレスにリダイレクトされるように細工することで、間接的に内部リソースにアクセスする。
- DNSリバインディングを利用した内部ネットワーク探索
- DNSリバインディングは、DNSサーバーの応答を悪用して、ウェブブラウザが外部サーバーにアクセスした後、同じドメイン名で内部ネットワークのアドレスに再接続するように仕向ける攻撃である[6]。 これにより、攻撃者は外部からのアクセス制御を回避し、内部ネットワークを探索することが可能になる。
SSRF攻撃の類型
SSRF攻撃は、攻撃者がサーバーからの応答をどのように利用するかによって、いくつかのタイプに分類される[4]。
- 標準的なSSRF攻撃
- このタイプの攻撃では、サーバーからのリクエストに対する応答が攻撃者に直接返される[4]。
- ブラインドSSRF攻撃
- タイム・ベースドブラインドSSRF
- これはブラインドSSRFの一種で、特定の動作（例えば、無効なポートへの接続）が引き起こす応答時間の遅延を利用して、内部のサービスやポートの存在を推測する手法である[4]。
SSRF攻撃の事例
Capital One情報漏洩事件（2019年）
2019年7月、米金融大手Capital Oneは、不正アクセスにより1億人を超える個人情報が流出したと発表した[2]。この事件の根本原因は、WAF（Web Application Firewall）の設定ミスに起因するSSRF攻撃であった[2]。攻撃者はこの脆弱性を悪用し、AWS EC2のインスタンスメタデータへの接続に成功[2]。SSRFを介して窃取されたAWS S3ストレージの認証情報が、顧客データベースへのアクセスと情報窃取に悪用されたことが確認されている[7]。
Ivanti Connect Secureのゼロデイ脆弱性
2024年1月、Ivantiが提供するリモートアクセス製品に、SAMLコンポーネントに存在するSSRF脆弱性（CVE-2024-21893）が発見され、JPCERT/CCが注意喚起を行った[8][9]。この脆弱性は、認証を必要とせずに特定の制限されたリソースへのアクセスを可能にするものであり、CVSS v3スコアで9.1を記録した脆弱性も報告されている[10]。この脆弱性は、公開される前からゼロデイ攻撃としてすでに悪用されていたことが確認されている[9]。JPCERT/CCは、本脆弱性を悪用したとみられる攻撃が国内組織に対しても行われた可能性があることを確認し、注意を促している[8]。
SSRF脆弱性の検出と対策
脆弱性診断ツールの活用
Webアプリケーション診断では、SSRFを検出する機能を備えた自動化されたツールが一般的に使用されている。しかし、自動診断ツールだけではすべての脆弱性を網羅的に検出することは難しく、特にビジネスロジックに潜む複雑な脆弱性や、後述するブラインドSSRFのような特殊なケースは、専門家による手動診断やペネトレーションテストによって補完する必要がある[11]。
OAST（Out-of-band Application Security Testing）
ブラインドSSRFについては、サーバーからの応答が攻撃者に直接返されないため、通常の診断方法では検出が困難である。このタイプの脆弱性を特定するためには、OAST（Out-of-band Application Security Testing）技術が有効である[12]。
OASTでは、対象となるWebアプリケーションに対し診断用のエクスプロイトを仕掛ける。Webアプリケーションから外部（アウトオブバンド）への通信を試行させる。あらかじめ用意した外部サーバーでは、対象アプリケーションからの通信があったかどうかを記録し、エクスプロイトが有効か、脆弱性が存在するかを確認する。
アローリスト（Allowlist）の導入
SSRF対策の最も堅牢な方法は、リクエストの送信先を厳格に制限する「アローリスト（許可リスト）方式」を導入することである。対照的に、悪意のあるURLを一覧化して拒否する「ブラックリスト方式」は、巧妙な回避策によって容易に迂回されるため、効果的な対策とは言えない[2]。
技術的な防御策
- 厳格な入力検証とサニタイズ: ユーザーからの入力値は、リクエストの送信先として使用する前に、その形式、プロトコル、ドメイン、IPアドレスなどを厳格に検証し、無害化（サニタイズ）する必要がある[4]。
- ネットワーク分離とファイアウォールによるアクセス制御: 外部に公開されたサーバーと内部の非公開サーバーの間で、ネットワークを論理的に分離し、ファイアウォールによって通信を制御することが重要である。特に`localhost`（127.0.0.1）や、クラウド環境のメタデータサービスにアクセスできる特定のIPアドレスに対するリクエストは厳しく制限する[2]。
- サービス連携における最小権限の原則: サーバーが外部リソースとの連携に必要な権限は、必要最小限に限定する「最小権限の原則」を徹底する。
- WAF（Web Application Firewall）の活用と適切な設定: WAFは、SSRF攻撃を検知し、ブロックする有効な手段となり得る[4]。
関連項目
- エクスプロイト
- クロスサイト・リクエストフォージェリ - クライアントの認証情報を悪用して意図しない操作を実行させる
脚注
- ^ “脆弱性コラム - 第15回”. www.techmatrix.co.jp. 2025年9月12日閲覧。
- ^ a b c d e f g h “SSRF攻撃とは？仕組みや被害事例、効果的な対策について徹底解説 - サイバーセキュリティ.com”. cybersecurity-jp.com. 2025年9月12日閲覧。
- ^ a b “非公開サーバーにアクセスされてしまうSSRF脆弱性の問題『OODAセキュリティ』”. www.ooda-security.com. 2025年9月12日閲覧。
- ^ a b c d e f g h i j “サーバーサイドリクエストフォージェリ (SSRF) とは何ですか?”. www.f5.com. 2025年9月12日閲覧。
- ^ a b “SSRF - A10 OWASP Top 10 - Wallarm”. www.wallarm.com. 2025年9月12日閲覧。
- ^ a b “サーバーサイドリクエストフォージェリ(SSRF)攻撃とは？そのリスクと防止策を徹底解説”. cybersecurity-jp.com. 2025年9月12日閲覧。
- ^ “SSRF攻撃により1億件以上の情報漏洩となったCapital One事件はどうして起こったか?”. www.youtube.com. 2025年9月12日閲覧。
- ^ a b “Ivanti Connect SecureおよびIvanti Policy Secureの脆弱性（CVE-2023-46805およびCVE-2024-21887）に関する注意喚起 - JPCERT コーディネーションセンター”. www.jpcert.or.jp. 2025年9月12日閲覧。
- ^ a b “Critical Vulnerabilities in Ivanti Exploited In-The-Wild”. www.wiz.io. 2025年9月12日閲覧。
- ^ “「Vex」 バージョン11.3.0.0リリース サーバーサイドリクエスト ...”. www.ubsecure.jp. 2025年9月12日閲覧。
- ^ “脆弱性診断導入ガイドラインの内容からサービス選定まで解説『OODAセキュリティ』”. www.ooda-security.com. 2025年9月12日閲覧。
- ^ “Blind SSRFの発見と攻撃手法 - Shikata Ga Nai”. cysec148.hatenablog.com. 2025年9月12日閲覧。
- サーバサイド・リクエストフォージェリのページへのリンク
