LASSIC Media らしくメディア
SSRFとは｜サーバを踏み台にする攻撃と対策
クラウドを活用したシステム開発が広がるなかで、「SSRF（サーバサイドリクエストフォージェリ）の対策はできていますか」「脆弱性診断でSSRFの指摘がありました」といった言葉を耳にする機会が増えています。SSRFは、近年とりわけ注目を集めている攻撃手法で、クラウド環境での大きな情報漏えいの一因としても知られる存在です。IT事業部でシステムの発注や運用に関わる立場であれば、名前は聞いたことがあっても、それが具体的に何を突く攻撃で、なぜ危ないのか、どう防ぐのかまでは説明しにくいかもしれません。とはいえ、その大まかな仕組みを理解しておくと、ベンダーの提案や脆弱性診断の報告を受けたときに、対策が妥当かどうかを判断する助けになるでしょう。本記事では、攻撃コードの書き方といった実践的な手順ではなく、SSRFとはそもそも何を突く攻撃なのか、なぜ起こり、どんな被害につながり、どう防ぐのかを、発注・運用の視点から順に整理します。専門的な用語をすべて覚える必要はありませんが、「サーバが、攻撃者の指定した先へ代わりにアクセスさせられる」という勘所をつかんでおくと、セキュリティの会話が理解しやすくなるはずです。
SSRFとは何か
SSRF（Server-Side Request Forgery、サーバサイドリクエストフォージェリ）とは、攻撃者が、Webサーバをいわば「踏み台」にして、そのサーバから攻撃者の狙った別の場所へリクエスト（通信の要求）を送らせる攻撃です。ポイントは、通信を実際に行うのが攻撃者自身ではなく、攻撃を受けたサーバだという点にあります。サーバが本来持っている権限や、内部ネットワークへの通信経路を、攻撃者が間接的に利用してしまうわけです。
もう少しかみ砕いてみましょう。Webサービスには、利用者が指定したURLの内容を、サーバが代わりに取りにいく機能がしばしばあります。たとえば、指定した画像のURLを読み込んでサムネイルを作る、外部のデータを取り込む、といった処理です。この「サーバが指定された先へ取りにいく」動きを悪用されると、攻撃者は、本来アクセスできないはずの場所のアドレスを指定して、サーバにそこへアクセスさせられます。外部の攻撃者からは直接届かない社内システムや、クラウドの内部的な情報にも、サーバを経由すれば手が届いてしまうのです。
とりわけ問題になりやすいのが、クラウド環境です。クラウドのサーバには、自身の設定や一時的な認証情報を取得するための、内部専用の窓口が用意されていることがあります。SSRFでこの窓口にアクセスされると、サーバがもつ強い権限の認証情報が抜き取られ、大きな被害につながりかねないのです。実際に、SSRFがクラウド上の大規模な情報漏えいの一因になった事例も報告されています。
なぜ起こるのか（攻撃の仕組み）
SSRFが成立してしまう根っこには、「サーバが取りにいく先（宛先）を、利用者からの入力で決めているのに、その宛先が妥当かを確認していない」という問題があります。
先ほどの例のように、URLを受け取ってその内容を取得する機能があると、攻撃者はそのURLの部分に、外部のアドレスではなく、内部のアドレスを紛れ込ませます。サーバは「言われたとおりに取りにいくだけ」なので、それが外部の正当な相手なのか、触れられては困る内部の相手なのかを区別せずにアクセスしてしまうのです。外部の攻撃者は本来、内部のアドレスへ直接アクセスできません。しかし、内部ネットワークに置かれたサーバに「代わりに」アクセスさせれば、その壁を越えられてしまうわけです。次の図は、この流れを単純化して示したものです。
ここで大切なのは、SSRFは「サーバの位置」と「信頼のすきま」を突く攻撃だという点です。内部ネットワークのサーバは、外部よりも信頼されていることが多く、内部同士の通信はゆるやかに許されがちです。その内部にいるサーバを操って通信させることで、外側からは越えられない壁を越えてしまう——この構図を理解しておくと、なぜ対策が「宛先を見張ること」に向かうのかがつかめます。
身近な流れで想像してみましょう。あるサービスに、利用者が入力したURLの画像を読み込んで表示する機能があったとします。通常は外部の画像URLが入力されますが、攻撃者はそこに、外部からは触れられないはずの内部アドレスを紛れ込ませるのです。サービスのサーバは、指定されたとおりにそのアドレスへアクセスし、返ってきた内容を処理してしまう——。利用者向けの何気ない機能が、内部への入り口として悪用されてしまうわけです。なお、取得した内容が画面に表示されない場合でも、応答の有無や時間差から内部の様子を推し量られることがあり、油断はできません。
この記事のポイント
- SSRFは、Webサーバを踏み台にして、攻撃者の狙った先へサーバから通信を送らせる攻撃です。
- 原因は、サーバが取りにいく宛先を利用者の入力で決め、その妥当性を確認していないことにあります。
- クラウドの内部窓口を突かれると認証情報の窃取につながるため、宛先の制限が対策の中心です。
どんな被害につながるのか
SSRFが成立すると、攻撃者は、サーバという「内側にいる存在」を通じて、さまざまな情報や機能に手を伸ばせます。代表的な被害を挙げておきましょう。
一つ目はクラウドの認証情報の窃取です。前述のとおり、クラウドの内部窓口からサーバの認証情報を抜き取られると、攻撃者がその権限で他の資源にアクセスし、被害が一気に広がるおそれがあります。二つ目は内部システムの探索です。外部からは見えない社内のサーバや管理画面へサーバ経由でアクセスされ、内部構成の把握や、さらなる攻撃の足がかりにされることがあります。三つ目は本来非公開の情報の取得です。内部でのみ参照できるはずのデータや設定が、サーバを介して読み取られてしまう場合があります。
共通しているのは、いずれも「外部からは直接届かないはずの領域」に、サーバを踏み台として到達される点です。とりわけクラウドでは、一つの認証情報が広い権限を持つことがあり、被害が連鎖的に拡大しやすくなります。SSRFが近年とくに重視されるのは、クラウドの普及とともに「サーバに取りにいかせる」機能が増え、突かれたときの影響が大きくなっているためだといえるでしょう。
CSRFとの違い
SSRFは、名前が似ているCSRF（クロスサイトリクエストフォージェリ）と混同されがちですが、まったく別の攻撃です。違いを整理しておくと、報告を受けたときに取り違えずに済みます。
| 観点 | SSRF | CSRF |
|---|---|---|
| 通信を送る主体 | サーバ（サーバに送らせる） | 利用者のブラウザ（ブラウザに送らせる） |
| 狙う先 | 内部システムやクラウドの内部窓口 | 利用者がログイン済みの正規サイト |
| 対策の中心 | 取りにいく宛先の制限・確認 | 正規の画面からの要求かの確認（トークン等） |
名前の「フォージェリ（偽造）」が共通するため紛らわしいのですが、SSRFは「サーバに通信させる」、CSRFは「利用者のブラウザに通信させる」と覚えると、区別しやすくなります。狙う先も、SSRFは内部側、CSRFは正規サイト側と対照的です。報告書に両者が出てきたら、まず「どちらが通信の主体か」を確認すると、話の筋が追いやすくなるでしょう。
基本の対策と発注・運用の観点
SSRFにも、有効性が知られた対策があります。中心になる考え方と、発注・運用で押さえておきたい観点を整理しておきましょう。
| 対策 | 考え方 |
|---|---|
| 宛先の許可リスト化 | 最も基本の対策。サーバが取りにいってよい相手をあらかじめ決めておき、それ以外への要求は弾きます。「弾くものを決める」より「通すものだけを決める」ほうが漏れにくくなります。 |
| 内部アドレス宛ての遮断 | 内部ネットワークやクラウドの内部窓口にあたるアドレスへの通信を、そもそも遮断します。ネットワーク側の設定で、サーバから内部への不要な通信を止める考え方です。 |
| クラウド側の保護機能 | クラウドには、内部窓口への不用意なアクセスを防ぐための、より新しい方式が用意されていることがあります。これらを有効にしておくと、認証情報の窃取を抑えやすくなります。 |
| 権限の最小化 | サーバに与える権限を必要な範囲に絞ります。万一、認証情報が抜き取られても、できることが限られていれば、被害を小さくとどめられます。 |
中心になるのは、サーバが取りにいく宛先を制限し、内部側への通信を許さないという考え方です。加えて、クラウド側の保護機能や権限の最小化を重ねることで、万一のときの被害を抑える多層的な守りになります。SSRFは「入力を受け取って、その先へ通信する」機能に潜むため、そうした機能があるかどうかを意識することが第一歩です。
発注・運用の立場では、いくつかの観点を押さえておくとよいでしょう。第一に挙げられるのが、外部URLを扱う機能の把握になります。利用者が指定したURLやアドレスをサーバが取りにいく機能があるか、提案や仕様の中で確認しておくと、リスクの所在がつかめます。第二に、クラウド設定の確認です。クラウドを使う場合、内部窓口の保護機能が有効になっているかは、SSRF対策の要になります。第三に、脆弱性診断の活用です。リリース前や定期的なタイミングで診断を受けると、作り込みの不備を早い段階で見つけられます。なお本記事は攻撃手法の実践的な手順ではなく、SSRFという脅威の考え方と、発注・運用で押さえたい観点に焦点を当てているものです。個別の対策の実装や診断は、実績のあるベンダーや専門機関への相談が別途必要になります。
まとめ
- SSRFは、Webサーバを踏み台にして、攻撃者の狙った先へサーバから通信を送らせる攻撃です。
- 通信の主体が攻撃者ではなくサーバである点が特徴で、外部から届かない内部にも到達されます。
- 原因は、サーバが取りにいく宛先を利用者の入力で決め、その妥当性を確認していないことにあります。
- 被害は、クラウド認証情報の窃取・内部システムの探索・非公開情報の取得など、クラウドで拡大しやすいものです。
- 名前の似たCSRFとは別物で、SSRFはサーバに、CSRFは利用者のブラウザに通信させる攻撃です。
- 対策の中心は宛先の制限で、クラウド側の保護機能や権限の最小化を多層で重ねます。
- 本記事は攻撃手法の手順ではなく、脅威の考え方と発注・運用の観点の整理を狙いとしています。
よくある質問
SSRFとCSRFは名前が似ていますが同じものですか。
名前は似ていますが、別の攻撃です。SSRF（サーバサイドリクエストフォージェリ）は、Webサーバを踏み台にして、サーバから攻撃者の狙った先へ通信を送らせる攻撃です。一方CSRF（クロスサイトリクエストフォージェリ）は、ログイン中の利用者のブラウザに、本人が意図しない通信を正規サイトへ送らせる攻撃になります。通信を送る主体が、SSRFはサーバ、CSRFは利用者のブラウザという点が大きな違いです。狙う先も、SSRFは内部システム側、CSRFは正規サイト側と対照的で、対策の考え方も異なります。
なぜSSRFはクラウドでとくに危険とされるのですか。
クラウドのサーバには、自身の設定や一時的な認証情報を取得するための内部専用の窓口が用意されていることがあり、SSRFでそこにアクセスされると、サーバがもつ強い権限の認証情報が抜き取られるおそれがあるためです。クラウドでは一つの認証情報が広い権限を持つことも多く、抜き取られると被害が連鎖的に広がりやすくなるのです。実際に、SSRFがクラウド上の大規模な情報漏えいの一因になった事例も報告されています。クラウドを使う場合は、この内部窓口を保護する設定が対策の要になります。
どんな機能があるとSSRFのリスクが生じますか。
利用者が指定したURLやアドレスを、サーバが代わりに取りにいく機能があると、SSRFのリスクが生じます。たとえば、指定した画像のURLを読み込む、外部サイトのデータを取り込む、指定したアドレスの状態を確認する、といった機能です。こうした機能自体は便利で一般的なものですが、取りにいく宛先を確認せずに処理すると、内部アドレスを紛れ込ませる余地が生まれます。まずは自社のシステムにこうした「サーバが外部へ取りにいく」機能があるかを把握し、あるなら宛先の制限がかかっているかを確認するとよいでしょう。
WAFを導入すればSSRF対策は十分ですか。
WAFは補助的な備えにはなりますが、それだけで十分とはいえません。SSRFは、正規の機能に内部アドレスを紛れ込ませる形で成立するため、通信の見た目が正常に近く、入り口での検知だけではすり抜ける余地が残ります。根本的な対策は、サーバが取りにいく宛先を許可リストで絞り、内部アドレス宛ての通信を遮断することです。あわせて、クラウド側の内部窓口の保護や権限の最小化を重ねると、より確からしい守りになります。WAFはこうした根本対策を補う一枚と位置づけ、多層で守るのが基本です。
著者：テレリモ総研編集部 鈴木 亮佑
LASSICでは、国内ニアショア開発体制を活かし、SSRFをはじめとする脆弱性を作り込まないための設計・実装から、外部URLを扱う機能の宛先制限、ネットワーク側の遮断、クラウドの内部窓口の保護設定、権限設計、脆弱性診断を踏まえた改修までを一貫して支援する体制です。クラウド移行時のセキュリティ設計や、診断で受けた指摘への対応にお困りの際もご相談いただけます。要件定義の段階から実装、テスト、リリース後の運用・保守まで、工程を分けずに任せられる点も強みでしょう。セキュリティの作り込みに不安がある段階からでも、ご相談ください。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
