情報処理安全確保支援士の令和6年度 春季試験 午後問題 問3の解説を行っていきます。
令和5年度 秋季試験より、これまでの試験構成が午後Ⅰ・午後Ⅱから午後問題へと変更になっています。
試験構成の変更や受験者への影響については『こちら』にまとめていますので、まだ確認されていない方は試験前までにご覧ください。
出題テーマ：Webサイトのセキュリティ対策（XSS・CSRF・SSRF）
出題テーマとしては『Webサイトのセキュリティ対策（XSS・CSRF・SSRF）』でした。
XSS・CSRF・SSRFの攻撃内容や対策について出題されました。
最低でもXSS・CSRF・SSRFがどういった内容なのかという基本的な知識がないと解答することが難しかったと思います。
一方で基本的な知識があれば、ある程度文章中のヒントから解答することができる国語の問題だったかとは思います。
設問1 (1)
下線①として、『設計書を調査した上で手動による分析を行い、図3中のリクエスト内のスクリプトが別の機能の画面に出力されることを確認した。』とあります。
図3は問合せ機能のリクエストとレスポンスです。
こちらは表1中の『項番5：問合せ機能』に関してであり、選択すべきは他の問合せに関連する機能であると考えることができます。
ということで解答は、『項番9：問合せ管理機能』が該当すると考えられます。
設問1 (2)
下線②として、『攻撃者がこのXSSを悪用してサイトX内の全会員の利用者情報を取得する』とあります。
XSS：クロスサイトスクリプティングに関しての問題です。
XSSのイメージとしては攻撃者がスクリプトを仕込んだ罠サイトを用意し、利用者にアクセスを行わせます。
アクセスするとスクリプトを含んだリクエストが行われ、Cookieの窃取や偽のサイトを表示させて、そこでID/PWの入力を促して情報漏洩やマルウェア感染を誘導するなどが行われます
話を戻しますと、重要な部分として、『サイトXのログインセッション管理は、cookieパラメータのSESSIONIDで行う。』とあります。
つまり、Cookieを窃取さえできれば攻撃者はサイトXにログイン可能となり、あとは自由に情報を取得することができます。
ということで解答例は、『攻撃者は罠サイトを用意し、 cookieを攻撃者に送信するスクリプトを送信するよう仕込んでおく。管理者にアクセスを行わせ、リンクなどを踏ませる。このようにしてcookieを窃取し、それを使用することで、管理者としてログインし、利用者情報を取得する。』と考えることができます。
ちなみに、Secure属性とはHTTPSの場合にのみCookieを送信する設定です。
Cookieの設定としてXSSに対して有効なのはHttpOnly属性が挙げられます。
HttpOnly属性はHTTP以外のJavaScriptなどからCookieを読み取ることができなくなりますので、完全ではありませんがXSSに対して有効な設定とされています。
設問2 (1)
下線③として、『利用者に被害を与える』とあります。
CSRF：クロスサイトリクエストフォージェリに関する内容です。
CSRFのイメージとしては、攻撃者が罠サイトを用意し、ユーザにアクセスを行わせます。
ユーザがアクセスすると罠サイトに用意されていたリクエストを攻撃対象のサーバに送信し、攻撃対象のサーバは不正なリクエストを処理してしまいます。
被害内容としてはSNSや掲示板などでのなりすまし投稿や、不正送金などが挙げられます。
表2を見ていきますと、手順1ではcsrf_tokenが空、手順2では値がない場合ですが、それぞれエラーとなっていますので、一定のCSRF対策はできています。
しかし、手順3では異なる利用者アカウントで取得したcsrf_tokenとなっていますが、この場合は正常に処理が行われています。
つまり攻撃者が用意したアカウントのcsrf_tokenでも正常に処理が行われるので、こちらとCSRFの流れを合わせてあげればよいと考えることができます。
解答例は『攻撃者はcsrf_tokenをあらかじめ取得しておく。罠サイトを用意し、利用者にアクセスさせ、自身が取得したcsrf_tokenと変更情報をリクエストして、利用者情報の書き換えを行う。』と考えることができます。
設問2 (2)
知識の問題です。
重要な部分として、『サイトXの構成次第では、SameSite属性をcookieに付与することも有効な対策となり得る。SameSite属性は、Strict、Lax、Noneの三つの値のうちのいずれかを取る。サイトXにログインした利用者のWebブラウザにおいて、サイトX内で遷移する場合と外部WebサイトからサイトXに遷移する場合では、SameSite属性の値によってサイトXのcookie送信の有無が表3のように異なる。』とあります。
CookieのSameSite属性の値には説明文および表3に記載の通り、『Strict、Lax、None』の3種類があります。
Strictは別ドメインへはCookieを送信することができません。
Laxは別ドメインへCookieを送信することができますが、GETのみ送信することができます。
ちなみに、Noneは別ドメインへCookieを送信することができ、GET・POSTに限らず送信することができますが、Secure属性が必要です。
ということで、StrictはGET『a：×』、POST『b：×』、LaxはGET『c：○』、POST『d：×』となります。
設問3 (1)
下線④の部分として、『さらに、ある利用者がほかの利用者が注文した際のorder-codeを知らなくても、ある攻撃手法を用いれば攻撃が成功する』とあります。
図5のorder-codeは『202404-AHUJKI』とあり、規則として表1を見ますと、『注文履歴は注文年月である数字6桁とランダムな英大文字6桁の値をハイフンでつないだ注文管理番号で管理される。』とあり、『YYYYMM-XXXXXX』と年月と6桁の英大文字から構成されていることがわかります。
この6桁の英大文字に対して、総当たり攻撃をかければ、いつかは存在するorder-code（注文管理番号）にヒットすることになります。
ということで解答例は、『注文管理番号の英大文字6桁部分に対して総当たり攻撃を行う（28文字）』と考えることができます。
設問3 (2)
下線⑤として、『サイトXのWebアプリに追加すべき処理を説明した。』とあります。
現状としては利用者αが利用者βの注文履歴を閲覧できてしまいますが、あるべきとしては利用者αが本人の注文履歴しか閲覧できないという状況です。
重要な部分として、『サイトXのログインセッション管理は、cookieパラメータのSESSIONIDで行う。』とありましたので、Cookieを確認することで注文履歴の閲覧のリクエストを行っている利用者の特定を行うことは可能です。
また、図5の注釈に『表1の注文管理番号のことである。値から利用者を特定することができる。』とあり、order-codeからどの利用者の注文なのかを特定することも可能です。
ということで、注文履歴の閲覧のリクエストを行っている利用者と問合せをしている注文履歴の利用者が一致する場合にのみ応答、一致しない場合はエラーを返すようにすれば良いと考えることができます。
解答例として、『Cookieおよび問合せている注文管理番号から利用者を特定し、一致しない場合にエラーを返答する処理（49文字）』と考えることができます。
設問4 (1)
SSRF：サーバサイドリクエストフォージェリは、攻撃者が公開されているサーバに対して細工したアクセスを行うことで、そのサーバを踏み台として直接アクセスできないサーバに対して不正アクセスを行う攻撃です。
被害内容としては、DBサーバなどにアクセスが行われた場合に情報漏洩に繋がるなどが考えられます。
下線部⑥としては、『図7のリクエストのパラメータの値をWebサーバYのCMSの管理ログインのURLに変更することで、その画面にアクセスできるが、ログインはできない』とあります。
図2中のCMSについての説明を見ると、『WebサーバXのhttps://□□□.jp/adminまたはWebサーバYのhttps://■■■.jp/adminにアクセスすると、それぞれのサーバのCMSの管理ログイン画面にアクセスできる。ログインは、POSTメソッドで許可はされるが、GETメソッドでは許可されない。』とあります。
ログインを行うためにはPOSTメソッドでおそらくID・PWなどのデータを受け渡す必要がありますが、図7のリクエストを見るとGETメソッドです。
GETメソッドの中でパラメータ値を変更することでログイン画面にアクセスすることは可能ですが、そのパラメータ値にPOSTメソッドに変更してデータを送ることはできません。
よって解答例として、『変更したURLに対してPOSTでデータを送ることができないため（31文字）』と考えることができます。
設問4 (2)
下線⑦として、『図7のリクエストのパラメータの値を別のURLに変更するという方法（以下、方法Fという）でSSRFを悪用して、クレデンシャル情報を取得し』とあります。
図2中のIMDSについて確認すると、『IMDSは、VPCの各サーバから特定のURLにアクセスされると特定の情報を返す、例えばhttps://○○○/meta-data/credentialにGETメソッドでアクセスされると、クラウドW上のサービスのクレデンシャル情報を返す。』とあります。
ということで、このURLに変更してあげることでクレデンシャル情報を取得することができると考えられます。
解答例としては、『パラメータをIMDSのストレージWのクレデンシャル情報を返すURLに変更する』となります。
設問4 (3)
下線⑧の部分として、『IMDSにアクセスする方式を方式1から方式2に変更すると、方式Fではクレデンシャル情報を取得できないので、ストレージWから情報を盗み出すことができない。しかし、図7のリクエストのパラメータ値を変更することで、WebサーバYから送られるリクエストに任意のメソッドの指定および任意のヘッダが追加できる方法（以下、方法Gという）がある。方法Gを用いれば、方式2に変更しても、クレデンシャル情報を取得し、ストレージWから情報を盗み出すことができることを確認した。』とあります。
方式に関しては、図2中に記載があります。
『方式2：トークンを発行するURLにPUTメソッドでアクセスし、レスポンスボディに含まれるトークンを入手してから、そのトークンをリクエストヘッダに含めて特定のURLにアクセスすると情報を取得できる。』とあります。
方法Gを用いるのであれば何でもできてしまうので、方法2のやり方をそのまま行ってあげればよいです。
よって解答例は、『トークンを発行するURLにPUTメソッドでアクセスして、トークンを入手する。入手したトークンをリクエストヘッダに含めて、IMDSのストレージWのクレデンシャル情報を返すURLにアクセスする。』となります。
設問4 (4)
下線⑨として、『サイトYのWebアプリに追加すべき処理』とあります。
根本原因としては、サイトP（WebサーバY）へのリクエストでしたが、パラメータとしてWebサーバYのCMSの管理ログインの画面のURLに変更することでアクセスなどが行えてしまうことです。
サイトPへのリクエストなのであれば、URLがサイトP以外のものを受け付けない状態にしてあげれば、SSRFを防ぐことができます。
ということで解答例は、『パラメータを確認し、サイトP以外のURLの場合にエラーを返す処理（32文字）』と考えることができます。
公式解答例との比較
私の解答と公式解答を比較してみました。
満点ではないにせよ、少なくとも7割～8割程度は取れているかと思います。
予想配点はあくまで予想ですので参考程度でお願いします。
出題テーマは『Webサイトのセキュリティ対策（XSS・CSRF・SSRF）』でした。
XSS・CSRF・SSRFに関しての基本的な知識は必要でした。
基本的な知識さえあればある程度は文章中のヒントから解答することができる国語の問題だったと思います。
基本的な知識がないと解答することが困難だったかと思いますが、しっかりと復習して基本的な知識を抑えるようにしておきましょう。
回答する際に文字数制限がない問題もあり、『令和5年 秋期試験 午後 問4』のように完全自由ではないものの、少し具体的回答する必要があったかとは思います。
総じて、難易度としては普通～難しい程度だったかと思います。
配点 |
|||
| 設問1 (1) | 9 | 9 | |
| 設問1 (2) | 攻撃者は罠サイトを用意し、 cookieを攻撃者に送信するスクリプトを送信するよう仕込んでおく。管理者にアクセスを行わせ、リンクなどを踏ませる。このようにしてcookieを窃取し、それを使用することで、管理者としてログインし、利用者情報を取得する。 | 攻撃者がわなリンクを用意し、管理者にそのリンクを踏ませることで管理者権限のcookieを攻撃者のWebサイトに送信させ、その値を読み取って利用することで管理者としてサイトXにアクセスし、利用者情報を取得する。 | |
| 設問2 (1) | 攻撃者はcsrf_tokenをあらかじめ取得しておく。罠サイトを用意し、利用者にアクセスさせ、自身が取得したcsrf_tokenと変更情報をリクエストして、利用者情報の書き換えを行う。 | 攻撃者が自らのアカウントで取得したcsrf_tokenと一緒に利用者情報をサイトXに送るように構成したわなフォームに、詐欺メールなどで利用者を誘導し、利用者情報を変更させる。 | |
| 設問2 (2) | a：× b：× c：○ d：× |
a：× b：× c：○ d：× |
|
| 設問3 (1) | 注文管理番号の英大文字6桁部分に対して総当たり攻撃を行う（28文字） | Order-codeの下6桁を総当りで試行する。 | |
| 設問3 (2) | cookieおよび問合せている注文管理番号から利用者を特定し、一致しない場合にエラーを返答する処理（49文字） | cookieの値で利用者アカウントを特定し、order-codeの値から特定したものと違っていれば、エラーにする。 |
|
| 設問4 (1) | 変更したURLに対してPOSTでデータを送ることができないため（31文字） | 変更後のURLにPOSTデータは送ることができないから | |
| 設問4 (2) | パラメータをIMDSのストレージWのクレデンシャル情報を返すURLに変更する | パラメータpageの値をIMDSのクレデンシャル情報を返すURLに変更する。/strong> | |
| 設問4 (3) | トークンを発行するURLにPUTメソッドでアクセスして、トークンを入手する。入手したトークンをリクエストヘッダに含めて、IMDSのストレージWのクレデンシャル情報を返すURLにアクセスする。 | トークンを発行するURLにPUTメソッドでアクセスしてトークンを入手し、そのトークンをリクエストヘッダに含めて、IMDSのクレデンシャル情報を返すURLにアクセスする。 | |
| 設問4 (4) | パラメータを確認し、サイトP以外のURLの場合にエラーを返す処理（32文字） | パラメータpageの値がサイトP以外のURLならエラーにする。 |
引用元
問題および解答例に関しては、『独立行政法人 情報処理推進機構（IPA）』より引用しています。
YouTube解説動画
鋭意編集中につき少々お待ちください。
情報処理安全確保支援士の問題解説
その他の年度、問題解説は『以下のページ』にまとめております。
