3.4サーバセキュリティ②

はい、承知いたしました。
令和4年度春期 情報処理安全確保支援士試験 午後II問1の問題文、設問、解答解説をソースに基づいて出力します。

---

＜問１＞ Webサイトのセキュリティ

問題文

A社は、従業員1,500名の中堅システム開発会社である。A社では、セキュリティ品質の高いWebサイトを開発するために、表1に示すWebセキュリティ管理基準を定めて運用している。

表1 Webセキュリティ管理基準（抜粋）

項番	管理策	概要
1	セキュリティ要件レビュー	・概要設計、基本設計、詳細設計それぞれの設計レビューにおいて、Webサイトに関するセキュリティ要件をレビューする。
2	ツールによるソースコードレビュー	・Webサイトのリリースまでに実施する。 ・期間は、3日間くらいが目安である。 ・開発環境の特性などが原因で実施できない場合、項番3を行う。 ・ツールが検出した指摘事項について、開発担当者は、脆弱性かどうか、対策が必要かどうかを判断する。 ・セッション管理の脆弱性は、一部だけが対象である。 ・認可・アクセス制御の脆弱性は、対象外である。
3	プロジェクトメンバによるソースコードレビュー	・項番2が実施できない場合、Webサイトのリリースまでに実施する。 ・期間は、10日間くらいが目安である。 ・A社の指定した既知の脆弱なコードパターンを見つける。 ・レビューでの指摘事項について、開発担当者は、脆弱性かどうか、対策が必要かどうかを判断する。 ・セッション管理の脆弱性は、一部だけが対象である。 ・認可・アクセス制御の脆弱性は、対象外である。
4	ツールによる脆弱性診断	・Webサイトのリリースまでに実施する。 ・期間は、3日間くらいが目安である。 ・Webサイトをテスト環境で稼働させ、ツールでWebサイトに様々なHTTPリクエストを送り、その応答を評価する。 ・ツールが検出した指摘事項について、開発担当者は、脆弱性かどうか、対策が必要かどうかを判断する。 ・セッション管理の脆弱性は、一部だけが対象である。 ・認可・アクセス制御の脆弱性は、対象外である。
5	専門技術者による脆弱性診断	・Webサイトのリリースまでに実施する。 ・期間は、10日間くらいが目安である。 ・専門会社に委託する。 ・Webサイトをテスト環境で稼働させ、Webサイトに様々なHTTPリクエストを送り、その応答を評価する。 ・診断による指摘事項について、専門技術者と開発担当者は、対策が必要かどうかを協議して判断する。 ・セッション管理の脆弱性は、対象である。 ・認可・アクセス制御の脆弱性は、対象である。
注1	脆弱性診断サービスを提供しているD社に委託している。

〔A社によるB社の子会社化〕
B社は、従業員200名の新興のITサービス会社であり、各種SaaSを提供している。A社とB社は協業関係にあったが、両社の経営陣は、双方の強みを生かせると判断し、A社によるB社の子会社化について合意した。B社のクラウド環境には、コーポレートサイト（サイトB）、及びB社が提供中の三つのSaaSそれぞれのWebサイト（サイトX、サイトY、サイトZ）がある。それらの概要を表2に示す。

表2 B社のWebサイトの概要

サイト名及びURL	概要	システム構成
サイトB https://www.b-sha.co.jp/	・B社に関する情報を発信している。 ・コンテンツマネジメントシステム（CMS）を導入し、運用している。	IaaS上のWebサーバで構成されている。
サイトX https://x.b-sha.co.jp/	・会社又は組織向けのコミュニケーションサービスであり、利用する社間又は組織間で、情報共有やチャットが行える。	IaaS上のWebサーバ及びデータベースサーバ（DBサーバ）で構成されている。
サイトY https://y.b-sha.co.jp/	・個人向けのブログサイトであり、利用者が情報を発信できる。 ・"A社のニューストピック"を表示する。	IaaS上のWebサーバとDBサーバで構成されている。
サイトZ https://z.b-sha.co.jp/	・ソフトウェア開発を業向けのWebサービスであり、利用者はグループを作ることができ、そのグループ内で、マイルストーン、タスク、ソースコードなどのプロジェクト情報を共有できる。	IaaS上のWebサーバとDBサーバで構成されている。
注1	DBサーバには、B社のシステム担当者と、それぞれのサイトのWebサーバとがアクセスできる。

