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

解答の論理構成

1. 表1‐No.3の調査結果には
   “攻撃手法Kに使われる文字列が Web サーバ Xの標準設定では①アクセスログに残らない”
   と明記されています。
2. 一般的な Web サーバ標準ログ（Common Log Format など）は、リクエストライン（メソッド・URL・HTTP バージョン）とヘッダ部までを記録しますが、POST メソッドのボディ部は記録しません。
3. したがって、攻撃者が「特定の文字列」を POST ボディに埋め込んで送信すると、その文字列はログに出力されず、痕跡が残りません。
4. 以上より、“アクセスログに残らない”攻撃とは「攻撃文字列が POST データ内に含まれる場合」であると結論付けられます。

誤りやすいポイント

• GET クエリストリングと混同し、URL パラメタに含まれる場合はログに残る点を見落とす。
• SSL/TLS で暗号化されているから残らないと勘違いする（復号後に Web サーバは平文で受け取り、ログ可能です）。
• サーバのログレベル変更や WAF の影響を過度に考慮し、標準設定という前提を忘れる。

FAQ

解答の論理構成

1. 調査の目的
   • 会話でF氏は“他の形でページが改ざんされている可能性もあるので確認が必要”と述べています。
2. 安全な参照元の条件
   • 表1 No.5 で“WebサイトY”は“外部からのアクセスはなく、改ざんされた痕跡も見付けられなかった。”と判明。
   • さらに本文では“WebサイトXとシステム構成が全く同じWebサイトY”であると明記されています。
3. 比較対象の選定理由
   • 同一構成かつ無改ざんの“WebサイトY”を基準にすれば、改ざん漏れなく効率的に確認できます。
4. 結論
   • 以上より、a には“WebサイトYの全ファイルと比較”が最適となります。

誤りやすいポイント

• バックアップファイルとの比較と書くと、バックアップが改ざんを受けていない保証が本文にないため誤答になります。
• 差分ツールで比較とだけ書くと「何と比較するか」が不明確で減点対象になります。
• ハッシュ値確認のみではファイル選択の根拠が示せず不完全です。

FAQ

解答の論理構成

1. 下線②の原文は
   “F氏は、②SSHの認証方式をパスワード認証方式以外に設定するようDさんにアドバイスした。”
   とあります。
2. その直前でF氏は「SSHサービスに対して辞書攻撃が容易に成功することが確認された」と述べ、 “B社PC-LAN内に攻撃者が侵入できると、WebサイトYに不正にログインできる”
   というリスクを指摘しています。
3. 辞書攻撃が成功する原因は、推測しやすい“パスワード認証方式”を採用しているからです。
4. SSHで辞書攻撃・ブルートフォース攻撃を回避でき、かつ「パスワード認証方式以外」に該当する代表的な方式は、ユーザが保持する秘密鍵とサーバに登録された公開鍵で認証を行う “公開鍵認証方式” です。
5. 以上より、②に設定すべき認証方式は
   公開鍵認証方式
   となります。

誤りやすいポイント

• 「多要素認証」「ワンタイムパスワード」などを挙げる受験者もいますが、SSHの一般設定で簡潔に切り替えられる方式としては“公開鍵認証方式”が最も妥当です。
• “証明書認証”と書くとTLSサーバ証明書と混同されるおそれがあり減点対象になる場合があります。
• SSH‐2ではキーファイルを使った方式が標準であることを忘れ、旧来のrlogin/rshの“ホストベース認証”と誤記するケースがあります。

FAQ

解答の論理構成

1. 背景把握
   問題文には「全社のWebサイトについて脆弱性への対応状況を調査した。その結果、対応漏れがあるWebサイトが5サイト見つかった。」とあります。対応漏れの原因を無くすため、情報システム部が脆弱性情報を一括収集する方針が示されました。
2. 報告項目の目的
   同じ文章で「効率的な情報収集ができるよう、各Webサイト担当者には、bを報告させた。」と指示されています。外部から入手する脆弱性情報を“効率的”に各サイトへマッチさせるには、サイトごとの利用ソフトウェアとそのバージョンを特定する必要があります。
3. 必須要素の抽出
   本文中で脆弱性対象として具体的に挙がっているのは「WF」「プラットフォーム（OSやミドルウェア）」です（例：表1「WF-Kに脆弱性Kが存在」との記述）。したがって、報告すべきは
   • OS
   • ミドルウェア
   • WF
   これらの「名称」と「バージョン」です。名称だけでは該当する脆弱性か判断できず、バージョンだけでなく種類も必要となるため両方を盛り込みます。
4. 解答
   よってbには「Webサイトで使用しているOS、ミドルウェア及びWFの名称並びにそれぞれのバージョン情報」と記載するのが妥当です。

誤りやすいポイント

• ハードウェアやIPアドレス等、脆弱性情報収集に直接不要な項目まで列挙してしまう。
• 「アプリ名」「OS名」だけでバージョンを抜かす。バージョンが分からなければ適用要否を判断できません。
• Webアプリ固有の名称（例：WebアプリX）を報告対象に含める。脆弱性データベースは一般的な製品・OSS単位で公開されるため対象外です。
• WF（Webアプリケーションフレームワーク）を失念する。フレームワークの脆弱性も多く報告されるので必須です。

