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

解答の論理構成

• 【問題文】では、検知方法1を「攻撃コードとして、スクリプトに相当する文字列を含めたリクエストをサーバに送信したときに、その文字列がレスポンス中にスクリプトとして出力されるかどうかで判断する方法」と説明しています。これはサーバから返るレスポンスを解析して XSS を判定する手法です。
• 一方、【図04】にある「脆弱性2：検索ページで使用されるスクリプトに DOM-based XSS が存在する。攻撃者が “#” から始まるフラグメント識別子に攻撃コードを記述できる。」とあるとおり、脆弱性2は DOM‐based XSS であり、ブラウザ内の JavaScript がクライアント側でフラグメント識別子を解析して悪意あるコードを生成します。
• DOM‐based XSS は「サーバレスポンスの内容」に変化を与えません。したがって「①検知方法1では脆弱性2を検知できない」となる理由は、サーバ応答だけを見ても反映される違いがないためです。
• 以上より、模範解答の「脆弱性の有無によってサーバからのレスポンスに違いがないから」となります。

誤りやすいポイント

• 通常の反射型 XSS と DOM‐based XSS を混同し、「フラグメント識別子もサーバに送られる」と誤解する。
• 検査ツールがクライアント側で DOM を解析していると想定し、「検知できるはず」と判断してしまう。
• 「WAF なら必ず DOM‐based XSS も遮断できる」と思い込み、原因をレスポンスの不変性ではなく WAF の設定に求めてしまう。

FAQ

解答の論理構成

• 【問題文】では「脆弱性2は、検索ページで使用されるスクリプトに DOM-based XSS が存在する。攻撃者が “#” から始まるフラグメント識別子に攻撃コードを記述できる。」と説明しています。DOM-based XSS はクライアント側のスクリプトが location.hash などを取り込み、動的に HTML を生成することで発生します。
• さらに「②Rポータルへのアクセスを繰り返すことなく、脆弱性2の有無を分析する方法」があると記載されています。DOM-based XSS はサーバから返されるレスポンス内容を変化させないため、【問題文】で示された「攻撃コードを含んだリクエストを送り、レスポンス中を確認する」という“検知方法1”や WAF では検知できません。
• したがって、有効なアプローチはクライアント側 JavaScript の静的／動的解析です。攻撃者は対象ページのスクリプトファイルを取得し、location.hash や document.URL の値を DOM に書き込む処理がないかを確認します。
• スクリプトをローカルで解析すればネットワーク越しに「Rポータルへのアクセスを繰り返す」必要がありません。
• 以上より模範解答「スクリプトを分析し、フラグメント識別子の値の変化による挙動を確認する。」となります。

誤りやすいポイント

• 検知方法1・WAFが役に立たない理由を「サーバに届かないから」と言及せず、単に「DOM-based XSS だから」とだけ覚えてしまう。
• 動的にページを表示してブラウザの開発者ツールで確認する方法を“繰り返すアクセス”だと誤認し、静的解析の意図を取り違える。
• フラグメント識別子（# 以降）が HTTP リクエストに含まれないことを忘れ、サーバログで検知できると考えてしまう。

FAQ

解答の論理構成

• 【問題文】では、XSS対策として「③Rポータルの動作に影響が出ないことを確認した上で、Cookieの発行時にHttpOnly属性を付与する」とあります。
• 【問題文】で「Rポータルはセッション管理をCookieで実現している」と明記されています。
• HttpOnly 属性を付与した Cookie はブラウザの document.cookie などクライアント側スクリプトからは参照できません。
• したがって、Rポータルがクライアント側スクリプト（JavaScript 等）で Cookie の値を読み取り、画面表示や機能制御を行う実装を採っている場合、そのスクリプトは Cookie を取得できず動作に支障が出ます。
• 以上より、動作に影響があるのは「Rポータルが利用しているスクリプトがCookieの値を利用している場合」と結論付けられます。

誤りやすいポイント

