SSRFは、サービスのサーバーに、意図しない場所へアクセスさせる攻撃です。攻撃者の端末からは直接届かない情報にも、接続できる範囲の広いサーバーを経由して届く場合があります。
ポイントは「誰が接続するか」です。URLを入力した人と、そのURLへ実際に接続するコンピューターが同じとは限りません。
SSRFとはサーバー側から意図しない場所へ接続させること
SSRFは、Server-Side Request Forgeryの略です。日本語では「サーバーサイドリクエストフォージェリ」と呼ばれます。長い名前ですが、まずは「サーバーに別の場所への通信をさせる」と捉えると理解しやすくなります。
Webサービスには、入力されたURLから画像や資料を取り込む機能があります。このとき、利用者が自分でファイルを取りに行く方式もあれば、サービスのサーバーが取りに行く方式もあります。
後者では、利用者の入力が、サーバーの接続先を決める材料になります。そこで許可する接続先の確認が足りないと、本来の目的から外れた通信に使われるおそれがあります。
URLを受け取る機能が、全部危険なわけではない
他のサービスから情報を取得すること自体は、普通に使われる機能です。問題になるのは、どこへ接続してよいかを制限せず、入力によって意図しない場所へ接続できてしまう場合です。
Webサーバーは、ページを返すだけでなく、別のコンピューターへ情報を取りに行くこともあります。その「取りに行く側」の働きが悪用される、と考えてみてください。
外部の端末から、サービスへ取り込みを依頼する
許可の確認が不足すると、意図しない先へ向かう
外部の端末から直接は届かない情報や機能が対象になる
サーバーから内部へ接続できる場合の模式図です。実際の影響は接続先の権限や結果の扱いでも変わります。
SSRFとCSRFは、通信に使われる側が違う
似た略語のCSRFでは、主に利用者のブラウザが、本人の意図しない要求を送ることが問題になります。SSRFでは、サービスのサーバーが通信を送る側です。
| 言葉 | 意図しない通信を送る側 | 注目する点 |
|---|---|---|
| SSRF | サービスのサーバー | サーバーがどこへ接続できるか |
| CSRF | 利用者のブラウザ | その操作が本人の意図したものか |
名前を丸暗記するより、ニュースの図や説明で「この矢印はどの機械から出ているか」を見ると、混同しにくくなります。
SSRFで外から見えない場所に届くのはなぜ？
同じURLでも、外部の端末と、サービスを動かすサーバーでは、接続できる範囲が違う場合があります。社内向けの情報や、サービスの管理用の仕組みは、外から直接使えないようにしていることがあるためです。
ところが、公開サービスのサーバーからは、業務のためにそれらへ接続できることがあります。SSRFが起きると、その経路を意図しない用途へ使われる可能性が生まれます。
MDNのSSRF解説も、外部から直接届かない資源へ、より広い接続範囲を持つサーバーから要求を送れる点を説明しています。MDNのSSRF解説
内側へ届くことと、すべての情報を盗めることは別
サーバーから接続できても、接続先が権限を確かめていれば、自由に情報を読めるとは限りません。また、取得した結果が攻撃者へ返るかどうかでも影響は変わります。
考えるべきなのは、接続できる範囲、接続先で許される操作、返された情報の扱いです。条件がそろえば情報の流出や不正な操作につながりますが、「SSRFがある＝全データが盗まれた」とは言えません。
反対に、結果を画面へ表示しないから安全とも限りません。不要な要求を送って処理を妨げたり、応答の違いから内部の状態を推測されたりする場合もあります。
APIという、ソフトウェア同士で情報や機能をやり取りする窓口も、接続先になり得ます。外から直接見えない窓口であっても、接続した相手に何を許すかの確認は必要です。
SSRF対策は接続先と権限を制限する
SSRFの主な対策は、サービスを作る・運営する側が行います。利用者のパスワードを長くするだけで、サーバーの接続先の問題が直るわけではありません。
運営側では、必要な相手にだけ接続できるようにすることが基本です。OWASPの指針は、接続先を決められる場合と、幅広い外部サイトを扱う場合を分け、アプリケーションと通信経路の両方で守る考え方を示しています。OWASPのSSRF対策指針
| 対策の考え方 | 防ぎたいこと |
|---|---|
| 必要な接続先を決め、許可する範囲を絞る | 入力次第で任意の場所へ接続されること |
| 転送先や実際の接続先も確認する | 最初に確認した場所から、別の場所へ移されること |
| 不要な内部通信を制限する | 一つの機能から重要な内部サービスへ広く届くこと |
| 接続先でも権限を確かめる | 内部から来たというだけで重要な操作を許すこと |
ここでいう「転送」は、アクセスした先から別の行き先へ案内されることです。最初のURLだけを調べても、その先で行き先が変わる場合があります。URLがHTTPSで始まるかを見るだけでは、接続してよい相手かの確認を代わりにはできません。
幅広いURLを扱うサービスでは、接続先を少数の一覧にするだけでは機能が成り立たないこともあります。その場合も、不要な内部接続を防ぎ、機能を他の重要な処理から分けるなど、用途に合う設計が必要です。
サービスの利用者が、ニュースで確かめること
SSRFの発表を見たら、まず自分が使うサービスや機能が対象か、提供元の案内で確認します。「対策済み」と「情報への影響を調査済み」は同じではないため、利用者向けに何が分かっているかも読みます。
自分で内部のURLを入力して、問題があるか試す必要はありません。運営側の修正が必要な問題なのか、利用者にも変更が求められているのかを分ければ、次の行動を選びやすくなります。
SSRFという言葉を見かけたら、接続するのは誰の機械で、その機械はどこまで届くのか。この二点に注目すると、長い専門用語が具体的な仕組みとして見えてきます。安全上の弱点という言葉自体は、脆弱性とは何かで説明しています。
