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

解答の論理構成

1. 【問題文】では、対象ログを「ステータスコードが200」かつ「応答のサイズが通常のアクセス時と比較してa」と条件づけています。
2. 表2を見ると /GoodsDetail について
   • 通常アクセス（番号「12」）の応答サイズは「1,798」バイト
   • インジェクションを含むリクエスト（番号「14」）の応答サイズは「1,806」バイト
     となっており、ほぼ同じサイズです。
3. 解答群で“ほぼ同じ”を表すのは「ウ：95〜105%」。よって a＝ウ。
4. 条件を満たすログ番号は「ステータスコード200」「応答サイズほぼ同じ」を同時に満たす番号「14」。解答群では「ク：14」が対応します。
5. 以上より
   • a：ウ
   • b：ク

誤りやすいポイント

• 応答サイズが「小さい」「大きい」と早合点し、「ア：6%未満」「エ：200%以上」を選んでしまう。実際には約0.4%の差で“ほぼ同じ”に該当します。
• 番号「7」や「11」もインジェクション文字列を含みますが、通常リクエスト（番号「4」「8」）と比較したときに“ほぼ同じ”かどうかを確認せずに選んでしまう。
• ステータスコードが200であることを失念し、500エラーの「13」を選択してしまう。

FAQ

解答の論理構成

1. 攻撃者は、携帯サイトの「表2　携帯サイトのアクセスログ（抜粋）」に示されるように
   「/Catalog」「/GoodsSearch」「/GoodsDetail」など複数画面へ典型的な SQL インジェクション用の文字列（' や and '1'='1 など）を投入しています。
2. T 氏はログの中から「ステータスコードが200」で「応答のサイズが通常時と比較して異常」である行を抽出しています。
   • 通常アクセス（番号「12」）
     GET /GoodsDetail goodsNo=10001 200 1,798
   • 攻撃リクエスト（番号「14」）
     GET /GoodsDetail goodsNo=10001 and 1=1 200 1,806
     いずれも HTTP 200 ですが、後者の応答サイズ「1,806」は通常時「1,798」と異なり、わずかな差が生じています。
3. この差分は、SQL 文が正常終了しつつ条件が無害化（and 1=1）されたことで取得結果が変わり、ページサイズに変化が出たことを示唆します。
4. 従って、 • 脆弱性が潜む画面＝URI のパス名は「/GoodsDetail」
   • 問題となるクエリ文字列中のパラメタ名は「goodsNo」
   であると判断できます。

誤りやすいポイント

• 「/Catalog」や「/GoodsSearch」にも ' を含むリクエストがありますが、応答サイズが変わらずページが静的に生成されているため脆弱性の有無を誤判定しやすいです。
• ステータスコード「500」の行（番号「13」）だけに注目すると「エラーだから脆弱」と思いがちですが、T 氏は正常応答かつサイズ差分の行（番号「14」）を根拠にしています。
• パラメタ名は URI に含まれるキー部分のみを答える必要があり、「goodsNo=...」全体や値まで書いてしまうミスが頻出です。

FAQ

解答の論理構成

1. 携帯サイトの規模
   【問題文】には「ショッピングサイトα…それぞれ30画面で構成されている。」とあります。携帯サイトも 30 画面存在します。
2. 攻撃の対象範囲
   T 氏は「特定のIPアドレスから27画面に対して、SQLインジェクションの代表的なパターンが試行されていました。」と報告しています。
3. 攻撃を受けなかった画面の存在
   30 画面中 27 画面だけが試行されたという事実は、残り 3 画面が攻撃対象になっていないことを示します。
4. 未試行＝安全ではない
   攻撃が届かなかっただけで「脆弱性がない」とは言えません。未試行の 3 画面にも同様の実装があれば同じ欠陥を含む可能性があります。
5. よって T 氏は「①それらの画面だけでなく、携帯サイト全体に対してSQLインジェクション対策を行ってください」と指示しました。

誤りやすいポイント

• 「27 画面に試行＝脆弱性は 27 画面限定」と誤解し、残り 3 画面の危険性を見落とす。
• 「エラーが出ていない画面は安全」と早合点し、根本的な入力値検証を怠る。
• PC／スマホサイトは診断済みだから携帯サイトも安全と連想し、サイト単位ではなくソース単位で脆弱性を考える視点が抜ける。

