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

解答の論理構成

1. 指摘事項Aの原因確認
   • 問題文では「暗号化通でだけ便用されるべきクッキーに、a属性が設定されていない」とあります。
   • 暗号化通信（HTTPS）でのみクッキーを送付させる仕様はSet-Cookieヘッダの「Secure」属性です。したがって a には「secure」が入ります。
   • 表2でも「暗号化通信でだけ使用するクッキーにa属性を設定する」と再度確認できます。
2. 指摘事項Bのログ検出条件
   • 問題文には「指摘事項Bに対する攻撃は、③HTTPアクセスログから検出する…ただし、この方法ではbメソッドが使用された場合にしか検出できない。」とあります。
   • 一般的なWebサーバのアクセスログはリクエストラインのみを保存し、POSTボディは残りません。したがってクエリ文字列にスクリプトが含まれている場合に検出できるのはGETリクエストだけです。
   • よって b には「GET」が入ります。
3. まとめ
   • a → 「secure」
   • b → 「GET」

誤りやすいポイント

• 「HttpOnly」を選んでしまう
  クッキーをJavaScriptから参照できなくする属性であり、暗号化通信限定ではないため不適切です。
• 「POST」メソッドを入れてしまう
  POSTボディはアクセスログに残らないことが多く、ログ検出の前提に合致しません。
• 属性名の大文字小文字
  RFCでは「Secure」ですが、問題文ではすべて小文字で求められています。

FAQ

解答の論理構成

1. 検出ロジックの確認
   ― 本文には「同一のセッションIDが、複数の送信元IPアドレスから送信されているリクエストをログから抽出することにした。」とあります。
   ― つまり “セッションID → IPアドレス” が1対1であることを前提に不正利用をあぶり出す方式です。
2. 誤検出が起こる条件を逆算
   ― 不正利用でなくても「同一のセッションID」が「複数の送信元IPアドレス」から届くことがあり得れば、正当なアクセスが不正と判定されてしまいます。
3. 実際にあり得るシナリオ
   ― モバイル回線、プロキシ経由、社内NATなどでは通信経路の都合で「端末のIPアドレスがセッションの途中で変わる」ことがあります。
   ― この変化を検出ロジックは “複数IPからの同一セッションID” とみなすため、正当な利用者を誤検出します。
4. したがって解答は「端末のIPアドレスがセッションの途中で変わるようなアクセスの場合」となります。

誤りやすいポイント

• IPアドレスが変わる＝常に不正と早合点しやすい。モバイル回線やロードバランサ配下を忘れがちです。
• 「セッションIDの使い回し」＝クッキー盗難と単純連想し、IP変化という正常系を想定しない。
• 誤検出と検出漏れの双方を問う設問で、一方しか考慮せず解答を狭めてしまう。

FAQ

解答の論理構成

1. 検出方法の前提
   問題文では、指摘事項Ａに対し
   「同一のセッションIDが、複数の送信元IPアドレスから送信されているリクエストをログから抽出」
   とあります。これは “送信元IPアドレスが異なる＝別人” という仮定で不正利用を見付ける仕組みです。
2. 検出漏れが起こる条件
   しかし同じＩＰアドレスを共有する環境では、この仮定が成り立ちません。
   例えば多数の端末が1つの “プロキシサーバ” や “ＮＡＴ装置” を経由すると、外部からは全て同じ送信元ＩＰに見えます。
3. 不正利用なのに検出できないケース
   攻撃者が被害者と同じ共有ＩＰ内にいる場合、 「セッションIDの盗難→同一ＩＰから再利用」というシナリオになります。
   ログ上は “同一ＩＰからのアクセス” なので、上記抽出条件に該当せず検出不能です。
4. したがって解答
   「攻撃者と被害者が同一のプロキシサーバやＮＡＴを経由してアクセスした場合」となります。

誤りやすいポイント

• 「モバイル回線のＩＰが変わると検出できない」と勘違い
  ⇒ 問題は “同じＩＰに見える” ケース。変わる方は①の誤検出リスクです。
• ＩＰスプーフィングと混同
  ⇒ ここでは送信元ＩＰを偽装する必要はなく、単に共有ＩＰ環境に居ればよい。
• 「ＣＤＮ経由」など中継ノードを挙げるミス
  ⇒ 送信元が同一ＩＰに見える具体例として、プロキシサーバやＮＡＴを押さえましょう。

FAQ

解答の論理構成

