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

解答の論理構成

1. 脆弱性の特定
   • H氏はセッション識別子が「ログイン日と会員番号」を組合せた文字列であると指摘し、これでは「①容易になりすましアクセスができてしまいます」と述べています。
2. 具体例の確認
   • 図2の例としてsession_id = 20081223309804が提示されており、説明文には「会員番号309804の利用者が2008年12月23日にログインしたときのcookieの値」とあります。
3. 推測可能性の評価
   • ログイン日はカレンダーの日付、会員番号は連番や顧客情報から類推できるため、攻撃者は他人の「会員番号」を試行しやすい構造です。
4. なりすまし方法の導出
   • よって攻撃者は自分のブラウザのcookieに保存されたsession_idのうち「会員番号」部分だけを目当ての利用者番号に書換え、当該利用者のセッションとしてアクセスできます。

誤りやすいポイント

• 「ログイン日」を変える必要があると誤解しやすい
  → 日付は当日の値でよいか、単純に推測できるので主攻撃点は「会員番号」。
• 既存cookieを削除してから攻撃すると思い込む
  → 既存値を編集するだけで済む。
• セッション固定攻撃と混同する
  → 本設問は識別子を“推測・改変”して奪うケース。固定攻撃とは別。

FAQ

解答の論理構成

1. 先に問題文で示された状況
   • 「図3のプログラムはHTTPSでアクセスする画面を出力するもの」
   • 「③HTTPSでの正常なアクセスを意味する鍵マークが表示されなくなっています」
     これは“混在コンテンツ（mixed content）”が原因で発生する典型的な症状です。
2. 混在コンテンツが疑われる理由
   • 安全に表示されるには、HTML内で参照するすべてのリソース（画像・CSS・JSなど）が同じくHTTPSで取得される必要があります。
   • HTTPのリソースを1つでも含むと、ブラウザは“完全に保護されていない”と判断し、鍵マークを外します。
3. プログラム行の調査
   • 【図3】から画像を読み込む箇所は24, 29, 50行です。
     24 print "<img src="http://www.c-sha-a.com/img/a0.png" ...>"; 29 print "<img src="../img/a1.png" ...>"; 50 print "<img src="https://www.c-sha-a.com/img/a9.png" ...>";
   • 29行は相対パス、50行はHTTPS。唯一24行だけが「http://」で絶対指定されています。
4. 原因の特定
   • 「http://www.c-sha-a.com/img/a0.png」が混在コンテンツの発生源。
   • よって“行番号：24”。
5. 修正方針
   • 相対パス「../img/a0.png」にする
     もしくは
   • 先頭を「https://」に変更
     どちらもブラウザへの要求がHTTPSで統一され、鍵マークが回復します。

誤りやすいポイント

• 「29行も相対パスだから危険では？」と勘違いする。相対パスは現在のスキーム（HTTPS）を自動で継承するので問題はありません。
• 「24行を削除すればよい」と安易に判断して画像欠落を招く。リソースの取得方法だけを直すのが基本です。
• “httpとhttpsの違いは速度だけ”と誤認し、警告表示の重要性を軽視する。鍵マークは利用者への重要な安心材料です。

FAQ

解答の論理構成

• 【問題文】ではH氏がXSS対策について「プログラムがHTMLタグの②ある特定の属性に値を出力する場合は、個別の対処が必要」と助言しています。
• ここで “個別の対処” が必要となるのは、ブラウザがその属性値をJavaScriptと解釈しやすい部分です。
• 代表例の一つはリンク先を指定するhref属性です。<a href="javascript:..."> の形式でスクリプトを直接実行できるため、一般的な「 < や > の置換」だけでは防げません。
• もう一つは各種イベントを扱う「イベントハンドラ属性」です。onclick、onmouseoverなどon* で始まる属性は、値に書かれたスクリプトをそのまま実行します。
• したがって「②ある特定の属性」に該当する二つは
  ・「タグのhref属性」
  ・「タグのイベントハンドラ属性」
  となります。

誤りやすいポイント

• srcやactionも危険だと考え、回答数を超えて列挙してしまう。
• 「イベントハンドラ」を単に「onclick」と書いてしまい、属性の総称でないため減点される。
• hrefのみを挙げて二つ目を失念する。

FAQ

解答の論理構成

1. 問題文では、透過的データ暗号化（TDE）について
   「“④透過的暗号化の効果は限定的です”」と記載されています。
   ここでいう限定的とは、“DBファイルやバックアップ媒体が社外に持ち出された場合”のような、データベースの外側で発生する脅威に対して有効である一方、SQLを経由した正規アクセス時には自動復号されてしまう、という意味です。
2. 解答群を個別に検討します。
   • ア「SQLインジェクションによる不正閲覧」
   ─ 攻撃者はアプリケーション経由でSQLを実行します。TDEはSQL実行時に自動復号するため防げません。
   • イ「サーバ管理者によるSQL文を利用した不正閲覧」
   ─ 管理者もSQLを使うため同様に自動復号され、防げません。
   • ウ「図1中の内部セグメントにおける通信傍受による不正閲覧」
   ─ TDEはストレージ暗号化であり、ネットワーク経路は暗号化しません。
   • エ「バックアップ媒体を入手した第三者による不正閲覧」
   ─ バックアップファイルは暗号化されたまま保存されるため、TDEが最も効果を発揮するケースです。
3. 以上より、防止できるのはエのみです。

誤りやすいポイント

• 「暗号化している＝SQLインジェクション対策にもなる」と短絡的に考えてしまう。TDEはストレージ暗号化でありアプリ経由の読み取りは平文になります。
• 「内部セグメントの通信傍受」も守れると誤解する。TDEは転送経路ではなく“保存データ”の暗号化機能です。
• “サーバ管理者”というキーワードに惑わされる。管理者がDBへSQLを投げれば自動復号されるため閲覧可能です。

FAQ

解答の論理構成

1. 本文では、G君が「パスワードをMD5関数の引数にして算出しています」と述べています。これはハッシュ化自体は行っているものの、入力が“パスワードだけ”なので辞書攻撃やレインボーテーブル攻撃に弱い状態です。
2. その結果としてH氏は「ハッシュ値が知られた場合、検索エンジンや専用ツールを使って、元の値であるパスワードを突き止められてしまう可能性があります」と指摘し、さらに「⑤より工夫してパスワードのハッシュ値を算出した方がよい」と助言しています。
3. “より工夫”とは、攻撃者が用意している既成のハッシュ一覧に一致しないようにすることです。代表的な対策は
   ・パスワードにランダムな文字列（ソルト）を連結し、その結果をハッシュ化する
   ・もしくは鍵付きハッシュ関数（HMACなど）を用いてハッシュ値を計算する
   　という2案に集約できます。どちらも“パスワードだけ”を入力としないことで、既存テーブルを無効化し、ハッシュ値から元のパスワードを容易に逆算できないようにします。

誤りやすいポイント

• 「MD5は一方向関数だから安全」と思い込み、ソルトの必要性を見落とす。
• 「暗号化」と「ハッシュ化」を混同し、鍵を保存した“暗号”方式を答えてしまう。
• ソルトを固定値にしてしまい、ユーザ間で同じパスワードが同じハッシュになる失敗。

FAQ