サイトアイコン やさしいネットワークとセキュリティ

【情報処理安全確保支援士試験 令和6年度 春期 午後 問3 設問4】サーバサイドリクエストフォージェリ（SSRF）

aolaniengineer

いよいよ情報処理安全確保支援士試験の解説シリーズも最終回です！トリを飾るのは、近年その危険性が特に注目されている「SSRF（サーバサイドリクエストフォージェリ）」です。

特にクラウド環境では、この脆弱性がもたらす被害は計り知れません。今回の問題は、クラウド特有の仕組みである「IMDS」が絡む、非常に実践的な内容です。SSRFの仕組みから対策まで、この機会にマスターしてしまいましょう！

情報処理安全確保支援士試験 令和6年度 春期 午後 問3

【出典：情報処理安全確保支援士試験 令和6年度 春期 午後 問3（一部、加工あり）】

[サイトYに対するWebアプリ診断]
 サイトYに対するWebアプリ診断では、次の脆弱性が検出された。

[SSRFについて]
 Z社がSSRFを検出した経緯は、次のとおりであった。
⑴サイトPの新着情報を取得する際に、利用者のWebブラウザがWebサーバYに送るリクエストを確認したところ、図7のとおりであった。


⑵⑥図7のリクエストのパラメータの値をWebサーバYのCMSの管理ログイン画面のURLに変更することで、その画面にアクセスできるが、ログインはできないことを確認した。
⑶⑦図7のリクエストのパラメータの値を別のURLに変更するという方法（以下、方法Fという）でSSRFを悪用して、クレデンシャル情報を取得し、ストレージWから情報を盗み出すことができることを確認した。
⑷IMDSにアクセスする方式を方式1から方式2に変更すると、方法Fではクレデンシャル情報を取得できないので、ストレージWから情報を盗み出すことができない。しかし、図7のリクエストのパラメータの値を変更することで、WebサーバYから送られるリクエストに任意のメソッドの指定及び任意のヘッダの追加ができる方法（以下、方法Gという）がある。方法Gを用いれば、方式2に変更しても、⑧クレデンシャル情報を取得し、ストレージWから情報を盗み出すことができることを確認した。

 Z社は、クラウドW上のネットワークでのアクセス制御の設定、及び⑨サイトYのWebアプリに追加すべき処理を提案した。

 リリース前の脆弱性診断で検出された脆弱性の対策が全て完了し、サイトXとサイトYは稼働を開始した。

問題の状況：サーバが攻撃の「踏み台」に

まずは、サイトYで発生したSSRFの状況を整理します。

CSRFが「利用者のブラウザ」を悪用するのに対し、SSRFは「Webサーバ自身」を悪用して内部・外部へ攻撃リクエストを送信させるのが特徴です。

キーワード解説

SSRF (サーバサイドリクエストフォージェリ)

サーバに、外部サイトのコンテンツを取得させるような機能がある場合、その取得先URLの検証が不十分だと、攻撃者が意図した任意の場所にサーバからリクエストを送信させることができてしまいます。これがSSRFです。 特に危険なのは、本来インターネットからはアクセスできない社内ネットワークや、クラウドの内部サービスに、サーバを踏み台にしてアクセスされてしまう点です。

IMDS (インスタンスメタデータサービス)

クラウド環境で稼働するサーバ（インスタンス）は、IMDSと呼ばれる特別なサービスにアクセスすることで、自分自身の情報（IPアドレスなど）や、クラウドサービスを操作するための認証情報（クレデンシャル情報）を取得できます。 このIMDSは、通常169.254.169.254のような、そのサーバからしかアクセスできない特別なプライベートIPアドレスを持っており、外部からはアクセスできません。 しかし、SSRF脆弱性があると、サーバを踏み台にしてこのIMDSにアクセスされ、認証情報を盗まれてしまう危険があるのです。

【設問4 (1)】なぜCMS管理画面にログインできないのか？

(1) 本文中の下線⑥について、ログインできないのはなぜか。SSRF攻撃の特徴を基に、35字以内で答えよ。

攻撃者はSSRF脆弱性を利用し、pageパラメータにサイトY自身のCMS管理画面のURLを指定しました。画面へのアクセスには成功したものの、ログインはできませんでした。 その理由は何でしょうか。

ヒントは、本文のCMSの仕様にあります。

