令和4年度 春期 情報処理安全確保支援士試験 午後II 問1 Web脆弱性の原因究明とアジャイル開発におけるセキュリティ管理の導入

正解の根拠

図1「ライブラリMのコード」では、出力されるHTMLの <meta> タグが以下のように組み立てられます。
out.println("<meta property=\"og:url\" content=\"https://"+serverName+"/"+scriptName+"?"+queryString+"\">");

ここで、注記にあるように queryString にはURLのクエリ文字列以降の値が格納されます。
選択肢アのリクエストライン GET /confirm?"><img src=1 onerror=alert(1)><" を送信した場合、クエリ文字列以降の値である "><img src=1 onerror=alert(1)><" がそのまま queryString に入ります。
これが結合されると、出力は以下のようになります。
<meta property="og:url" content="https://serverName/confirm?"><img src=1 onerror=alert(1)><"">
このように、"> によって <meta> タグが強制的に閉じられ、その直後に悪意のある <img src=1 onerror=alert(1)> タグが展開されるため、XSS脆弱性が発現します。

各選択肢の解説

• ア: 上記の通り、既存のタグを適切に閉じてスクリプトを実行できる構成になっているため正解です。
• イ: リクエスト中のタグ閉じが > のみであり、<meta ... property="..." content="...?> となり、属性値のダブルクォーテーションが閉じられないため、後続のタグが正しく解釈されません。
• ウ, エ: これらは POST メソッドのリクエストボディに攻撃コードが含まれています。ライブラリMの処理ではクエリ文字列 (queryString) を対象としているため、リクエストボディの内容は出力に反映されません。

解説

本文では、ライブラリの利用について「開発部のメンバそれぞれが，開発時に利用可能なライブラリを収集している」「使用するライブラリは，マルウェアが含まれていない，既知の脆弱性が修正された，安全性が確認できているライブラリを公開しているWebサイトから，ファイルサーバにダウンロードし，利用している」と記述されています。
しかし実際には、「今回使われていたライブラリMは，既知のXSS脆弱性の対策をしていないバージョンであった」ため、複数のWebサイトで同じXSS脆弱性が検出されてしまいました。

この原因を踏まえると、再発防止策としては、ダウンロード時にライブラリの脆弱性を確認することや、安全性が確認できるWebサイトからの入手を組織として徹底することが考えられます。
したがって、再発防止策としては以下のいずれかを記述します（どちらか一方で満点となります）。

• ダウンロードするライブラリに既知の脆弱性がないかを確認する。
• 特定のWebサイトからの入手をルール化し，明文化する。

高得点のポイント

• 「ダウンロードするライブラリに既知の脆弱性がないかを確認する」こと、または「特定のWebサイトからの入手をルール化し，明文化する」ことのいずれか一方を記述します。
• 本文で示された問題の背景を踏まえ、35字以内で簡潔かつ具体的にまとめましょう。

正解の根拠

CSRF攻撃を防ぐためのトークン（csrftoken）は、正規の利用者が送信したリクエストであることをサーバ側で検証するために使用します。
本問のシステムではトークン自体は発行されているものの、それがどの利用者のものかが検証されていません。悪意のある利用者が自身の正規トークンを用いて別の利用者に意図しないリクエストを実行させる攻撃を防ぐには、サーバ側で管理している利用者IDまたはセッションオブジェクトとトークンをひも付けて検証する必要があります。
したがって、空欄 a，b には「利用者ID」と「セッションオブジェクト」が入ります（順不同）。
順不同で「利用者ID」と「セッションオブジェクト」の両方を答えていれば満点、どちらか一方のみを答えている場合（同じ正解を二つ書いた場合を含む）は半分、正解を一つも答えていない場合（同じ誤答を二つ書いた場合を含む）は0点となります。

正解の根拠

クリックジャッキング攻撃では、利用者を騙すためのコンテンツを配置した罠画面を公開し、その手前に標的サイトの画面を透明にして重ねます。問題文より、画面βは攻撃者が用意した罠の画面であるため、罠サイトに公開する画面 c は「画面β」となります。

各選択肢の解説

• ア (α): 標的となるサイトXの画面であり、罠サイトに直接公開する画面ではないため誤りです。
• イ (β): 攻撃者が用意した罠画面であり、利用者を誘導するために罠サイトに公開するため正解です。

正解の根拠

クリックジャッキング攻撃では、利用者に罠画面を見せつつ、クリックイベントを手前の標的画面で発生させます。問題文よりクリックイベントは手前の画面で発生するため、見せかけの指示を配置する罠画面（画面β）は利用者から見て「奥」に配置します。したがって、d は「奥」です。

各選択肢の解説

• ア (奥): 罠画面βを配置すべき位置であり、手前に透明な標的画面を重ねることで攻撃が成立するため正解です。
• イ (手前): 手前に配置するとクリックイベントが罠画面で発生し、標的サイトを操作させられないため誤りです。

正解の根拠

