情報処理安全確保支援士 2010年 秋期 午後1 問03

解答の論理構成

1. 【問題文】には
   「販売システムを利用する上で必要な通信（以下、正常な通信という）をWAFが攻撃として検知してしまうことで、利用者が販売システムを利用できなくならないよう、まずはaを減らすための検証期間を設けます。」
   と記載されています。
2. ここで説明されている現象は「正常な通信を攻撃として検知」することです。
3. これは攻撃ではないものを攻撃と“誤判定”している状態であり、セキュリティ分野では「フォールスポジティブ（偽陽性）」と呼ばれます。
4. 解答群を照合すると、「エ：フォールスポジティブ(偽陽性)」が一致します。
5. よって a に入る適切な語句は「エ」です。

誤りやすいポイント

• 「攻撃を見逃す」ケース（＝フォールスネガティブ）と取り違える。問題文では“正常な通信を攻撃として検知”と明示されており、真逆です。
• 「フェールセーフ／フェールソフト」は障害時のシステム動作方針の用語であり、誤検知・検知漏れの概念ではない点に注意。
• “検証期間には、攻撃を検知しても通信の遮断は行わず”という一文だけを見て「見逃し＝フォールスネガティブ」と早合点するケース。文脈全体を読めば“遮断しないのは可用性確保のための暫定措置”であり、本質は誤検知削減です。

FAQ

解答の論理構成

1. まず本文では、S主任が「①販売システムのFWでは、セッションIDの偽造を判別できない」と判断しています。
2. その根拠として図2の説明に「(5) FW は、パケットのヘッダ情報によってアクセスを制御するパケットフィルタリング型である。」と明示されています。
3. パケットフィルタリング型ファイアウォールは、IPアドレス・ポート番号といったヘッダ情報のみを参照し、HTTPメッセージ本文に含まれるクッキーやセッションIDといったアプリケーション層データは検査範囲外です。
4. したがって、ヘッダ以外に含まれるセッションIDが真正か偽造かを見分けられないため、S主任は判別不可と結論付けました。

誤りやすいポイント

• 「ファイアウォール＝すべての不正通信をブロックできる」と早合点し、パケットフィルタリング型とアプリケーション層を解析するWAFの違いを混同しやすいです。
• 「SSL通信だからFWでも中身を見られるのでは」と誤解するケースがありますが、FWは復号処理を行わないため暗号化されたペイロードも判別できません。
• 「シグネチャによる通信検査機能」をFWが持つと勘違いし、下線①との関係を取り違えるミスが起こりやすいです。

FAQ

解答の論理構成

• 図3には「ミドルウェアによるセッションIDの生成に不備があり、利用者向けに発行されたセッションIDを第三者が推定できてしまう可能性がある。」とあり、攻撃者は推定した値をクッキーに仕込み送信するだけでなりすましが可能です。
• 一方、WAFの「クッキーの暗号化機能」は「Web アプリケーションがブラウザに対してクッキーを発行した際、クッキーの値を暗号化して引き渡す。」さらに受信時に復号してアプリケーションへ渡します。
• つまりブラウザ側に保存される値は暗号文であり、攻撃者は①推定した平文セッションIDをそのまま送信しても WAF が復号時に不整合を検知し破棄する、②暗号鍵を知らないため「復号後に有効なセッションID」となる暗号文を生成できません。
• したがって「②クッキーの暗号化機能によって、図3の脆弱性を悪用した攻撃への対策が可能です」という Q 氏の説明が成り立ちます。

誤りやすいポイント

• クッキー暗号化を「通信経路の盗聴防止」と混同し、推定可能なセッションID問題まで解決できる理由を説明できない。
• 暗号化してもクッキー属性が保持されるとあるため、安全性が落ちると誤解する。実際には暗号化で予測困難性が加わる。
• シグネチャ検査と混同し、「既知攻撃検知だから防げる」と答えてしまう。今回の対策は検知ではなく改変困難化。

FAQ

解答の論理構成

1. クッキー暗号化機能の仕様確認
   【問題文】の表で、WAF の機能として
   「クッキーの暗号化機能…クッキーの値を暗号化して引き渡す」
   と明記されています。すなわち暗号化対象は 値 (＝右辺) のみです。
2. 属性は維持されることの確認
   下線③では
   「クッキーの暗号化では、クッキーに属性を付与している場合であっても、その属性の効果を維持できるように考慮されています」
   とあるため、secure や path などの属性名・属性値は書き換えません。
3. 元の Set-Cookie ヘッダ
   Web アプリケーションが送信するヘッダは
   Set-Cookie: session_id=uid20101017143045; secure; path=/874045/
   です。
4. 暗号化後に変化する箇所
   変わるのは session_id= 以降の値「uid20101017143045」だけ。
   問題文では暗号化後の文字列を “☆☆” で表すと指定されているので
   session_id=☆☆ となります。
