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

解答の論理構成

• 図3の報告(3)には「descriptionパラメタの値を画面Bの備考に出力する際には、エスケープ処理が正しく行われており、XSS脆弱性は認められない。」と記載されています。
  つまり、送信された <script>alert('XSS!')</script> という文字列は、そのままタグとして解釈されないようにエスケープされて応答に埋め込まれている必要があります。
• 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</a>」
   と記載されています。すなわち、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と混同しやすい。今回はリンクを「クリック」した瞬間に実行されることがヒントです。
• 候補「イ」や「ウ」は <script> タグを含むため、ブラウザのHTMLパーサがタグを閉じられる位置を探す必要があり、href属性にそのまま入れても実行されません。
• " を含む文字列を選ぶと ダブルクォーテーションのエスケープ が発生し、クリックによる即時実行には至らない点を見落としがちです。

FAQ

解答の導き方

1. どちらの誤りかを確認する
   図8の診断用URL3は、refURLパラメタに「" onmouseover=alert('XSS!') foo="」を与えて、属性値を引用符で閉じてイベント属性を挿入しようとするものです。しかし図9の出力では、引用符が「"」にエスケープされ、href属性の値の中にとどまっています。つまり、属性値の出力時のエスケープ処理は行われており、引用符で属性を切断する攻撃は成功していません。
2. 残っている問題
   エスケープ処理をしていても、href属性に「javascript:」で始まる文字列を出力すると、リンクをクリックしたときにスクリプトが実行されます。refURLパラメタの値をそのままhref属性に出力しているので、「javascript:alert(…)」のようなURLを与えられると、XSSが成立します。エスケープでは引用符などの記号は無害化されますが、「javascript:」というスキームそのものは無害化されません。
3. 改修方法
   href属性に出力するURLを、「http://」又は「https://」で始まるものだけに限定すれば、「javascript:」スキームによるスクリプトの実行を防げます。

誤りやすいポイント

• 図9の出力を読み落とし、引用符による属性の切断が成立していると考えてしまう。図9では引用符が「"」にエスケープされています。
• 「エスケープ処理を追加する」と答えてしまう。エスケープは既に行われており、それでは「javascript:」スキームを防げません。
• 出力を禁止するスキームを「javascript:」だけに限定してしまう。ほかの危険なスキームもあり得るので、許可するスキーム（http・https）を限定する方が確実です。

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. <script>…</script> のようなHTML内に直接書いたコード（＝インラインスクリプト）
     がいずれも実行できなくなります。
• このうち社内開発で頻出し、呼出し方法を変えるだけで対応できるのは2. です。
• したがって③で確認すべきは「HTMLファイルに直接埋め込まれたスクリプト」。
• 実行させるには、「ファイルとして同一オリジンに配置し <script src=…> で参照する」ように変更すれば、'self' に合致し正常動作が回復します。

誤りやすいポイント

• 'self' を指定すると外部サイトだけが遮断され、インラインは許可されると誤解しやすい。実際には 'unsafe-inline' を付けない限りインラインも遮断されます。
• <script src="//cdn.example.com/…"> のようにプロトコル相対URLを使えば許可されると考えがちですが、オリジンが異なるため拒否されます。
• <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