FAQ

解答の論理構成

1. プロジェクトで定めた報告ルール
   ・U課長は対策として「(4) “セキュリティ事故が発生した直後のA社情報システム部への報告”」を各社に指示しました。
   ⇒ 事故が判明したら即時に A社情報システム部へ連絡することが義務です。
2. Nさんの実際の行動
   ・携帯サイトの切離し・修正・再開を済ませた後で「NさんはA社情報システム部に、F社でセキュリティ事故が発生したことを報告した。」とあります。
   ⇒ 事故対応がほぼ完了した後になって初めて報告しています。
3. ギャップの整理
   ・要求は “直後に報告” であるのに対し、実態は “事後報告”。
   ・その結果、グループ全体で早期に注意喚起や被害抑止策を取る機会を逸しました。
4. 以上より、改善すべき点は「事故発生を認知した時点ですぐに A社情報システム部へ報告していないこと」と導けます。

誤りやすいポイント

• SQLインジェクション対策の不備が主因だと勘違いし、報告フローの問題を見落とす。
• 「切り離してから数日以内なので許容範囲」と判断してしまう。
• 報告先を G社運用担当者や X社だけで十分と考え、グループ全体への連絡義務を失念する。

FAQ

解答の論理構成

1. 問題は、図1の診断ガイドライン案にある次の記述から空所eを補うものです。
   引用：
   「IPS、WAFなどによって、eからの通信が遮断されると、対象Webサイトの脆弱性を検出できないので、eからの通信は遮断しないように設定した上で診断する。」
2. 文脈では“診断”を実施する主体は図1の「プラットフォーム診断」「Webアプリ診断」を行うツールやサービスです。
   それらが送信するパケットが IPS や WAF にブロックされると脆弱性を検出できません。
3. したがって、遮断してはならない通信元は“診断に用いるツールが設置された機器”を特定する情報であり、もっとも具体的に識別できるのは IP アドレスです。
4. 以上より、空所eには「診断ツールのIPアドレス」が入ると結論付けられます。

誤りやすいポイント

• 「診断者の端末」など抽象的な語を入れてしまい、IPS/WAF の設定対象として不十分になる。
• “スキャナ”や“ペネトレーションテストツール”と答え、通信元ではなく機器そのものを表現してしまう。
• WAF の例外設定は宛先ではなく送信元（通信元）に着目することを見落とす。

FAQ

解答の論理構成

• 【問題文】では「ファイアウォールの内側から行った診断で検出された脆弱性のうちfについては、深刻な脆弱性であっても、対策の優先順位を下げてよい。」と指示しています。
• ここで鍵となるのは「ファイアウォールの内側から行った診断」という条件です。外部からの攻撃はファイアウォールで遮断されるため、本来は到達できないサービスや“ポート番号”に対する脆弱性まで検出されてしまいます。
• したがって、優先順位を下げてよいのは「ファイアウォールで遮断されている通信」すなわち「外部から到達不可能なポート番号に関する脆弱性」です。
• 以上よりfには「ファイアウォールで遮断されているポート番号の通信に関わる脆弱性」と記述するのが適切になります。

誤りやすいポイント

• 「内部診断だから重大度が低い」と一律に判断し、ファイアウォールで遮断されていないポートまで優先順位を下げてしまう。
• “ポート”という語を忘れ「サービス」や「通信経路」など曖昧な表現でまとめる。
• ファイアウォール設定変更の可能性を無視し、外部公開予定のサービスも低優先度にしてしまう。

FAQ

解答の論理構成

1. 問題では、下線付き②の診断について「脆弱性の修正完了後、公開前にプラットフォーム診断及びWebアプリ診断を再度行う」と明示しています。
2. これは一度見つかった脆弱性を“修正した直後”という限定されたタイミングで“再度”診断することを義務付けています。
3. 同じ診断を再実施する意図は、①当初の脆弱性が本当に塞がれたか、②修正作業によって別の脆弱性が混入していないか、という二点の検証にあります。
4. 設問は「検出された脆弱性が適切に修正されたこと以外に何を確認することを目的としているか」を問うため、②に含まれるもう一つの目的、すなわち「修正作業が原因の新たな脆弱性有無の確認」を導きます。
5. 以上から解答「修正によって新たな脆弱性が発生していないこと」となります。

