情報処理安全確保支援士 2021年 秋期 午後2 問01

解答の論理構成

• 図3の報告(3)には「descriptionパラメタの値を画面Bの備考に出力する際には、エスケープ処理が正しく行われており、XSS脆弱性は認められない。」と記載されています。
  つまり、送信された という文字列は、そのままタグとして解釈されないようにエスケープされて応答に埋め込まれている必要があります。
• HTMLにおけるタグ開始文字 < とタグ終了文字 > を画面に表示させるための代表的なエスケープは
  • < → <
  • > → >
  の2つです。どちらも4文字で構成されます。
• 図5の該当箇所は「備考： ascriptbalert('XSS!')a/scriptb」という書式で示され、script と /script の前後に4文字のエスケープシーケンスが入ることが想定されています。
• 以上より、 a には「<」、 b には「>」
  が入るのが妥当です。

誤りやすいポイント

• < と > の末尾セミコロンを忘れて &lt や &gt としてしまう。
• &lt; など二重エスケープをしてしまい、表示結果が <script> になる。
• < と > を全角文字で書いてしまい4文字に収まらなくなる。
• 「4字」という条件から短絡的に < や > そのものを記入してしまう。

FAQ

解答の論理構成

1. 図7のHTTPレスポンスには
   「参考URL：<a href="c">c」
   と記載されています。すなわち、c が href属性の値にもリンクテキストにもそのまま出力 されています。
2. 図3(4)には、 「診断用URL2を入力した時に表示された画面B上で、参考URLのリンクをクリックすると、“XSS!”という内容のダイアログボックスが表示された。」
   とあります。クリック時に JavaScript が実行されたことが分かります。
3. クリックだけでスクリプトを実行させる最も単純な方法は、javascript: スキームを用いて リンク先をスクリプトにする ことです。
4. 解答群を確認すると、エ：javascript:alert('XSS!') だけが
   ・javascript: スキームを持つ
   ・alert 関数を呼び出し “XSS!” というダイアログを表示する
   という条件を同時に満たします。
5. したがって、図6・図7の c に入る文字列は 「javascript:alert('XSS!')」、すなわち 解答群エ です。

誤りやすいポイント

• onmouseover など イベントハンドラ属性 でのXSSと混同しやすい。今回はリンクを「クリック」した瞬間に実行されることがヒントです。
• 候補「イ」や「ウ」は を探す必要があり、href属性にそのまま入れても実行されません。
• " を含む文字列を選ぶと ダブルクォーテーションのエスケープ が発生し、クリックによる即時実行には至らない点を見落としがちです。

FAQ

解答の論理構成

• 問題文では、図3の報告(5)で「refURLパラメタの値を画面Bの参考URLのリンクとして出力する際の処理に問題があり、XSS脆弱性が存在すると認められる。」と指摘しています。
• 図8・図9の例のように、refURL にスクリプトを仕込むとリンクの href 属性 内でイベント属性が挿入され、ブラウザが実行してしまいます。
• この脆弱性は「HTMLタグの属性値の出力時に必要な処理が行われていない」（図3 (6)）ことが原因です。
• 属性値に利用可能な文字列を「http:// または https:// で始まる正しい URL だけ」に限定すれば、" や空白などの制御文字を含む不正値を排除でき、悪意あるスクリプトは挿入できません。
• したがって、改修方法は「http:// 又は https:// で始まる URL だけを出力するようにする」となります。

誤りやすいポイント

• 「エスケープ処理だけで十分」と考え、入力値の妥当性検証を実装しない。属性値の場合はエスケープ漏れが起こりやすいです。
• javascript: スキームの禁止を忘れる、あるいは部分一致で判定し httpss 等の偽装を許してしまう。
• アンカータグ本文のみをサニタイズし、href 属性のチェックを怠る。

FAQ

解答の論理構成