子会社化に当たって、B社のWebサイトのセキュリティ水準を確認することになり、A社の品質管理部でセキュリティ技術を担当しているRさんが対応することになった。

〔B社のWebサイトのセキュリティ水準の確認〕
Rさんは、サイトB、サイトX、サイトY及びサイトZに対する脆弱性診断をD社に依頼した。診断の結果、検出された脆弱性を表3に示す。

表3 検出された脆弱性（抜粋）

サイト名	脆弱性名
サイトB	・クロスサイトスクリプティング（XSS）脆弱性
サイトX	・XSS脆弱性 ・クロスサイトリクエストフォージェリ（CSRF）脆弱性 ・クリックジャッキング脆弱性
サイトY	・XSS脆弱性 ・サーバサイドリクエストフォージェリ（SSRF）脆弱性
サイトZ	・XSS脆弱性 ・SSRF脆弱性

〔サイトBのXSS脆弱性〕
D社は、サイトBに①診断用リクエストを送ることで、XSS脆弱性があることを確認した。このリクエストは、ライブラリMを使ってプログラムCが処理する。ライブラリMはSEOのためのライブラリである。B社では、開発部のメンバそれぞれが、開発時に利用可能なライブラリを収集している。使用するライブラリは、マルウェアが含まれていない、既知の脆弱性が修正された、安全性が確認できているライブラリを公開しているWebサイトから、ファイルサーバにダウンロードし、利用している。今回使われていたライブラリMは、既知のXSS脆弱性の対策をしていないバージョンであった。その結果、同じXSS脆弱性が検出された。これを受け、B社における②再発防止策について検討した。

〔サイトXのCSRF脆弱性〕
サイトXは、セッションIDをJESSIONIDというcookieに格納している。D社は、サイトXのキャンペーン応募ページでCSRF脆弱性を検出した。
(1) 診断用利用者（利用者A）の利用者IDでサイトXにログインし、キャンペーン応募ページで送信されるリクエストの内容をツールを使って確認した。
(2) 利用者Aとは別の診断用利用者（利用者B）の利用者IDでサイトXにログインし、キャンペーン応募ページで送信されるリクエスト中のcsrftokenの値を、(1)で確認した値に設定して送信したところ、利用者Bとして処理された。
この結果から、csrftokenと [ a ] 又は [ b ] とをひも付けるという対策ができていないことが分かった。

〔サイトXのクリックジャッキング脆弱性〕
サイトXでは、クリックジャッキングによって、利用者が気付かずに利用者情報の公開範囲を変更させられてしまう脆弱性が検出された。攻撃者は、画面 [ c ] を利用者から見て [ d ] に [ e ] 状態で奥に公開し、サイトXの画面 [ f ] を利用者から見て [ g ] に [ h ] 状態で手前に重ねて表示する。この状態のサイトにアクセスした利用者は、意図せず利用者情報の公開範囲を変更させられてしまう可能性がある。クリックジャッキング脆弱性の対策には、レスポンスヘッダに [ i ] を含める方法と [ j ] を含める方法がある。後者は標準化されている。

〔サイトYのSSRF脆弱性〕
サイトYでは、例えば、図4のリクエストを受け取ると、A社のニューストピックを取得し、表示するようになっている。
GET /news?topic=https://www.a-sha.co.jp/news/20220417.html HTTP/1.1
この処理にSSRF脆弱性があった。D社は、③図4のリクエスト中の値を変更してサイトYに送り、サイトYのDBサーバのメンテナンス用のWebインタフェースにアクセスできることを確認した。

〔サイトZのSSRF脆弱性〕
サイトZでは、最近、旅行会社P社の宿泊サイトと連携する新機能が開発された。この機能は、駅名を入力すると、その駅周辺のホテルの割引クーポンなどの"お得情報"を表示できる。D社の専門技術者V氏がSSRF脆弱性を検出した手順を表4に示す。

表4 SSRF脆弱性を検出した手順

順序	手順
1	P社宿泊サイトに登録されていない駅名、例えば、"abc"を入力し、Hostヘッダの値を、V氏が用意したサイトのFQDNに変更して、サイトZにリクエストを送る。
2	サイトZは、P社宿泊サイトに、"/station/abc"をリクエストURIに指定したリクエストを送る。
3	P社宿泊サイトは、Locationヘッダに [ k ] のURLを含めたレスポンスをサイトZに返す。
4	サイトZは、受け取ったレスポンスを基に、 [ k ] にリクエストを送る。