誤りやすいポイント

• 「再度診断＝修正ミスの有無」とだけ捉え、修正に伴う“新規”脆弱性まで意識しない。
• プラットフォーム診断とWebアプリ診断の対象範囲を誤解し、コードのみ、あるいはOS設定のみと限定してしまう。
• “公開前”というタイミングを軽視し、運用開始後の定期診断と混同する。

FAQ

解答の論理構成

1. 問題文の前提
   「例えば、図2に示すHTML（http://www.example.jp/domxss.html）があった場合に、図3に示すURIにブラウザからアクセスすると、“1”という警告ダイアログが表示される。」と記されています。図2の JavaScript は URI からフラグメント（location.hash 部分）を取得して画面に出力する仕組みであるため、攻撃者はフラグメントにスクリプトを埋め込めば DOM ベースの XSS が発生します。
2. g の導出
   フラグメント識別子は URI 中で # から始まります。よって、スクリプトをフラグメントに挿入するにはパス名直後に # を置く必要があります。従って g は「#」となります。
3. h の導出
   フラグメントに挿入するスクリプト部分は で終わらせなければブラウザが正しく解析できません。したがって h は「」となります。
4. 結論
   以上より、図3の URI に入る文字列は
   ・g：#
   ・h：</script>

誤りやすいポイント

• フラグメント識別子とクエリ文字列を混同し、「?」を選んでしまう。DOM ベースの XSS ではサーバに送信されないフラグメント（#）が利用される点に注意が必要です。
• スクリプトの終了タグを省略したりエンティティ化せずに書いてしまう。HTML 上は を明示的に閉じないと後続の文字列がすべてスクリプトとして解釈されます。

FAQ

解答の論理構成

1. 本文には「DOMベースのXSSは、攻撃者が注入するデータがWebサイトからの応答中に出力されない」ため、下線部「③反射型のXSSとは診断方法が異なる」とあります。
2. 反射型 XSS の特徴は、(a) 攻撃者が送ったパラメタがそのままサーバ側の応答に挿入され、(b) ブラウザで即実行される点です。したがって診断では、 ・テスト用スクリプト（例：）を各入力項目に埋め込む
   ・HTTP 応答に同じスクリプトがそのまま含まれているかを確認する
   という手順で脆弱性の有無を判定します。
3. しかし「DOMベースのXSSでは攻撃者が注入するデータがWebサイトからの応答中に出力されない」ため、上記のサーバ応答チェックでは検知できません。応答にスクリプトが見えないので、診断者が「安全」と誤認してしまいます。

誤りやすいポイント

• 「ブラウザでスクリプトが実行されるか」を直接見るのではなく、「応答にスクリプトが反映されているか」を確認することが反射型 XSS 診断の要点です。
• DOM ベース XSS はクライアント側 JavaScript が DOM を生成・書換える過程で起こるため、サーバ応答だけを調べても見つからない点を忘れがちです。
• 反射型と DOM ベースの診断を混同し、同じ手順で十分と考えてしまう失点が多発します。

FAQ

解答の論理構成

1. クリックジャッキング対策として本文では
   「④HTTP応答ヘッダで“X-FRAME-OPTIONS”にDENYを指定する」
   と示されており、DENY は“全てのドメインからのフレーム埋込を拒否”する挙動を持ちます。
2. 表3「フレーム内での表示の有無」を確認すると、 ・サイト5 … 「あり（同じドメインページ内で表示）」
   ・サイト6 … 「あり（同じドメインページ内で表示）」
   の2サイトは、自サイト内ページをフレームで呼び出す正規機能があると読み取れます。
3. DENY を設定すると同一ドメインを含めフレーム表示が完全に阻止され、正規機能が動作しなくなる＝不具合発生サイトは「サイト5」「サイト6」と判断できます。
4. 不具合を防ぎつつ外部サイトからの埋込だけを拒否したい場合、X-FRAME-OPTIONS の値を
   SAMEORIGIN（同一オリジンからのフレーム埋込のみ許可）に変更すれば要件を満たせます。

誤りやすいポイント