• 【問題文】では「指摘事項Bに対する攻撃は、③HTTPアクセスログから検出することにした」とあります。したがって検出対象は“攻撃に用いられたHTTPリクエスト”です。
• 指摘事項Bの攻撃内容は表1にあるとおり「HTTPリクエストに挿入されたスクリプトが、ブラウザ上で実行される」ことです。
• 攻撃例として提示された【図2】の1行目は
  「GET /mypage/progA?PID=xx&QTY=yy"><script>alert("script")</script> HTTP/1.1」
  で、スクリプトがクエリ文字列に含まれています。
• さらに本文には「ただし、この方法ではbメソッドが使用された場合にしか検出できない」とあり、【図2】と照合するとbは「GET」と判断できます。GETであればリクエストラインにパラメータが露出し、ログにそのまま残るため検索が可能です。
• 以上より、「クエリ文字列にスクリプトが含まれているログ」を抽出すれば攻撃を検出できると論理付けられます。

誤りやすいポイント

• 攻撃スクリプトの有無をレスポンス側に探してしまう
  → 問題はリクエスト（アクセスログ）側で検出します。
• POSTリクエストの本文に含まれるスクリプトも対象にしようとする
  → 本文中にある制約で「bメソッドが使用された場合にしか検出できない」と明記されています。
• RefererやCookieヘッダに着目してしまう
  → 例示された攻撃はクエリ文字列へのスクリプト挿入であり、最優先で確認すべき箇所はリクエストラインです。
• セッションID重複検出（指摘事項Aの方法）と混同する
  → 指摘事項Bの検出は別ロジックであることに注意します。

FAQ

解答の論理構成

1. 問題文は、c行目について「受け取ったパラメタの値をスクリプトに埋め込み、動的にスクリプトを生成」し、かつ「通常のHTMLにパラメタの値を埋め込むときと同じ方法で、エスケープ処理を行っていた」と説明している。
2. 図4のコードを確認すると、 • 35行目
   out.println("- - results - - category: " + escape(category) + "
   ");
   はHTMLの本文に文字列を埋め込んでいるだけで、スクリプト生成は行わない。
   • 37行目
   out.println("<a name="#" onclick="alert('" + escape(word) + "')">");
   はonclick属性内にJavaScriptのalert() を動的生成しており、「パラメタの値をスクリプトに埋め込む」条件に合致する。
3. したがって、cに入る行番号は「37」である。

誤りやすいポイント

• エスケープ関数escape() が両行に登場するため、「HTMLに値を埋め込む＝脆弱」と早合点し、35行目を選択しがちです。
• 「スクリプト生成」というキーワードを見落とすと、HTML本文とJavaScript部分の文脈の違いに気付きにくいです。
• onclick属性内での文字列結合は、クロスサイトスクリプティング (XSS) が最も発生しやすい典型例であることを思い出せないと判断を誤ります。

FAQ

解答の論理構成

1. 図4のプログラムは、onclick属性のJavaScript内に wordパラメタを
   〈 ' + escape(word) + ' 〉という形でシングルクォート囲みで埋め込んでいます。
   したがって、wordに
   ・スクリプト解釈用の バックスラッシュ
   ・囲み文字である シングルクォート
   が現れると、構文が壊れ 「任意のスクリプトが実行可能」 という“指摘事項B”の脆弱性になります。
2. 表2の改修方針では「出力するときの文脈に合わせたエスケープ処理を行う」と定義され、 そのために escape2関数を新設するとあります。
3. 逃がすべき対象文字と置換後の文字列は、JavaScript文字列リテラルの規則から直接導けます。
   • バックスラッシュ \ はエスケープ記号そのものなので \ に二重化する。
   • シングルクォート ' は文字列終端の意味を持つので \’ へ変換する。
4. 先にスクリプト文法上のエスケープ（上記2文字）を行い、続けて既存のescape関数で
   HTMLエンティティ変換（&、<、>、"）を実行するという仕様です。

誤りやすいポイント

• バックスラッシュを 一重 にしてしまい、結果としてブラウザが ' を +’ ではなく
  エスケープ済みの ' と解釈するケース。
• ダブルクォート " を対象に含める 誤回答。今回はJavaScriptを '...' で囲んでいるため
  ダブルクォートは文字列終端になりません。
• HTMLエンティティ（< など）だけで十分と考え、スクリプト文法上の
  エスケープ処理を追加しないままescapeを呼び出すパターン。

FAQ