• 問題文では、XSS対策の二つ目として“Content-Security-Policy：　script-src 'self';”を付加し、Webブラウザに対し「②指定したスクリプトファイルの実行だけを許可する」と記載されています。
• 'self' は Content-Security-Policy（CSP）のキーワードであり、【仕様上】“現在表示しているページと同じオリジン（スキーム＋ホスト＋ポート）に属するリソースのみを許可する”ことを意味します。
• よって、実行が許可されるのは「アクセス中のページと同一オリジンのサーバに置かれたスクリプトファイル」です。
• 以上より、模範解答「URLと同じオリジンであるスクリプトファイル」となります。

誤りやすいポイント

• 'self' を「自サイトに置いた全ファイル」と広く捉え、CDN など別ドメインのスクリプトまで許可されると誤解しやすい点。
• script-src 'self' はインライン JavaScript をデフォルトでブロックすることを忘れ、インラインスクリプトも許可されると勘違いするケース。
• “同一ドメイン”と“同一オリジン”を混同し、ポート番号の違いを見落とすミス。

FAQ

解答の論理構成

• 対策②では、HTTPレスポンスに“Content-Security-Policy：　script-src 'self';”を付加し、【問題文】のとおり「②指定したスクリプトファイルの実行だけを許可」します。
• 'self' だけを許容すると、
  1. オリジン外部の JavaScript
  2. のような HTML 内に直接書いたコード（＝インラインスクリプト）
  がいずれも実行できなくなります。
• このうち社内開発で頻出し、呼出し方法を変えるだけで対応できるのは 2. です。
• したがって③で確認すべきは「HTMLファイルに直接埋め込まれたスクリプト」。
• 実行させるには、「ファイルとして同一オリジンに配置し

誤りやすいポイント

• 'self' を指定すると外部サイトだけが遮断され、インラインは許可されると誤解しやすい。実際には 'unsafe-inline' を付けない限りインラインも遮断されます。
• <img onerror=…> などイベント属性に埋めた JavaScript もインライン扱いである点を見落としやすい。

FAQ

解答の論理構成

1. 問題文には
   「クラウドサービスのためのdの実践の規範であるISO/IEC 27017」
   とあります。
   ISO/IEC 27017 は “Code of practice for information security controls for cloud services” を正式名称としており、キーワードは「情報セキュリティ管理策」です。よって
   d ＝「ウ：情報セキュリティ管理策」
   となります。
2. 続けて
   「パブリッククラウドにおけるeの実践の規範であるISO/IEC 27018」
   とあります。
   ISO/IEC 27018 は “Code of practice for protection of personally identifiable information (PII) in public clouds” を正式名称としており、キーワードは「個人情報保護」です。したがって
   e ＝「ア：個人情報保護」
   となります。
3. 解答群の残りの語句
   ・「イ：システム監査」
   ・「エ：審査及び認証」
   は、ISO/IEC 27017・27018 の主題と合致しないため除外できます。

誤りやすいポイント

• ISO 番号と対象領域を混同し、「27017＝クラウド個人情報保護」と覚えていると逆転選択をしやすいです。
• 「審査及び認証」をキーワードに選びたくなりますが、ISO 規格の“コード・オブ・プラクティス”は管理策・保護策を示す指針であり、審査そのものをテーマにはしていません。
• システム監査は ISO/IEC 27017・27018 とは直接の関連がないため、監査という言葉に引きずられないよう注意が必要です。

FAQ

解答の論理構成

1. 事実の整理
   • 本文には「F国では安全保障上の要請があれば、F国内に保存されているデータを、F国政府に強制的に提出させる国内法が存在する。」とあります。
   • さらに下線④で「Gサービスを経由して協力会社との間で受け渡すファイルの内容を保護するという観点で、どのような措置が当社として取り得るか」と問われています。
2. リスクの特定
   • Gサービスのストレージに平文で保存すると、G社やF国政府が鍵なしに内容を閲覧できるリスクがあります。
   • 「ファイルを削除しても、Gサービス上のストレージに情報が残る可能性がある」（表2）ことも示され、保管中の暗号化が必須です。