FAQ

解答の論理構成

• 【問題文】の図4の箇条書きには、
  • “・c トラバーサル”
  • “・d リクエストフォージェリ”
  • “・e ヘッダインジェクション”
  • “・クリック f”
    という未確定語が列挙されています。
• 一般的な脆弱性名称との対応を考えると、
  1. “トラバーサル”と組み合わせる語は “ディレクトリ” が標準表記です（Directory Traversal）。
  2. “リクエストフォージェリ”に冠する語は “クロスサイト” が定訳で、CSRF（Cross-Site Request Forgery）の和訳でもあります。
  3. “ヘッダインジェクション”の前に付く典型は “HTTP” です（HTTP Header Injection）。
  4. “クリック”の後に続く脆弱性語は “ジャッキング” が通例で、クリックジャッキング攻撃を指します。
• さらに、表3でも “（エ）” の脆弱性名が “d リクエストフォージェリ” となっており、ここでも “クロスサイト” を補えば意味が通ります。
• 以上より、
  • c：ディレクトリ
  • d：クロスサイト
  • e：HTTP
  • f：ジャッキング
    が妥当と判断できます。

誤りやすいポイント

• “ディレクトリトラバーサル”を“パストラバーサル”と混同して別語を入れる。
• “クロスサイトリクエストフォージェリ”を“サイト間”などで訳してしまい正式名称を外す。
• “HTTPヘッダインジェクション”を“レスポンスヘッダインジェクション”と誤記する。
• “クリックジャッキング”を“クリックハイジャック”と書く誤表記。

FAQ

解答の論理構成

1. 表4には次の三つのテストケースが掲載されています。
   • No.1　keyword に "bag' and '1'='1" を送信 → 画面表示は 該当商品数： g 件
   • No.2　keyword に "bag' and '1'='2" を送信 → 画面表示は 該当商品数： h 件
   • No.3　keyword に "bag" を送信 → 画面表示は 該当商品数：30件
     （いずれもステータスコードは “200”）
2. 注記として “診断時にDBには商品が100件登録されていた。” とありますが、通常のキーワード "bag" で取得できた件数は “30件” です。したがって bag という条件に一致する商品は 30 件 と分かります。
3. SQLインジェクションを想定すると、アプリ側のSQLは
   sql SELECT ･･･ FROM 商品表 WHERE name LIKE '%%'
   のように単純連結されている可能性が高いです。
   • を "bag' and '1'='1" に置き換えた場合、SQLの WHERE 句は
     name LIKE '%bag' and '1'='1%'
     となり、'1'='1' は常に真ですが name LIKE '%bag' という条件は残ります。
     よって返されるレコード数は、もとの検索と同じ “30件” です。
   • を "bag' and '1'='2" に置き換えると
     name LIKE '%bag' and '1'='2%'
     となり、'1'='2' は常に偽です。AND 条件ですから 全レコードが除外され、結果は 0 件 になります。
4. 以上より
   • g には “30”
   • h には “0”
     を入れると論理が整合します。

誤りやすいポイント

• “DB に 100 件登録” という注記から g = 100 と決めつける。実際にはキーワードで絞り込みが残ることを見落としているケースが多いです。
• '1'='1' を “常に真だから全件ヒットする” と短絡的に考え、WHERE 句全体が無条件になると誤解する。
• LIKE 句やプレースホルダの有無を意識せずに SQL を想像し、条件の残り／消えを判定し損ねる。

FAQ

解答の論理構成

1. 図9には
   var returnobj = window.opener.document.getElementById('i');
   と記載されており、i の値は JavaScript のシングルクォート '...' 内にそのまま埋め込まれます。
