情報処理安全確保支援士 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

解答の導き方

誤りやすいポイント

• AND と OR を取り違えると誤答する。AND '1'='1' は元の条件を維持するが、OR '1'='1' なら全件（この問題では100件）を返す可能性がある点を区別する必要があります。
• LIKE とワイルドカード（%）の扱いに注意すること。ワイルドカードを不適切に挿入すると文字列リテラルの閉じ方が崩れ、構文エラーになるため、実際にどう埋め込まれているか（% が付くかどうか）を意識して考える必要があります。
• 入力値がエスケープ済み、あるいはプレースホルダ（パラメタ化）で処理されている場合はこの種の注入は起きないため、観測結果（件数の変化）を手がかりに「注入が有効か」を判断すること。
• 自動診断ツールは表示件数などの差分から判定することが多い点を理解しておくと、表の数値が何を意味するか把握しやすくなります。

FAQ

解答の導き方

1. 注目すべき箇所を確認します。図8のURLは「https://www.z-site.com/calendar?inputfieldid= i」で、図9の該当コードは「var returnobj = window.opener.document.getElementById('i');」とあります。つまり、アドレスバーのinputfieldidの値が、getElementByIdの単一引用符で括られた引数部分にそのまま埋め込まれます。
2. ここで実行したいのはポップアップ側のスクリプト内でJavaScriptを実行させ、警告ダイアログに "NG" を出すことです。埋め込まれた文字列をそのまま表示させるだけではなく、スクリプトとして動かすには「単一引用符で囲まれた文字列リテラル」を破ってJavaScriptの文を挿入する必要があります。具体的には、まず開いている文字列を閉じる「'」と、getElementByIdの呼び出しを終える「)」が必要で、その直後に実行したい文（alert('NG')）を置く、という手順になります。
3. 選択肢を比較します。実行に必要な「文字列の終了 → 関数呼び出しの終了 → alertの呼び出し」という流れを作れるのは、先頭が「')」で始まりかつalertを含むものだけです。選択肢イは「');alert('NG」で、先頭に「')」がありalertを含んでいます。他の候補は以下の理由で不適切です。
   • ア／エ：いずれも<script>タグを挿入する形で、これはHTMLとして挿入される場面（例えばinnerHTML）で有効ですが、ここはJavaScriptの文字列リテラル内なのでそのまま実行されません。
   • ウ：先頭が「'alert(...」となっており、開いた文字列を閉じる「'」で始まっていません（文字列を閉じた上で ) を付ける必要があるため、文の分離・実行ができません）。
4. 挿入のイメージを示します。もとの行に選択肢イを入れると、次のようになります。
   var returnobj = window.opener.document.getElementById('');alert('NG');
   getElementById('')の呼び出しが終わった直後に alert('NG'); という文が続き、末尾の「');」は図9にもともとある部分がそのまま使われます。構文として正しいJavaScriptになるので、ポップアップのスクリプト実行時に警告ダイアログが出ます。以上より、正しい選択は選択肢イです。

誤りやすいポイント

• 「<script>を入れれば実行される」と考える誤り：スクリプトタグ挿入型はHTMLコンテキストでの攻撃で、今回のようにパラメータがJavaScriptの文字列リテラル内に埋め込まれている場合は効かないことが多いです。
• 文字列の開始／終了の扱いを見落とすこと：getElementByIdの引数が '...' で囲まれている点（シングルクォート）を見落とすと、どのように抜け出せばよいか判断できません。
• URLエンコードを忘れること：実際に攻撃文字列をURLに入れる際には特殊文字を適切にエンコードする必要がある点を見落としがちです（試験では選択肢そのままの比較で判断します）。

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