表4の手順によって、V氏は、Authorizationヘッダの値を駆け取ることができた。
D社からP社に、SSRF脆弱性への対策が提案された。加えて、④別の対策も実施することが望ましいとのことであった。

〔開発プロセスの見直し〕
Rさんは、B社の開発プロセスについて調査を進めた。B社では、アジャイル開発を行っている。B社の開発プロセスの概要を図7に示す。

(図7はソース参照)

Rさんは、B社のWebサイトのセキュリティ水準を十分なものにするためには、A社のようなWebセキュリティ管理基準をB社に導入する必要があると考えた。
RさんはE課長との会話で、⑤ソースコードレビューやツールによる脆弱性診断では発見できないが、専門技術者による脆弱性診断では発見できる脆弱性が多くあり、専門技術者による脆弱性診断を改良リリースにおいて毎回実施できない場合でも、⑥当該診断が長期間行われないことを避けるために、時期を決めて実施することや、⑦開発プロセスを見直すことを検討するよう依頼した。
Rさんはまた、Webサイトの実装に必要な一般的な機能や定型コードを、ライブラリとしてあらかじめ用意したフレームワークには、⑧脆弱性対策が組み込まれていて、それがデフォルトで有効になっているものもあるので、利用を検討してみてもよいと述べた。

---

設問

設問1 〔サイトBのXSS脆弱性〕について、(1)、(2)に答えよ。
(1) 本文中の下線①における診断用リクエストの構成要素を、解答群の中から選び、記号で答えよ。
解答群
ア リクエストライン：GET /confirm?"><"
イ リクエストライン：GET /confirm?"
ウ リクエストボディ：">"
エ リクエストボディ：POST /confirm

(2) 本文中の下線②について、考えられる再発防止策を、35字以内で述べよ。

設問2 本文中の [ a ] 、 [ b ] に入れる適切な字句を答えよ。

設問3 〔サイトXのクリックジャッキング脆弱性〕について、(1)、(2)に答えよ。
(1) 本文中の [ c ] ～ [ h ] に入れる適切な字句を、それぞれの解答群の中から選び、記号で答えよ。
c, fに関する解答群
ア α
イ β
d, gに関する解答群
ア 奥
イ 手前
e, hに関する解答群
ア 可視の
イ 透明な

(2) 本文中の [ i ] 、 [ j ] に入れる適切な字句を、解答群の中から選び、記号で答えよ。
解答群
ア Content-Disposition
イ Content-Security-Policy
ウ X-Content-Type-Options
エ X-Frame-Options

設問4 本文中の下線③について、図4のリクエスト中のどの値をどのような値に変更したか。45字以内で具体的に述べよ。

設問5 〔サイトZのSSRF脆弱性〕について、(1)、(2)に答えよ。
(1) 表4中の [ k ] に入れる適切な字句を、15字以内で答えよ。
(2) 本文中の下線④について、別の対策とは何か。B社で実施することが望ましい対策を、25字以内で述べよ。

設問6 〔開発プロセスの見直し〕について、(1)～(4)に答えよ。
(1) 本文中の下線⑤について、該当する脆弱性を二つ挙げ、それぞれ15字以内で答えよ。
(2) 本文中の下線⑥について、専門技術者による脆弱性診断が長期間行われないことを避けるためには、どのような時期に実施すればよいか。改良リリースの実施に影響を与えないことを前提に、20字以内で答えよ。
(3) 本文中の下線⑦について、専門技術者による脆弱性診断が長期間行われないことを避けるために、開発プロセスをどのように見直せばよいか。アジャイル開発の継続を前提に、40字以内で述べよ。
(4) 本文中の下線⑧について、CSRF脆弱性の場合では、どのような処理を行う機能が考えられるか。その処理を、55字以内で具体的に述べよ。

---

解答・解説

設問1
【試験センターによる解答例】
(1) ア
(2) ・ダウンロードするライブラリに既知の脆弱性がないかを確認する。（30字）
・特定のWebサイトからの入手をルール化し、明文化する。（27字）

