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

解答の論理構成

1. 脆弱性の内容把握
   • 図3に「“X-Sender” というヘッダフィールドを指定することで、任意のOSコマンドを実行させることが可能である。その際、OSコマンドはWebサーバプログラムの動作権限で実行される。」とあります。
2. 動作権限の重大性
   • 図2には「Webサーバプログラムは、システム管理者権限で動作している。」と記載されています。
   • よって攻撃者はシステム管理者権限で OS コマンドを実行できる状態となります。
3. 想定される被害
   • 管理者権限でコマンドを実行されると、 ① 図2の「DBサーバには、顧客の個人情報（住所、氏名、電話番号など機密性の高い情報）が格納されて」いる情報を窃取される恐れ。
     ② コマンド次第では Web サーバや DB サーバを停止させ、「システムの機能が全面的に停止」する恐れ。
4. 評価基準との照合
   • 図4「緊急」の定義は、損害金額が算出しにくい場合に「(1) 機密性の高い情報が漏えいする。」「(2) システムの機能が全面的に停止する。」のいずれかに該当すればよいと規定しています。
   • 上記①②はいずれも該当するため、P君は “緊急” と判断しました。

誤りやすいポイント

• 「POST しか影響しないから危険度は低い」と早合点する。攻撃経路が限定されても実行権限が高ければ致命的です。
• 「売上損害額が分からないから“重要”」と誤判定する。図4は損害金額を算出できない場合の別基準を示しています。
• 「個人情報の漏えいだけ」を理由にするか「システム停止だけ」を理由にするなど、緊急判定の根拠を片方しか挙げない。両方示すことで説得力が高まります。

FAQ

解答の論理構成

1. 本文の下線②では、Q課長が “攻撃が実際に行われる可能性が高い” と判断した理由を図3の内容から読み取る必要があります。
2. 図3には「“・Exploitコードが公開されている。」と明記されています。
3. 一般に、攻撃コード（Exploit）が公開されると、技術力の低い攻撃者でも容易に攻撃を実施できるようになるため、実際の攻撃発生確率が跳ね上がります。
4. したがって、Q課長の判断根拠は “Exploitコードが公開されている” という一点に帰着します。

誤りやすいポイント

• 図3の他の記述（“HTTP POSTメソッド…任意のOSコマンドを実行”）を根拠にしがちですが、攻撃が“高確率で起こる”と判断する直接要因は“Exploitコードの公開”です。
• 「攻撃手法が知られている」だけでは不十分で、“公開”というワードまで含めて記述する必要があります。
• 対処の緊急性と混同し、“システムの機能が停止する”など図4の評価基準を引用してしまう誤答に注意が必要です。

FAQ

解答の論理構成

1. 問題文の該当箇所
   ― S君は「POSTメソッドでのアクセスを拒否すると、HTML文書のa要素内に利用者が入力したデータを受け付けることができず」と述べています。
2. POST メソッドを利用する HTML 要素
   ― HTTP の「POSTメソッド」は、HTML 側ではデータ送信を行う仕組みに結び付きます。最も典型的なのは、
   要素の method="POST" 属性です。
3. 受験者が入力する具体的フィールド
   ― 実際にデータを入力するフィールドは や などですが、それらはすべて <form> 要素の内部に置かれ、送信先は <form> が担います。
4. 模範解答に「form 又は input」が認められる理由
   ― 表現上、 ① POST を扱う“入れ物”としての要素 … form
   ② 入力自体を受け付けるフィールド … input
   のいずれを指しても文意が成立するため、両方が正答として採用されています。

誤りやすいポイント

• 「body」「div」などレイアウト用タグを選んでしまう。POST メソッドとは直接結び付きません。
• 「textarea」は入力フィールドですが、問題文では“要素内に利用者が入力したデータを受け付ける”と広く述べているため、より一般的な form/input が優先されます。
• POST＝ファイルアップロードと短絡し と考えるなど、HTML 仕様に存在しないタグを想像してしまう。

FAQ

解答の論理構成

• 会話文では、GET への変更提案に対し Q課長が「③新たな情報漏えいの可能性が生じる」と指摘しています。
• 原因は、GET を使うと利用者入力が URL の末尾に付加される“クエリストリング”になる点です。
• “クエリストリング”は
  ① ブラウザが送る“Referer ヘッダ”にそのまま載り、外部サイトへ遷移した際に入力値が漏れる可能性があります。
  ② Webサーバが自動生成するアクセスログにも記録され、運用担当以外の閲覧者が内容を把握できてしまいます。
• したがって「POSTメソッド」と比較し GET では“クエリストリング”経由で入力データが別経路に残存・送信されるため、情報漏えいリスクが高まると結論づけられます。

誤りやすいポイント

• 「GET は暗号化されていれば安全」と思い込み、ログや Referer ヘッダの存在を失念する。
• “クエリストリング”をパラメータや URL パスと混同し、回答から語を外してしまう。
• POST でもヘッダにデータが載ると誤解し、リスク差を正しく比較できない。

FAQ

解答の論理構成