3. 求められる要件
   • 保護対象はファイル「内容」であり、G社やF国政府が取得しても閲覧できない状態にする必要があります。
   • したがって暗号鍵はU社側が管理し、クラウド事業者が保持しない形が望ましいです。
4. 措置の導出
   • 上記要件を同時に満たす手段は「アップロード前にU社管理の鍵で暗号化」以外ありません。
   • これによりクラウド側には暗号化済みデータしか置かれず、鍵を保持しないG社やF国政府は復号できません。
5. 結論
   • 「ファイルをU社が管理する鍵で暗号化してからアップロードする」となります。

誤りやすいポイント

• 「日本国内だけのデータセンタに保管させる」と回答する誤り
  （F国側データセンタにも保存されるサービス仕様のため実現不能）
• 「契約で提出拒否を定める」と回答する誤り
  （国家法による強制提出に契約条項は対抗できません）
• Gサービスの「自動暗号化機能」を根拠にする誤り
  （鍵が「G社が管理」なので閲覧リスクを解消できません）

FAQ

解答の論理構成

1. 問題文では攻撃手法を
   「表4　項番1　不正アクセスの方法：『利用者IDを固定して、パスワードを総当たりする。』」
   と説明しています。
2. これに対し検知方法として
   「一定時間当たりの f の回数がしきい値を超えたら、不正アクセスとして検知する。」
   と記載されています。
3. 固定された利用者IDに対し繰り返しパスワードを試すブルートフォース攻撃では、一つの利用者IDでログイン失敗が連続します。
4. 従って、しきい値判定に用いるべきメトリクスは「同一利用者IDで発生したログイン失敗回数」です。
5. 以上より、f に入る語句は
   「同一利用者IDでのログイン失敗」
   となります。

誤りやすいポイント

• 「ログイン試行回数」だけでは成功を含む場合があり検知精度が下がります。
• 「同一IPアドレスでのログイン失敗」と混同しがちですが、表4 項番1 は“利用者IDを固定”する攻撃を対象としているため利用者ID基準で考える必要があります。
• 「パスワード誤り回数」など結果を限定せず記述すると、成功・失敗が混在し曖昧になります。

FAQ

解答の論理構成

1. 【問題文】では、表4の「項番2」において
   「一定時間当たりの同一IPアドレスからの異なる利用者IDによるログイン失敗の回数がしきい値を超えたら、不正アクセスとして検知する。」
   と記載されています。
2. すなわち検知条件は「同一IPアドレス」という一点に依存しています。
3. 攻撃者が IP アドレスを切り替えながら試行すれば、①短時間に試行しても各 IP ごとの失敗回数がしきい値を下回り、②SIEM が閾値超過を検知できません。
4. したがって「ほかの場合」とは、攻撃者がアクセス元 IP アドレスを順次変更して総当たりを継続するケースであり、結論は
   「アクセス元IPアドレスを変えながら、不正アクセスを続けた場合」
   となります。

誤りやすいポイント

• 「少数のパスワード」「利用者IDを総当たり」に気を取られ、IP アドレス条件の弱点を見落としやすいです。
• 「ゆっくり実行」＝時間間隔だけと誤解し、IP ローテーションという手口を連想できない受験者が多いです。
• しきい値超過のロジックを“累積失敗回数”と解釈し、IP 依存という本質を外す失点が頻発します。

FAQ

解答の論理構成

1. 問題文では、FIDO 認証のメッセージ列 (3)～(5) にオリジンが含まれる理由を T さんが説明しています。
   引用︓
   「攻撃者が、gするための特別なサーバをインターネット上に用意し…という攻撃を防御するため」