クリックジャッキング攻撃では、利用者に罠のボタンやリンクをクリックするよう誘導する必要があります。そのため、奥に配置した罠画面（画面β）は利用者から見える状態にしておく必要があります。したがって、e に入る画面βの状態は「可視の」となります。

各選択肢の解説

• ア (可視の): 利用者に罠のコンテンツを視認させてクリック操作を促すため正解です。
• イ (透明な): 罠画面を透明にすると利用者が操作対象を見ることができず、クリックを誘導できないため誤りです。

正解の根拠

クリックジャッキング攻撃では、利用者が意図しない操作を標的サイト上で実行させます。問題文より、サイトXの画面は「画面α」と定義されているため、利用者に不正な操作（更新ボタンの押下など）を行わせる対象として重ねて表示する画面 f は「画面α」です。

各選択肢の解説

• ア (α): 攻撃の標的となるサイトXの画面であり、罠画面の上に重ねて表示するため正解です。
• イ (β): 攻撃者が用意した罠画面であり、重ねて表示される標的側の画面ではないため誤りです。

正解の根拠

問題文に「クリックイベントは，利用者から見て手前にある画面上で発生するものとする」とあります。利用者のクリックによって標的サイトX（画面α）のボタンを押下させるには、画面αを利用者から見て「手前」に重ねて表示する必要があります。したがって、g は「手前」です。

各選択肢の解説

• ア (奥): 奥に配置するとクリックイベントが画面αで発生せず、標的サイトを操作させられないため誤りです。
• イ (手前): クリックイベントを発生させて標的サイトを意図せず操作させるための配置であるため正解です。

正解の根拠

手前に配置した標的サイトX（画面α）が見えたままでは、利用者は罠に気づいてクリックしてくれません。利用者に奥の罠画面βを見せながら、実際には手前の画面αをクリックさせるためには、画面αを「透明な」状態にして重ねる必要があります。したがって、h は「透明な」です。

各選択肢の解説

• ア (可視の): 手前の画面αが見えてしまうと利用者に意図が露見し、奥の罠画面も見えなくなるため誤りです。
• イ (透明な): 奥の罠画面を透かして見せつつ、手前の画面αをクリックさせるために不可欠な設定であるため正解です。

正解の根拠

クリックジャッキングの防止策として、Webページが <iframe> などのフレーム内に読み込まれることを制限するHTTPレスポンスヘッダを利用します。
従来から広く使われている独自の仕様が X-Frame-Options です。一方で、これに代わる機能として標準化されたものが Content-Security-Policy (CSP) の frame-ancestors ディレクティブです。
問題文には「後者は標準化されている」とあるため、空欄iに入るのは標準化される前のヘッダである X-Frame-Options となります。

各選択肢の解説

• ア: ファイルのダウンロード時の振る舞いを指定するヘッダであり、誤りです。
• イ: 標準化されている方（空欄j）に入るヘッダであり、iの箇所としては誤りです。
• ウ: MIMEスニッフィングを防止するヘッダであり、誤りです。
• エ: 正解です。

正解の根拠

クリックジャッキングの防止策として、Webページが <iframe> などのフレーム内に読み込まれることを制限するHTTPレスポンスヘッダを利用します。
従来から広く使われている独自の仕様が X-Frame-Options（空欄i）です。一方で、これに代わる機能として標準化されたものが Content-Security-Policy (CSP) の frame-ancestors ディレクティブです。
問題文には「後者は標準化されている」とあるため、空欄jに入るのは標準化されているヘッダである Content-Security-Policy となり、イ が正解です。

各選択肢の解説

• ア: ファイルのダウンロード時の振る舞いを指定するヘッダ（Content-Disposition）であり、誤りです。
• イ: 正解です。
• ウ: MIMEスニッフィングを防止するヘッダ（X-Content-Type-Options）であり、誤りです。
• エ: 標準化される前の独自ヘッダ（X-Frame-Options、空欄i）であり、jの箇所としては誤りです。

正解の根拠

サイトYのSSRF脆弱性は、外部から与えられたURLに対してサーバがリクエストを送信してしまう問題です。
図4のリクエストにおいて、topic パラメータには https://www.a-sha.co.jp/news/20220417.html というURLが指定されています。攻撃者はこの値を改ざんし、サイトYの内部ネットワークにあるDBサーバにアクセスを試みました。
表2の注1より、サイトYのDBサーバのメンテナンス用WebインタフェースのURLは https://db-y.b-sha.co.jp/ であることが記載されています。したがって、topic の値をこのURLに変更することでSSRF攻撃を成立させています。

高得点のポイント

• 変更対象となるパラメータが「topic の値」であること。
• 変更後の値として、表2から読み取れる正確なURL（https://db-y.b-sha.co.jp/）が指定されていること。

正解の根拠