• 「クリックジャッキング対策＝とにかく DENY」と短絡し、フレームを正規利用しているサイトを見落とす。
• ALLOW-FROM も候補に挙げたくなるが、主要ブラウザでの実装状況が限定的であることに気付かず選択してしまう。
• 表3の「あり（同じドメインページ内で表示）」を“外部からは表示されないので安全”と理解し、対策不要と考える。

FAQ

解答の論理構成

1. 【問題文】には「HSTSとは、WebサイトがHTTPSの使用をブラウザに強制させる機能である。」とあり、さらに「HSTSは、HTTPS応答のヘッダにiを指定することによって有効となる。」と明記されています。
2. HSTS（HTTP Strict Transport Security）の仕様（RFC 6797）では、ブラウザに HTTPS を強制するために送信する HTTP 応答ヘッダは "Strict-Transport-Security" です。
3. 解答群を確認すると、HSTS に対応するヘッダフィールド名は「ウ：Strict-Transport-Security」のみです。
4. したがって、i に入る適切な応答ヘッダフィールド名は「Strict-Transport-Security」となり、記号「ウ」が正答です。

誤りやすいポイント

• 「Content-Security-Policy」と混同する
  同じくセキュリティ強化ヘッダですが、CSP はスクリプト実行やリソース読み込み元の制限を行うもので HTTPS 強制ではありません。
• 「X-Content-Type-Options」との誤選択
  これは MIME 型のスニッフィング防止ヘッダであり、HSTS とは無関係です。
• “HSTS” という略称から “HTTP”・“HTTPS” を含む別ヘッダを連想してしまい、正式フィールド名を思い出せないケースがあります。

FAQ

解答の論理構成

1. 問題文では「正規のWebサイトでHSTSが有効になるように設定していない場合、正規のWebサイトがHTTPS通信だけを受け付けるように構成していても、中間者攻撃が行われると、⑤ブラウザがHTTP通信で接続してしまい、中間者によって通信を盗聴されてしまう。」と述べ、HTTP に誘導された際の危険性を示しています。
2. その直後に「利用者は毎回jことでこの攻撃を受けても気付くことができる。」とあり、利用者自身が都度確認すれば危険を回避できると示唆しています。
3. 中間者攻撃で HTTP に誘導されても、ブラウザのアドレスバーに表示されるスキームは「http://」になり、錠前アイコンも消えます。したがって利用者は URL 表示を確認すれば異常に気付けます。
4. 以上より j には「ブラウザのアドレスバーを見て HTTPS 接続であることを確かめる」という内容が入るのが妥当となります。

誤りやすいポイント

• 錠前アイコンの有無だけを書くと、スキーム確認も必要な点を落としがちです。
• 「証明書情報を毎回詳細表示で確認する」とすると日常的に実行しづらく、問題文のニュアンスとずれます。
• 「URL のドメイン名を確認する」だけでは HTTP/HTTPS の違いに触れず不十分です。

FAQ

解答の論理構成

1. 本文には、HSTSが有効になる条件として
   「HSTSは、HTTPS応答のヘッダにiを指定することによって有効となる」
   とあり、図4では「HTTPS要求 → HTTPS応答（i: max-age=31536000）」のやり取り後にブラウザがHSTSを記憶すると示されています。
2. つまり、ユーザのブラウザは“最初に”対象サイトへHTTPSでアクセスし、Strict-Transport-Security ヘッダ（i）を受信して初めて強制機能を学習します。
3. 一方、下線⑤では「ブラウザがHTTP通信で接続してしまい、中間者によって通信を盗聴されてしまう」と説明されています。これは “ブラウザがまだHSTSを学習していない” 状況を前提としています。
4. したがって、有効期限切れ以外に問題が起きるのは「最初のアクセスがHTTPだったため、HSTSポリシを受け取っていないケース」であり、模範解答は「初回にブラウザでWebサイトへhttpでアクセスした場合」となります。

誤りやすいポイント

• 「HTTPSに強制される＝常に安全」と早合点し、初回アクセス時の“学習前状態”を忘れやすいです。
• 有効期限切れと混同し、「ヘッダのmax-ageが短い場合」などと解答すると設問の趣旨と外れます。
• “HTTPでブックマークされたとき”“httpリンクを踏んだとき”など、個別例に寄せすぎてしまうと要点がぼやけます。

FAQ