• HttpOnly を付けると「サーバも Cookie を読めなくなる」と誤解する。実際にはサーバ側処理には影響しません。
• 「セッション管理を Cookie で行っているなら必ず影響が出る」と早合点する。サーバのみで参照する設計なら影響はありません。
• 「SameSite」や「Secure」など他の属性と混同し、質問の焦点を外してしまう。

FAQ

解答の論理構成

1. 【問題文】には「共通管理者アカウントが正しく利用されていることが確認できる証跡は取得している」と明記されています。
2. どの機能で証跡を残しているかは、同じ段落に続く次の記述が根拠です。
   • 「踏み台サーバには操作記録機能があり、ログインした利用者のデスクトップ画面が数秒間隔で画像データとして記録され、実行したコマンドやキーボード入力がテキストで記録される。」
3. したがって、証跡を取得するのは「踏み台サーバの操作記録機能」であり、取得内容は「デスクトップ画面」「実行コマンド」「キーボード入力」の3種類です。
4. 以上をまとめると、模範解答のとおりとなります。

誤りやすいポイント

• 操作ログを出力しているのは各サーバではなく「踏み台サーバ」だと読み落としやすい。
• 証跡に含まれる要素を「ログイン履歴」だけと誤解し、デスクトップ画面やキーボード入力を省いてしまう。
• 「操作記録機能」という語を別の表現に置き換えると原文引用の要件を満たさなくなる。

FAQ

解答の論理構成

1. 追加ルールの目的を整理
   • 検討中の案2では「DBサーバをサーバセグメントに移動」し、FWで必要通信のみを許可するとあります。
   • さらに会話には「DBサーバへの通信を業務上必要なものだけに限定する案」と明記されています。
2. どの通信が“業務上必要”かを確認
   • 【問題文】には「WebAPサーバとDBサーバはODBC（Open Database Connectivity）を用いて特定のポート間で通信している」とあります。
   • よって、WebAPサーバ → DBサーバ の ODBC通信だけを許可すれば十分です。
3. 表5の a〜c の決定
   • 送信元は WebAPサーバ → a = “WebAPサーバ”
   • 宛先は DBサーバ → b = “DBサーバ”
   • サービスは ODBC → c = “ODBC”
4. 既存FWルールで不要になるものを洗い出す
   • DBサーバが DMZ からサーバセグメントへ移動すると、利用者セグメント（運用管理PC を含む）から DBサーバ への直接SSH通信は“原則禁止”に変わります。
   • 表4を確認すると、運用管理PC → DBサーバ の SSH を許可しているのは「項番 9」です。
   • よって案2採用時に不要となるのは「9」。
5. 以上より
   • a：WebAPサーバ
   • b：DBサーバ
   • c：ODBC
   • ルール：9

誤りやすいポイント

• 「運用管理PC からの SSH は保守作業だから残す」と判断しがちですが、案2では「利用者セグメントからのアクセスを禁止」と述べられており残せません。
• ODBC を “SQL” や “TCP” と書き換えてしまうミス。問題文の「ODBC」をそのまま引用する必要があります。
• 送信元・宛先を逆にする取り違え。DBは受信側、WebAPは送信側です。

FAQ

解答の論理構成

1. 【問題文】では、DBサーバに対する基準を「“DBサーバには、システム運用課員によるログインと、WebAPサーバからの接続だけが許可されている。”」と明記しており、運用課員以外のログインは原則禁止です。
2. 案2でDBサーバをサーバセグメントへ移動すると、同セグメントのサーバは表3のアクセス許可を受ける対象になります。
3. 表3「項番1」は「“人事総務課の一部の職員のPC” → “踏み台サーバ”」のリモートデスクトップ接続を許可し、 表3「項番3」は「“踏み台サーバ” → “サーバセグメントの全てのサーバ”」を「“サーバの共通管理者アカウントによる認証”」で許可しています。
4. したがって、人事総務課の職員は
   (1) 自席PCから管理IDで踏み台サーバへログインし、 (2) そこから共通管理者アカウントでDBサーバへリモートデスクトップ接続が可能になります。