1. 脆弱性の特徴確認
   • 図3には「HTTP POSTメソッドにおいて、HTTPヘッダ内にRFCで定義されていない “X-Sender” というヘッダフィールドを指定することで、任意のOSコマンドを実行させることが可能」とあります。
   • 攻撃者は“X-Sender”ヘッダを送るだけで OS コマンドを実行できるため、このヘッダの有無が攻撃トラフィック判定の鍵となります。
2. 暫定対策の要求事項
   • 下線④で「シグネチャをカスタマイズすることで実現可能」とあるように、IPS に“攻撃パターンを検出して遮断”するシグネチャを登録する方針が決まっています。
   • したがって、シグネチャは「HTTPヘッダに “X-Sender” が含まれる通信」を的確に表現すればよいです。
3. 具体的シグネチャ内容
   • 攻撃はメソッドが「HTTP POSTメソッド」である点も特徴ですが、同じヘッダを悪用した GET など改変攻撃も想定されるため、“ヘッダに “X-Sender” がある”条件だけで遮断する方が安全マージンが大きく、実装も容易です。
   • よって解答は「HTTPヘッダに “X-Sender” フィールドを含む要求を拒否する」とまとめます。

誤りやすいポイント

• 「POST メソッドのみを対象」に絞りすぎる
  • 図3は POST の例示であり、ヘッダ検査だけで十分に危険トラフィックを止められます。
• 「X‐Sender=何らかの値」と値まで限定してしまう
  • 値は任意の OS コマンドを渡すため可変です。ヘッダ名だけで検知する方が確実です。
• 「User-Agent など既存ヘッダ名の書式」を参考にシグネチャを書いてしまう
  • 攻撃ヘッダは RFC 非準拠の“X-Sender”です。正確な綴りを引用しないと検知漏れが起きます。

FAQ

解答の論理構成

1. 脆弱性の特性
   図3には「任意のOSコマンドを実行させることが可能である。その際、OSコマンドはWebサーバプログラムの動作権限で実行される。」とあります。
2. 現行設定の問題点
   図2の(f)には「Webサーバプログラムは、システム管理者権限で動作している。」と明記されています。
3. 設定変更によるリスク低減
   任意コマンドが“システム管理者権限”で走ると、攻撃者はOS全体を掌握できます。そこで動作権限を制限すれば、同じ脆弱性を突かれても被害範囲を大幅に縮小できます。
4. 設定箇所と対策内容
   • 設定箇所は図2の(f)。
   • 対策は「Web サーバプログラムの動作権限を必要最小限とする。」
   以上より、記号：(f)、30字以内の対策内容が導かれます。

誤りやすいポイント

• (a) を選び「フォーム部分を変更すれば良い」と考えてしまう。脆弱性はHTTPメソッド内部処理でありフォーム仕様の変更では根本解決しません。
• (c) や (d) など境界防御装置に目が行きがち。今回はサーバ内部権限が直接関与します。
• 「IPSを導入したから十分」と思い込み、権限設定の見直しを軽視する。多層防御の観点を忘れがちです。

FAQ

解答の論理構成

• 図5の(1)は「負荷分散装置の設定を変更する」目的を示しています。
• 会話文においてS君は「深夜2時から朝8時までの間はアクセスが少なく、サーバ1台でも処理が可能」と述べ、P君は「Web販売システムを停止させることなく修正プログラムを適用」と提案しています。これは対象サーバを一時的にサービス系から外し、残りのサーバで処理を継続する運用を示唆しています。
• したがって負荷分散装置で行う操作は、対象サーバを稼働系（運用系）から切り離し、待機（スタンバイ）状態にすることを指します。
• 以上より、b には「運用系から切り離す」など、サーバを一時的にサービス提供から外す意味の語句が入るのが妥当です。

誤りやすいポイント

• 「停止させる」と書くとサーバ電源断やプロセス停止を想起させ、負荷分散装置での設定変更という文脈とずれる場合があります。
• 「ロードバランサを無効化する」と誤答するケースがありますが、無効化するのはサーバへの振り分けであってロードバランサ自体ではありません。
• 順次適用というキーワードを見落とし、全サーバを同時に外す前提で考えてしまうと適切な語句が選べなくなります。

FAQ

解答の論理構成

1. 修正プログラムは動作不具合を招く場合があり、本番適用前に安全性を確認する必要があります。
2. 問題文の「図2」g には
   「“B社のシステム開発部で図1とほぼ同一構成である動作試験用システムを別に用意している。”」
   とあり、実機と同等環境が既に整備されていることが分かります。
3. この環境でパッチ適用後の挙動を検証すれば、本番への影響を最小化できます。
4. 以上より、T課長への説明前に実施すべき作業は
   「動作試験用システムで、修正プログラム適用後の動作の正常性を確認する。」
   となります。

誤りやすいポイント

• 本番環境のバックアップ取得やロールバック手順だけで十分と誤解し、事前検証を怠る。
• 「IPSがあるから安全」と判断し、パッチテストを省略してしまう。
• テスト環境が「ほぼ同一構成」と明示されている事実を見落とす。

FAQ