SSRFとは？仕組み・攻撃例・対策をわかりやすく解説！

Webアプリケーションを開発・運用するうえで、セキュリティ対策は欠かせない要素です。その中でも、危険な攻撃手法のひとつがSSRF（サーバーサイドリクエストフォージェリ）です。

SSRFへの対策が不十分な場合、攻撃者に社内ネットワーク内の「内部サーバー」や「メタデータ情報」など、本来アクセスできないリソースへの不正アクセスを許してしまう可能性があります。たとえば、クラウド環境のメタデータAPIにアクセスされ、認証情報が盗まれるなど、重大な被害につながることもあります。

この記事では『SSRF』について、以下の内容を図や具体例を用いて、初心者の方にもわかりやすく解説していきます。

SSRFとは？
SSRFの仕組み
SSRFの対策
SSRFとCSRFの違い

SSRFとは？

SSRF（Server-Side Request Forgery／サーバーサイドリクエストフォージェリ）は、外部から直接アクセスできない「内部サーバー」に対して、「公開サーバー」を経由して不正にアクセスする攻撃です。

たとえば、攻撃者はインターネットから「公開サーバー（外部公開されているWebサーバーなど）」にはアクセスできますが、「内部サーバー（社内ネットワーク内のサーバーなど）」には直接アクセスできません。

しかし、公開サーバーが内部サーバーにリクエストを送れる構成だった場合、攻撃者はその仕組みを悪用して、公開サーバーを経由して内部サーバーにリクエストを送らせることができます。

その結果、本来アクセスできないはずの内部サーバーの情報を取得したり、コマンドを実行させたりすることが可能になります。これがSSRF攻撃の仕組みです。

公開サーバーと内部サーバーについて

公開サーバー
- 外部（インターネット）からアクセスできるWebアプリケーション
  - 例 ↓
  - https://example.com
内部サーバー
- 社内ネットワーク内など、外部（インターネット）から直接アクセスできないシステム
  - 例 ↓
  - http://127.0.0.1（ローカルホスト）
  - 社内のデータベース（DB）
  - クラウド環境のメタデータなど

SSRFの仕組み

上の図は、SSRF攻撃がどのように行われるかを示したものです。ここからは、その流れをステップごとに詳しく説明していきます。

ステップ1：攻撃者が悪意のあるリクエストを公開サーバーに送る

たとえば、あるWebサービスに「URLプレビュー機能」があるとします。ユーザーが送ったURLの内容を、公開サーバーが取得して、タイトルや画像を表示する仕組みです。ここに目をつけた攻撃者は、次のような「悪意のあるリクエスト」を送信します。

POST /fetch
{
  "url": "http://192.168.0.10:8000/admin"
}

このURL（http://192.168.0.10:8000/admin）は、社内ネットワークの中にある「内部サーバー」を指しています。つまり、攻撃者の自宅など外部のネットワークからはアクセスできない場所です。外部からは普通アクセスできない場所ですが、Webサービスの公開サーバーからはアクセスできてしまう場合があります。

ステップ2：公開サーバーが内部サーバーにリクエストを送ってしまう

Webサービス側の公開サーバーが、ユーザーから送られたURLをそのまま信用してアクセスしてしまうと、公開サーバー自身が、社内ネットワーク内の「内部サーバー」へリクエストを送ってしまいます。

この結果、攻撃者は本来見られないはずの情報を入手されてしまう可能性があります。

社内用の管理画面（例：http://192.168.0.10:8000/admin）
社内専用のAPIサーバー（例：http://10.0.0.1/api/）
クラウドのメタデータ情報（例：AWS のhttp://169.254.169.254/）

もしレスポンス内容（たとえば管理画面のHTMLや機密情報）がそのまま攻撃者に返ってきてしまうと、攻撃者は自分ではアクセスできない情報を盗み見できてしまうのです。

SSRFの対策

SSRF攻撃に対する対策を以下にまとめます。

対策①：外部リクエストの実行を極力避ける

まず基本として、「ユーザーが入力したURLに対して、サーバーが直接アクセスするような機能」は原則避けることが第一です。

たとえば、「URLプレビュー機能」や「画像URLから画像を取得する処理」などがこれに該当します。このような処理があると、攻撃者が内部サーバーにアクセスするきっかけになります。

どうしても実装が必要な場合は、次のような追加対策を組み合わせて使いましょう。

対策②：URLのチェック（フィルタリング・検証）

ユーザーが指定したURLにアクセスしなければいけない場合は、不正なアクセスを防ぐためのチェックを行いましょう。

具体的には、次のような対策があります。

スキームの確認
- httpやhttps以外（例：file://, ftp://）は拒否
ホスト名のホワイトリスト化
- アクセスを許可するドメイン名を限定（例：example.comだけ許可）
IPアドレスチェック
- ホスト名をIPに変換して、以下のような内部IPアドレスをブロック
- 127.0.0.1（localhost）
- 169.254.0.0/16（リンクローカルアドレス）
- 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12（プライベートIP）

対策③：ファイアウォールやACL（アクセス制御）で守る

アプリケーション側の対策に加えて、ネットワークレベルでアクセスを制限するとより安全です。

VPC・セキュリティグループの設定
- Webサーバーから、社内サーバーやメタデータサービス（例：169.254.169.254）にアクセスできないように設定
外部アクセスが不要なポートやIPをブロック
- たとえば、内部DBや管理画面へのアクセスは外から一切通さない

SSRFとCSRFの違い

SSRF（サーバーサイドリクエストフォージェリ）とCSRF（クロスサイトリクエストフォージェリ）は、どちらも「リクエストを偽造する攻撃」ですが、攻撃の対象や仕組みが大きく異なります。以下に両者の違いをまとめます。

項目	SSRF	CSRF
略称	Server-Side Request Forgery	Cross-Site Request Forgery
読み方	サーバーサイドリクエストフォージェリ	クロスサイトリクエストフォージェリ
攻撃の目的	内部サーバーあるリソースに不正アクセス	ユーザーになりすまして意図しない操作を実行させる
攻撃の対象	内部サーバー	ログイン中のユーザー
前提条件	公開サーバーが外部から指定されたURLにアクセスする機能を持つ	ユーザーがログイン中でCookieなどの認証情報を持っている
攻撃の手口	公開ユーザーに細工されたURLを入力させ、公開サーバー側が内部サーバーにアクセス	悪意あるWebサイトを通じてユーザーのブラウザから不正なリクエストを送信
代表的な例	公開サーバーが`http://192.168.0.10:8000/admin`にアクセスしてしまう	銀行の送金フォームがユーザーの知らないうちに送信される
被害例	内部APIやメタデータサービスに不正アクセスされる	本人の知らないうちに送金、投稿、購入処理が実行される