5. この経路は「システム運用課員以外のログイン」を許してしまい、基準に反するため、M主任は⑤で「“DB サーバに関して R 団体のセキュリティ対策基準に違反するおそれ”」と指摘しました。
6. 以上より、違反行為は「人事総務課の職員が踏み台サーバを経由し、共通管理者アカウントでDBサーバにログインする」こととなります。

誤りやすいポイント

• 「共通管理者アカウント」ではなく「管理ID」でDBサーバに入ると誤読する
• DBサーバがDMZにある現状を前提にし、サーバセグメント移動後のルール適用を見落とす
• 表3「項番3」の“サーバセグメントの全てのサーバ”にDBサーバが含まれることを見逃す
• 違反主体を「システム運用課員」としてしまい、基準違反でないケースを答えてしまう

FAQ

解答の論理構成

1. 会話の前提
   • M主任は案2に対して「⑤DB サーバに関して R 団体のセキュリティ対策基準に違反するおそれ」があると指摘し、 「案2を採用する場合は、検出事項dの対策と併せて実施する必要がある。」と述べています。
2. “セキュリティ対策基準に違反するおそれ”の内容
   • R団体の基準では「DBサーバには、システム運用課員によるログインと、WebAPサーバからの接続だけが許可されている。」と記載されています。
   • 案2では DBサーバをサーバセグメントに移動するため、サーバセグメントで運用されている “共通管理者アカウント” が DBサーバにも適用される可能性が生じます。
3. “共通管理者アカウント”に関する検出事項を特定
   • 検出事項の一覧（図3）より、 「検出事項2：踏み台サーバを除く全てのサーバの管理者用アカウントに、共通管理者アカウントが使用されている。」
     が該当します。
4. 論理的な結び付け
   • 「共通管理者アカウント」が DBサーバに適用されれば、基準が求める “システム運用課員による個別ログイン” が担保できず、⑤の“違反するおそれ”につながります。
   • よって、案2を採用する場合に併せて実施すべきなのは「検出事項2」の対策です。
5. 結論
   • d に入る番号は「2」となります。

誤りやすいポイント

• 「DMZからサーバセグメントへ移動＝安全向上」と早合点し、アカウント管理面のリスクを見落とす。
• 検出事項3を“ネットワーク配置”の問題とだけ捉え、アカウント共通化の問題（検出事項2）と切り離して考えてしまう。
• “システム運用課員によるログイン”の要件を「踏み台サーバ経由なら良い」と誤解し、共通アカウント使用でも基準を満たすと判断してしまう。

FAQ

解答の論理構成

1. 会話文の確認
   本文には次の記述があります。
   「Nさん：第一に、製作パートナが使用している図面アプリなど、機密モードで起動できるアプリケーションソフトウェアを確認する必要があります。第二に、eを確認する必要があります。」
2. コンテナ方式の仕組みの再確認
   図7の説明より、コンテナ方式では
   ・「プロトタイプ製作の契約ごとに、R団体は、必要な数のCCIを製作パートナにメディアで渡す。」
   ・「CCIには、CCごとの識別情報が組み込まれている。」
   ・「同一のCCを複数台のPCにインストールしても…最初にコンテナドライブにアクセスした1台だけ」が有効
   という特性があります。
3. なぜ “CCIの数” を確認するのか
   • CCIを多く渡しすぎると、製作パートナ側で想定より多くの端末が機密モードを利用でき、不正持ち出しのリスクが増大します。
   • 逆に不足すると、業務が回らなくなるため事前確認が必須です。
4. したがって、［　e　］には「製作パートナに渡すCCIの数」を入れるのが最も自然であり、本文の要件とも整合します。

誤りやすいポイント

• 「利用者IDの数」や「PCの台数」を答えてしまう
  → CCIは端末登録とひも付くため、単にPC台数やID数を尋ねても管理は不十分です。