対して、今回の攻撃の起点となったリクエストは図7の通りGET /top?page=…です。 この機能は、指定されたURLに対してGETメソッドでアクセスするものです。

つまり、SSRF攻撃でCMS管理画面にアクセスしようとしても、送信されるメソッドは「GET」です。しかし、ログイン処理は「POST」しか受け付けません。メソッドが異なるため、IDやパスワードといったログイン情報を送信することもできず、ログインは失敗するのです。

これを簡潔にまとめたものが、解答例の「変更後のURLにPOSTデータは送ることができないから」です。

【設問4 (2)】IMDSから認証情報を盗む方法（方式1）

(2) 本文中の下線⑦について、クレデンシャル情報を取得する方法を、具体的に答えよ。

次に、攻撃者がSSRFを悪用してストレージWの情報を盗むために、IMDSからクレデンシャル情報を取得した方法です。

この時のIMDSのアクセス方式は「方式1」が採用されていました。

やるべきことは単純ですね。SSRF脆弱性のあるpageパラメータに、このIMDSのURLを指定してリクエストを送るだけです。そうすれば、WebサーバYがIMDSにアクセスし、取得したクレデンシャル情報がレスポンスとして攻撃者に返ってきます。

よって、解答は**「パラメータ pageの値をIMDSのクレデンシャル情報を返すURLに変更する。」** となります。

【設問4 (3)】より強固な方式2を突破する方法

(3) 本文中の下線⑧について、方法Gを用いてクレデンシャル情報を取得する方法を、具体的に答えよ。

方式1は単純なため、D社はよりセキュアな「方式2」への変更を検討しました。 しかし、それでも「方法G」という別の攻撃手法を使えば突破されてしまうことが分かりました。 この問題は【採点講評】で「正答率が低かった」と指摘されており、方式2の仕様を正確に理解できているかが問われます。

まず、関係者の能力を確認しましょう。

まさに、方式2を突破するためにあつらえたような能力ですね。この能力を使って、方式2の正規の手順をなぞらえてあげればよいのです。

【攻撃ステップ】

  1. トークン取得: まず「方法G」を使い、WebサーバYからIMDSのトークン発行用URLに対し、PUTメソッドでリクエストを送信させます。これにより、攻撃者はアクセストークンを入手します。
  2. クレデンシャル情報取得: 次に再び「方法G」を使い、WebサーバYからIMDSのクレデンシャル情報取得用URLに対し、GETメソッドでリクエストを送信させます。その際、リクエストヘッダに手順1で入手したトークンを追加します。

この2段階の手順を踏むことで、方式2の認証を突破し、クレデンシャル情報を取得できるのです。 この流れをそのまま記述したものが、解答例「トークンを発行するURLにPUTメソッドでアクセスしてトークンを入手し、そのトークンをリクエストヘッダに含めて、IMDSのクレデンシャル情報を返すURLにアクセスする。」となります。

【設問4 (4)】SSRFの根本的な対策とは

(4) 本文中の下線⑨について、サイトYのWebアプリに追加すべき処理を、35字以内で具体的に答えよ。

これだけの脅威をもたらすSSRFですが、対策の原則はシンプルです。 この機能は、そもそもV大学の「サイトP」の情報を取得するためのものです。 であれば、それ以外のURLにアクセスする必要は一切ありません。

したがって、アプリケーションに追加すべき処理は、pageパラメータで受け取ったURLを検証し、アクセスを許可する接続先を限定（ホワイトリスト化）することです。 具体的には、URLのホスト名（ドメイン）がサイトPのものであるかを確認し、それ以外であればエラーとして処理を中断します。

これが、解答例の「パラメータ page の値がサイトP以外のURLならエラーにする。」という処理になります。

また、本文ではアプリケーションの修正に加え、「クラウドW上のネットワークでのアクセス制御の設定」も提案されています。 これは、例えばWebサーバYからIMDSへの通信をネットワークレベルで原則禁止するといった、多層防御の考え方に基づいた非常に有効な対策です。

まとめ：クラウド時代の必須知識SSRF

今回の問題は、現代のWebセキュリティを象徴するような素晴らしい良問でした。

全4回にわたる解説はこれにて終了です。お疲れ様でした！ 一つの問題から、XSS, CSRF, 認可制御, SSRFといったWebセキュリティの重要テーマを網羅的に学べましたね。ぜひ今回の学びを活かして、合格を勝ち取ってください！応援しています！


モバイルバージョンを終了