【解説】
(1) リクエストラインが「GET /confirm?」で始まり、クエリ文字列がダブルクオート["]で囲まれているアが正しい記述です。
(2) B社では安全性が確認できているライブラリを公開しているWebサイトからダウンロードして利用しているとありますが、今回は既知のXSS脆弱性対策がされていないライブラリMが使用されていました。これは、それ以外のWebサイトからダウンロードされた可能性があることを示唆しています。再発防止策として、ダウンロードするライブラリに既知の脆弱性がないかを確認すること、または安全性が確認できている特定のWebサイトからの入手をルールとして明文化することが考えられます。

設問2
【試験センターによる解答例】
a：利用者ID
b：セッションオブジェクト
※aとbは順不同

【解説】
利用者Aの利用者IDでログインした際のcsrftokenの値が、利用者Bの利用者IDでログインした際にも有効であったということは、csrftokenと利用者IDやセッションIDなどのセッションオブジェクトとのひも付けが行われていないことを示しています。

設問3
【試験センターによる解答例】
(1) c：イ, d：ア, e：ア, f：ア, g：イ, h：イ
(2) i：エ, j：イ

【解説】
(1) クリックジャッキングは、利用者をだますために用意した画面βの手前に、クリックさせたい画面αを透明な状態で重ねて表示する攻撃手法です。これにより、利用者は画面βをクリックしているつもりで、実際には画面αのクリックイベントを発生させてしまいます。したがって、cは「β」、dは「奥」、eは「可視の」、fは「α」、gは「手前」、hは「透明な」が入ります。
(2) クリックジャッキング対策として、レスポンスヘッダに**"X-Frame-Options"を含める方法と、"Content-Security-Policy"**を含める方法があります。後者はW3Cで標準化が進められています。"X-Frame-Options"はframeやiframeでのページ表示の可否を指定し、「DENY」で一切禁止、「SAMEORIGIN」で同一ドメインのみ許可します。"Content-Security-Policy"も同様に、許可するドメインを限定できます。

設問4
【試験センターによる解答例】
topicの値を https://db-y.b-sha.co.jp/ に変更した。（39字）

【解説】
通常のリクエストでは、topicの値にA社のニューストピックのURLが指定されています。この仕組みを悪用してサイトYのDBサーバのメンテナンス用Webインタフェースにアクセスできたとすれば、**topicの値をサイトYのDBサーバのURLである「https://db-y.b-sha.co.jp/」に変更した**と考えられます。

設問5
【試験センターによる解答例】
(1) k：V氏が用意したサイト（10字）
(2) returnURLの値を固定値にする。（19字）

【解説】
(1) サイトZの連携機能では、Hostヘッダに設定された値がreturnURLのホスト名になります。攻撃手順では、Hostヘッダの値をV氏が用意したサイトのFQDNに変更しています。これにより、サイトZは最終的にV氏が用意したサイトへリクエストを送ることになります。したがって、kには「V氏が用意したサイト」が入ります。
(2) 提案された対策も有効ですが、より確実な対策は、returnURLの値を外部から指定させる仕様を見直し、固定値にすることです。

設問6
【試験センターによる解答例】
(1) ・一部のセッション管理の脆弱性（14字）
・認可・アクセス制御の脆弱性（13字）
(2) 改良フェーズにおける1か月の休止期間（18字）
(3) ・専門技術者による脆弱性診断が必要なときは、改良リリースを次回に持ち越す。（36字）
・半年に一度、改良リリースの期間を長くする。（21字）
・定期的に、期間の長い改良リリースを設ける。（21字）
(4) CSRF対策用トークンの発行、HTMLへの埋め込み、必要なひも付け、及びこれを検証する処理（45字）

【解説】
(1) 表1のWebセキュリティ管理基準において、項番2、3、4では対象外ですが、項番5では対象となる脆弱性は「セッション管理の脆弱性」と「認可・アクセス制御の脆弱性」です。ただし、セッション管理の脆弱性の一部は他の項番でも対象のため、「一部のセッション管理の脆弱性」となります。
(2) 専門技術者による脆弱性診断の実施期間は10日間程度が目安です。図7によると、改良フェーズには半年に1回、1か月の休止期間が設けられており、この期間を利用すれば診断が長期間行われない事態を避けられます。
(3) 開発プロセスの見直しとしては、2週間周期の改良リリースを脆弱性診断のために柔軟に調整することが考えられます。具体的には、診断が必要な場合はリリースを次回に持ち越す、または半年に一度など定期的に長い期間の改良リリースを設けるといった方法が挙げられます。
(4) CSRF対策に必要な機能としては、まずCSRF対策用トークンを発行し、それをHTMLに埋め込んで利用者に送信する処理が必要です。さらに、サイトXの脆弱性の原因であった、トークンを利用者IDなどとひも付ける処理と、返されたトークンを検証する処理が考えられます。