• 「コンテナサーバへの同時接続数」と解釈する
  → 同時接続数はCCIの数と必ずしも一致せず、運用設定で変更可能です。
• DRM方式と混同して「DRM対応アプリの有無」と記載する
  → 会話で第一に確認すると述べている事項なので重複します。

FAQ

解答の論理構成

1. コンテナ方式の特徴
   • 問題文では「PCはコンテナサーバだけにアクセスできる。それ以外のインターネット、ネットワークにはアクセスできない。」とあり、ネットワーク経由で図面ファイルを外部に送るのは困難です。
   • さらに「PCはコンテナドライブ以外、つまりPCの他のドライブや外部記憶媒体にはアクセスできない。」ため、USB メモリなどの記憶媒体で持ち出すこともできません。
2. 不正行為の目的
   • 会話中の前提は「海外の第三者（以下、協力者という）に有効期限内のS図面又は図面を渡す」という持ち出し行為です。
3. 不正行為の実現手段の検討
   • ネットワークも外部記憶媒体も利用不可なので、残る手段は“物理的に PC そのものを運ぶ”ことになります。
   • 既に CC がインストール済みで「最初にコンテナドライブにアクセスした1台だけがコンテナドライブにアクセスできる」という制約を逆手に取り、その1台を協力者に渡せば協力者は図面を閲覧できます。
4. 空欄 f への適切な記述
   • 以上より、コンテナ方式における不正行為は「CC をインストールした PC を協力者に送る」ことになるため、模範解答の
     「CCをインストールしたPCを協力者宛てに輸送」
     が導かれます。

誤りやすいポイント

• 外部記憶媒体へのコピーを想定してしまう
  「外部記憶媒体にはアクセスできない。」という制限を見落とすと USB や DVD での持ち出しを書いてしまいます。
• ネットワーク経由での送信を想定してしまう
  「PCはコンテナサーバだけにアクセスできる。」ためメールやクラウド転送は使えません。
• CC 未インストール PC を送ると誤記する
  CC がインストールされていなければ協力者は認証ダイアログすら表示できず、目的を達成できません。

FAQ

解答の論理構成

1. 脅威の整理
   • 会話文で、攻撃者が「海外の第三者」に有効期限内の“S図面”を渡す不正行為を想定しています。
   • 原文では「DRMサーバは、R団体のDMZ上に設置」され、「S図面」を開く際に「PCとDRMサーバとの間で通信」が必須と記されています。よって、第三者が図面を閲覧するには必ずDRMサーバへ到達する必要があります。
2. 防御ポイントの抽出
   • M主任が「いずれの方式でも、このような不正行為への技術的対策としては、FWでの対策が効果的」と述べ、続けて「例えば、DRM方式であれば、FWでgことができる」と示唆しています。
   • DRM方式はサーバ側で「利用者の認証機能や、利用者の図面へのアクセスを制御」する仕組みですが、通信経路を制限することで“第三者の地点からのアクセス”自体を遮断できます。
3. 具体策への落とし込み
   • 不正行為の起点は「製作パートナの従業員」です。従業員本人または外部協力者が社外からアクセスしようとした場合、「製作パートナの社内ネットワークで用いられている正当なグローバルIPアドレス以外」からの通信を遮断すれば、DRMサーバは到達不能となります。
   • したがってgには「DRMサーバへの通信を製作パートナのグローバルIPアドレスからだけに制限する」という“送信元IPアドレスによるファイアウォール制限”が最適解となります。

誤りやすいポイント

• 認証強化と混同し、ワンタイムパスワードや多要素認証を答えてしまう。設問は「FWでできる対策」に限定されています。
• ポート番号やプロトコル（HTTPS限定など）のみを制限すると、攻撃者も同じポートを使うため実効性が低い点を見落としやすい。
• 送信先（DRMサーバ側）のIP制限と勘違いし、「DRMサーバのIPアドレスを限定」などと書くミス。設問は送信“元”を制限する趣旨です。

FAQ