表4および図6の流れを追うと、攻撃の手順が理解できます。
手順1で、V氏は Host ヘッダの値を「V氏が用意したサイトのFQDN」に変更してリクエストを送信しています。
手順2でサイトZはP社宿泊サイトへリクエストを送りますが、このとき図6の注2にあるように「サイトZは，(1)のHostヘッダの値を，returnURL中のホスト名として指定する」処理を行います。つまり、returnURL にはV氏が用意したサイトのURLが組み込まれます。
手順3で、P社宿泊サイトは登録されていない駅名が入力されたため、returnURL で指定された先へリダイレクト（301）させようとし、Location ヘッダにそのURLを含めます。
したがって、空欄kに含まれるのは V氏が用意したサイト のURLとなります。

高得点のポイント

• 表4の記述に基づいて、「V氏が用意したサイト」というキーワードを過不足なく抜き出せていること。

正解の根拠

設問5(1)で判明したように、今回のSSRF脆弱性の根本的な原因は、サイトZが外部（クライアント）から送信された Host ヘッダの値を信用し、それを基にP社宿泊サイトへ送る returnURL を動的に組み立てている点にあります。
これを防ぐためには、外部から操作可能な入力値を利用せず、サイトZ側であらかじめ決めたエラーページのURLを returnURL として固定的に設定する対策が有効です。

高得点のポイント

• SSRFの原因となっている returnURL の動的生成を廃止し、値を固定化（ハードコード等）する旨が含まれていること。

正解の根拠

（1つ目・2つ目は順不同）
表1「Webセキュリティ管理基準」の項番ごとの管理策を比較します。
項番2（ツールによるソースコードレビュー）、項番3（プロジェクトメンバによるソースコードレビュー）、項番4（ツールによる脆弱性診断）では、いずれも以下の記載があります。

• 「セッション管理の脆弱性は，一部だけが対象である。」
• 「認可・アクセス制御の脆弱性は，対象外である。」

一方で、項番5「専門技術者による脆弱性診断」では、以下のように記載されています。

• 「セッション管理の脆弱性は，対象である。」
• 「認可・アクセス制御の脆弱性は，対象である。」

したがって、ツール等では発見できないが専門技術者の診断で発見できる脆弱性は「一部のセッション管理の脆弱性」と「認可・アクセス制御の脆弱性」の2つです。

高得点のポイント

• 表1の記述を正確に引用または要約し、「一部のセッション管理の脆弱性」または「認可・アクセス制御の脆弱性」のいずれか一方を記述していること。

正解の根拠

（1つ目・2つ目は順不同）
表1の比較から、専門技術者の診断でのみ対象となる脆弱性は「一部のセッション管理の脆弱性」と「認可・アクセス制御の脆弱性」の2つです。これらは業務ロジックや権限の仕様に依存するため、機械的なツールや単純なコードレビューでは発見が困難であり、専門技術者による検証が必要になります。
1つ目の欄と重複しない、もう一方の脆弱性を解答します。

高得点のポイント

• 表1の記述を正確に引用または要約し、1つ目の欄とは異なるもう一方の脆弱性を記述していること。

正解の根拠

図7「B社の開発プロセスの概要」の注記2に、「改良フェーズにおいて、半年に1回、1か月の休止期間を設けている。その間，開発部のメンバは，... Webサイトの点検などを実施している」とあります。
専門技術者による脆弱性診断は期間が「10日間くらいが目安」（表1）であり、通常の2週間周期の改良リリース中に実施することは困難です。しかし、この1か月の休止期間であれば、リリースのスケジュールに影響を与えることなく10日間の診断を実施することが可能です。

高得点のポイント

• 図7で提示されている「改良フェーズにおける1か月の休止期間」という時期を的確に指定していること。

正解の根拠

アジャイル開発では短いサイクル（B社の場合は2週間周期）でリリースを繰り返しますが、専門技術者による脆弱性診断には約10日間の期間が必要です（表1）。
設問6(3)の休止期間だけでは、システムの大規模な変更時などに適切なタイミングで診断を受けられないリスクがあります。そこで、アジャイル開発を継続しつつ専門技術者による診断を組み込むためには、診断が必要なスプリント（回）の改良リリース期間を意図的に長く設定するか、あるいは診断完了を待つためにそのサイクルのリリースを次回に持ち越すといったプロセスの柔軟な見直しが必要です。

高得点のポイント

• 診断に要する日数を考慮し、「リリース期間を長くする」または「リリースを次回に持ち越す」などの具体的な開発プロセスの調整方法が記述されていること。

正解の根拠

Webアプリケーションフレームワークには、開発者が意識せずともデフォルトでセキュリティ対策が有効になる機能（セキュアデフォルト）が備わっていることが多くあります。
CSRF脆弱性への対策の場合、サーバ側で推測困難な トークンを発行 し、それをクライアントに送信する HTML（フォーム）へ自動的に埋め込み、セッション情報との ひも付け を行い、フォーム送信時にその トークンを検証する という一連の定型的な処理が必要です。多くのフレームワークでは、この一連のトークン処理機構がデフォルトで組み込まれています。

高得点のポイント

• トークンの「発行（生成）」、「HTMLへの埋め込み」、「セッション等とのひも付け」、「検証」という一連の処理の流れが網羅されていること。
• 55字以内で処理内容が具体的に説明されていること。