5. 選択肢比較
   • ア：path の値が書き換わっており、属性保持の要件に反します。
   • イ：secure 属性が消えており、要件に反します。
   • ウ：secure; path=/874045/ がそのまま残り、値だけが ☆☆。
   • エ：secure は残るが path の値が書き換わっています。
   よって要件を唯一満たすのは【ウ】です。

誤りやすいポイント

• 「属性も暗号化対象」と思い込み、path や secure まで変更してしまう。
• secure 属性を見落とし、暗号化後に消えても問題ないと判断する。
• 暗号化でクッキー名称 (session_id) まで変わると誤解する。名称は保持されます。

FAQ

解答の論理構成

• 【問題文】では WAF の「クッキーの暗号化機能」について、 「ブラウザからクッキーを受信した際、値を復号して、Web アプリケーションに引き渡す」と説明されています。
  つまり暗号化／復号は WAF を経由する HTTP リクエスト／レスポンスの中だけで完結します。
• しかし下線部④において、Q氏は
  「ブラウザに格納されるクッキーが暗号化されたものになることから、Webアプリケーションによっては、動作に異常が生じる場合があります」
  と述べています。
• WAF が復号する前にクッキー値が利用されると、アプリケーションは暗号化済みの値しか取得できず整合が取れません。該当するケースは
  1. クッキーを JavaScript など“クライアント側”で参照・加工している場合
  2. クッキーを WAF を経由しない別ドメインや別 Web サーバに送信している場合
     です。どちらも WAF による復号が行われず、平文を期待する処理が破綻するため「動作に異常」が発生します。

誤りやすいポイント

• WAF が暗号化／復号を行うので「アプリケーションには影響しない」と早合点する。クライアントサイドで読む処理を見落としがちです。
• 「同一サイト内の別 Web サーバなら問題ない」と誤解する。WAF 経由かどうかが鍵であり、経路が異なれば復号されません。
• 暗号化対象を“セッションIDだけ”と決めつけ、他のクッキーフィールドを調べずにチューニングを進めてしまう。

FAQ

解答の論理構成

1. 【問題文】ではシグネチャによる通信検査機能について「シグネチャには、脆弱性を悪用する攻撃に含まれる可能性の高い文字列が定義されている」と示されています。
2. 同じく【問題文】の下線⑤で「正常な通信が攻撃と検知された場合であっても、不用意に、そのシグネチャを無効化するべきではありません」と注意喚起があります。
3. つまり“誤検知を防ぐためにシグネチャを無効化したい”という運用要望があっても、そのシグネチャで守っている“対象脆弱性”がシステムに残っている場合、無効化すれば攻撃を素通ししてしまう危険があります。
4. 逆に言えば、無効化しても安全と言い切れる条件は「そのシグネチャが防御している脆弱性が、Webアプリケーションやミドルウェアに存在しない」と確認できた場合に限られます。
5. 以上から、下線⑤に対する答えは「無効化するシグネチャの標的となる脆弱性が自システムに無いことを確認すること」と導かれます。

誤りやすいポイント

• 誤検知が出たら“即座に”シグネチャをオフにしてよいと考えてしまう。対象脆弱性が残存している可能性を忘れがちです。
• 「正常通信のみ通れば良い」の発想で“シグネチャの詳細分析”を怠り、実際にどんな攻撃を検知しているのか把握しないまま無効化するケース。
• 対象脆弱性の有無を「機能テストで問題が起きないから大丈夫」と誤解し、ソースコードレビューやバージョン確認を行わない点。

FAQ

解答の論理構成

1. 【問題文】には、WAFの機能として
   「シグネチャによる通信検査機能…HTTP による通信をシグネチャと比較し、一致した場合には攻撃として検知する」
   とあります。
   ⇒ WAFは暗号化されていない“HTTP”データを参照して初めて攻撃を検知できます。
2. しかし販売システムはログイン後、 「ブラウザと Web サーバ間で SSL 通信が行われる」
   と明記され、SSLで暗号化されたパケットはWAFから中身が見えません。
   ⇒ 従来どおり Web サーバでSSL終端すると、WAFは暗号化されたままの通信しか受け取れず検査不能です。
3. そこでWAFの「SSL アクセラレーション機能」を使い、 「⑥ブラウザからのSSL通信は、WAFで終端させることにした」
   としたのは、WAF自身が復号して平文HTTPを得るためです。
4. 復号後のHTTPを対象に「シグネチャによる通信検査機能」を適用し、攻撃を検知・遮断できるようにする。
   ⇒ したがって解答は “SSL暗号化されたままではWAFが検知できないため、復号の終端点をWebサーバではなくWAFに変更する” となります。

誤りやすいポイント

• 「SSLアクセラレーション＝高速化目的」とだけ考え、セキュリティ検査の必然性を見落とす。
• WAFを透過型と思い込み、暗号化されていても自動的に解読できると誤解する。
• SSL終端をWAFに移すと“通信は平文になる”と誤認し、内部区間の再暗号化（リバースプロキシ方式）を考慮し忘れる。

FAQ