2. 埋め込まれた位置は HTML ではなく JavaScript 文字列リテラル内なので、タグ (
3. 文字列を終了させるには ') と書き、次に実行したいコード alert('NG') を入れ、文を区切るセミコロン ; を付けます。
4. 以上を満たす候補は
   ');alert(NG
   だけです（選択肢イ）。他の選択肢は
   • ア・エ：タグが入っているため JavaScript 文字列内では無効
   • ウ：冒頭にクォートと閉じ括弧が無く、文字列を終端できない
     という理由で目的を達成できません。
5. よって i に入る適切な文字列は イ です。

誤りやすいポイント

• HTML タグを挿入するタイプの XSS と同一視し、
• 文字列リテラルの区切り文字（今回は '）を確認せず、ダブルクォートやタグで閉じられると誤解する。
• alert('NG') の後ろに閉じクォートが不要だと考え、文法エラーになるペイロードを選択する。

FAQ

解答の論理構成

1. 表5は「一般会員アカウント」で限定商品を買えてしまう手順を示しています。
   Step2 の説明は「商品一覧画面で j。」と空欄になっています。
2. 商品をカートに入れる処理は、表2の（う）と（え）が同じURL「https://www.z-site.com/kounyu」を使い、送信パラメタだけが異なります。
   • （う）「POSTデータ：code=0001344」
   • （え）「POSTデータ：code=1000021」
3. 限定商品は有料会員専用の「限定商品一覧」からしか選べない設計ですが、URLとパラメタを直接操作できれば制約を回避できます。
4. よって一般会員が「商品一覧画面」から購入リクエスト（う）を送る際に、code パラメタを限定商品の値「1000021」に書き替えれば、サーバ側が区別できず限定商品がカートに入ります。
5. 以上より、j に入る操作内容は「（う）の操作を実行するときに、codeの値を限定商品の値に書き替える」です。

誤りやすいポイント

• （え）の画面遷移そのものを呼び出すと回答してしまう。問題は「商品一覧画面」経由であるため、操作は（う）のリクエスト改変になります。
• URL変更だけを書くと不十分になりがちです。パラメタ code=1000021 への書替えを明示する必要があります。
• 「限定商品一覧画面に遷移する」と誤解するケース。アクセス制御不備の本質はサーバ側の認可チェック不足であり、画面遷移は不要です。

FAQ

解答の論理構成

1. 図10には
   “アクセス制御の不備や認可制御の欠落を確認する場合には、事前に k アカウントを用意し、l を確認する。”
   とあり、k と l を埋める必要があります。
2. 表5では一般会員で操作した際に
   “限定商品を購入できる。”
   という想定外の結果が示されており、手順1には
   “一般会員アカウントでログイン”
   と明記されています。
   これは「権限が異なる」アカウント（一般会員／有料会員）を比較して認可の欠落を検証する典型例です。
3. したがって k には、テストに用意すべきアカウントの性質として “権限が異なる複数の” が入ります。
4. 次に、検証の目的は「有料会員しか操作できない購入手続を一般会員が実行できてしまうか」を確かめることです。
   表5の結果が示すのは「許可されている操作」が会員種別によって異なるはずなのに同じになってしまった点です。
5. 以上より l には、両アカウント間で比較すべき対象として “許可されている操作の違い” が入ります。

誤りやすいポイント

• 認証テストと混同し、“異なるパスワードの有無” など認可とは無関係な観点を l に書いてしまう。
• “複数のテストユーザ” のように k を一般化し過ぎ、権限差があることを示せていない。
• UI 上に表示されるリンクやボタンの有無だけを比較し、実際にリクエストを送って機能を実行できるかどうかを確認しない。

FAQ

解答の論理構成

1. 追加すべき内容は、外部委託先が“レビューを実施した事実と結果”を検収時に示すことです。
2. 【問題文】では、内製時の管理強化策として図11に

   「注意事項：各工程の最後にレビューを行い、作業の妥当性を確認すること」
   と明示し、さらに各工程に
   「レビューポイント：～がテストされていること、適切な診断が実施されていること」
   など“妥当性確認”を求めています。

3. しかし、外部委託では「開発されていることを確認するには工夫が必要」と課題を示し、③で“契約の検収条件”に反映させるよう求めています。
4. 検収条件にレビュー結果提出を義務付ければ、A社側は成果物と併せてレビュー記録を照査し、図11が意図する“作業の妥当性”を客観的に確認できます。
5. 以上から、「作業の妥当性を確認できる詳細なレビュー記録を委託先が提出していること」とするのが適切です。

誤りやすいポイント

• 「テスト結果」や「診断報告書」だけを求めれば十分と勘違いする
  → 図11は全工程でのレビュー実施を要求しており、設計・実装フェーズも対象です。
• 「ソースコード提出」を検収条件に挙げる
  → 妥当性“確認”にはレビューの証跡が不可欠で、コード提出だけでは図11の趣旨を満たしません。
• “レビュー実施の誓約”のような宣言だけで済ませる
  → 客観的証跡がなければ検収時に確認できず、契約条件として不十分です。

FAQ

解答の論理構成

• まず、検出された XSS について「Webセキュリティガイドの記載が抽象的なので、誤った実装をしてしまった」と【問題文】に記載されています。
  → 原因分析がガイド改訂に直結した事実を示しています。
• さらに「Qさんは脆弱性を作り込まないよう Webセキュリティガイドに項目を追加した」とあるように、診断で判明した欠陥を即座にガイドへ反映しています。
• この流れは「各工程でのレビューポイントをWebセキュリティガイドに記載する」取り組みにも発展しており、脆弱性発見→原因特定→注意点追加というサイクルが明確です。
• 以上より、診断で見つかった個々の脆弱性は“原因を調査し、注意すべきポイントとしてガイドへ追加する”形で活用されると導けます。

誤りやすいポイント

• 「見付かった脆弱性を一覧に追加するだけ」と誤解し、原因分析の必要性を落とす。
• ガイド改善＝テスト工程強化と短絡的に結び付け、要件定義・設計へのフィードバックを忘れる。
• “注意点追加”をパッチ適用手順の追加と読み違え、本質的な開発プロセス改善を外してしまう。

FAQ