2. 攻撃者が立てるサーバの目的は、利用者と真正の「Kサービス」の間に入り込み、やり取りを代理で転送しながら認証情報を盗むことです。これは “リレー攻撃” や “中継” 型フィッシングの典型です。
3. オリジンをハッシュに含めて署名させることで、Kサービス側は「届いたメッセージが自分の正当なオリジンで生成されたか」を検証できます。中継サーバは自分のオリジンでしか署名を作れないため、検証に失敗して攻撃は成立しません。
4. よって g には「メッセージをKサービスとの間で中継」と入れると整合します。
5. 20 字以内という要件にも適合し、攻撃の意図と防御策が明確になります。

誤りやすいポイント

• 「オリジン偽装」「なりすまし」など抽象的に書き、実際に何をするサーバかを示せず減点される。
• 「MITM（中間者攻撃）」とだけ書いて具体性を欠く。設問は“何をするためのサーバか”を問うているので「中継」が必須。
• 「Kサービス」を別の表記（例：Ｋサービス、kサービス）にしてしまい固有名詞の引用ルール違反となる。

FAQ

解答の論理構成

1. [問題文] 表5には
   “スマートフォン…生体認証装置による生体認証”、 “OS 内蔵…生体認証機能による生体認証”
   と明記されています。表7で “認証器の使用時にhが必要” とあるのは、この生体認証を指すので h＝生体認証 となります。
2. 退職時の操作対象は IDaaS 側のアカウントです。
   [問題文] “IDaaSとの連携…国内…複数のデータセンタで運用されているKサービス” とあり、表6の “Kサービスにおける取扱い” も該当します。したがって “退職時又は退職後直ちに、iでは…” の i は Kサービス に他なりません。
   さらに不正アクセス防止の具体的操作は “利用を完全に断つ” こと、すなわち アカウントを削除 です。よって j＝アカウントを削除。
3. USB 接続外部認証器の行には “第三者による不正利用を防ぐために、直ちにkする必要がある。” と記されています。不正利用を防ぐ最速手段はアカウントを使えない状態にすることなので k＝アカウントを無効に が妥当です。

誤りやすいポイント

• 表5の“生体認証”と表7のhとの対応を見落とし、PIN やパスワードと誤記する。
• 退職時の操作対象を Gサービスと勘違いし、i に Gサービスを入れてしまう。
• j と k を入れ替え、“無効化”と“削除”を逆に答えてしまう。
• USB 接続外部認証器の対策を “認証器を回収” と物理的措置だけで済むと誤解する。

FAQ

解答の論理構成

1. 利用規約の継続
   – 本文に「Gサービスへの移行について、Dシステムの利用規約の継続を前提として」とある。
2. 重要な規約内容
   – 「Dシステムには、ファイル受渡し用PCからだけアクセスすることを求めている。」という制限が明記されている。
3. 認証器ごとのアクセス経路
   – 表6で、 ・「スマートフォン」は〈Bluetooth接続〉で PC と分離され、所有者も「各協力会社又は利用者個人」。
   ・「OS 内蔵の生体認証機能」は「ファイル受渡し用PCが認証器を兼ねる」。
   よってスマートフォンは PC 以外からも利用できるが、OS 内蔵方式は物理的に PC 以外からの認証が不可能。
4. Yさんの判断
   – 下線⑥で「Dシステムで要求されていたセキュリティ要件を技術的に実現できるので、OS内蔵の生体認証機能の方が望ましい」と述べ、要件＝“PC限定アクセス” を満たすことを理由としている。
5. したがって「Gサービスへのアクセスを、ファイル受渡し用PCからのアクセスだけに限定できるから」という模範解答となる。

誤りやすいポイント

• 「生体認証だから安全」という理由に終始し、“PC限定” という根本要件を見落とす。
• スマートフォンでも PC 近傍なら問題ないと思い込み、外出先からのアクセス可能性を軽視する。
• 表6の「認証器の所有者」欄を読み飛ばし、管理範囲の違いを把握できない。

FAQ