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

解答の論理構成

1. 決済アプリが表示するバーコードの中身
   • 表1には「決済…『16桁の会員番号をバーコードとして表示する』」と明記されています。
   • これによりバーコード＝会員番号であることが分かります。
2. バーコードの有効期限や一時性についての記述がない
   • 表4の決済処理では「3 利用者は，決済アプリにバーコードを表示する。」→「5…バーコードが示す会員番号に対して決済する。」のみで，バーコードが再利用不可能である旨の説明はありません。
3. 以上から導かれるリスク
   • 他人の「16桁の会員番号」を入手・推測すれば，同じ形式でバーコードを作成し店舗アプリに読み込ませるだけで決済が成立します。
   • これは「他者になりすまして決済できる」という表6 項番1の指摘に合致します。
4. よって模範解答は
   • 手段：会員番号を推測・窃取してバーコード（同等データ）を生成・提示
   • 問題：バーコードが単なる会員番号であり，かつ使い捨てでない

誤りやすいポイント

• 「ポイントサービスでは被害なし」だから安全と誤解し，金銭決済へのリスク増大を見落とす。
• 16桁だから総当たりは非現実的と考えがちだが，実際は「窃取」（肩越し撮影やスクリーンショット共有）でも成立する点を失念しやすい。
• バーコード自体が署名付きデータと誤認し，改ざん不可と思ってしまう。実際は単なる数値列で偽造容易。

FAQ

解答の論理構成

• 〔項番1への対策〕では、「会員番号、WebサーバNで生成した乱数、時刻、及びそれら三つの情報を基に生成されるHMAC（Hash-based Message Authentication Code）値」をQRコードに含めると記載されています。
• 図3はQRコード生成・検証手順を示しており、検証側では①秘密鍵Ｋで再計算したHMAC値βを得る → ②オリジナルのHMAC値αと照合する → ③時刻・ワンタイム性を確認する、という流れになっています。
• 一致確認こそがメッセージ認証の核心であり、HMAC値α ≡ HMAC値βなら改ざん・なりすましがないと判断できます。
• したがってaには「HMAC値αとHMAC値βの一致を検証する」が入ります。

誤りやすいポイント

• 再計算したHMAC値βをそのまま採用すると思い込み、照合プロセスを書き忘れる。
• “比較”ではなく“再計算”を記述し、生成フェーズと検証フェーズを取り違える。
• ワンタイム性確認（時刻・乱数）とHMAC値照合をセットで書いて冗長になる。

FAQ

解答の論理構成

1. 【問題文】には「①攻撃者が無線LANルータの設定を変更する と、攻撃者が用意したサーバに利用者が接続しても気付かない」とあります。
2. 利用者を攻撃者サーバへ誘導する最も簡単な方法は名前解決を乗っ取ることです。
3. 表5で名前解決に関与する設定は「い　DNS プロキシ　無線 LAN ルータが参照する DNS サーバの IP アドレス」だけです。
4. 攻撃者がここを自分の DNS サーバへ書き換えれば、正規ドメイン名を不正 IP にひも付けられ、「攻撃者が用意したサーバに利用者が接続」する状況が実現します。
5. 以上から「変更する設定項目：い」「変更後の設定内容：攻撃者のDNSサーバのIPアドレス」となります。

誤りやすいポイント

• 「え　パケットフィルタリング」を選ぶと、フィルタで通信を遮断できても別宛先へ“誘導”は困難である点を見落としやすいです。
• 「う　DHCP サーバ」を選ぶ場合も、DNS サーバ情報を含めるには DHCP 経由で設定を流す追加作業が必要で、本問の“設定を一か所変えるだけ”という意図から外れます。
• DNS 変更の影響範囲（ドメイン全体が乗っ取られる可能性）を軽視し、危険度を過小評価しやすいです。

FAQ

解答の論理構成

1. 図4の検証条件は

   「サーバ証明書に b の dNSName があれば、アクセス先の Web サーバ N の c と合致し、サーバ証明書に b の dNSName がなければ、アクセス先の Web サーバ N の c が subject の d と合致すること」
   と記載されています。

2. TLS／HTTPS では、まず拡張領域の “subjectAltName”（SAN） に含まれる “dNSName” と接続先 FQDN を照合し、SAN が無い場合だけ “subject” の “commonName” を参照するのが業界標準です。
3. 解答群を確認すると
   • “subjectAltName” は オ
   • “commonName” は イ
     が該当します。
4. “アクセス先の Web サーバ N の c” は DNS 名を指し、5字以内なので “FQDN” が適切です。
5. 以上より
   • b：オ（subjectAltName）
   • c：FQDN
   • d：イ（commonName）
     が導かれます。

誤りやすいポイント

• SAN と CN の優先順位を逆に覚えてしまう。最新ブラウザは SAN が無い証明書を警告なしで受け入れないため要注意です。
• FQDN を「ホスト名」や「ドメイン名」と書き換える誤答。設問は 5 字以内を指定しているので正式に “FQDN” と書く必要があります。
• 解答群の ア〜カ を見落とし、存在しない語句を記入してしまうミス。

FAQ

解答の論理構成

1. 【問題文】の表3「会員登録処理」に
   ・2-a では “電子メールを送信しました。”
   ・2-b では “既に使用されているメールアドレスです。”
   と表示内容が分岐すると明記されています。
2. 表6の項番5では、「決済アプリの会員登録機能は、攻撃者が悪用すると、当該機能の挙動からスクリーングができてしまう。」と指摘しています。
3. つまり攻撃者はメールアドレスを入力するだけで、上記2種類のメッセージのどちらが返るかを観測できます。
4. 返却メッセージの違いにより
   ・入力アドレスが既に会員登録済みか
   ・未登録か
   を判別できるため、パスワードリストから「存在するアカウントだけ」を抽出する“スクリーニング”が可能です。
5. 以上から、利用された挙動は
   「メールアドレスが会員登録済みか否かで UI メッセージが異なる」
   ことになります。

誤りやすいポイント

• 表3の2-a／2-bの違いに気付かず、会員登録処理が単にメール送信の可否を示しているだけと思い込む。
• スクリーニング＝総当たり攻撃と混同し、「表示の遅延」や「CAPTCHA」などを答えてしまう。
• 「挙動」を聞かれているのに「対策策」を述べてしまう。

FAQ

解答の論理構成

• 表6の指摘5には「決済アプリの会員登録機能は、攻撃者が悪用すると、当該機能の挙動からスクリーングができてしまう。」とあります。
  「スクリーング」とは登録有無を判別し、無効な候補を除外できることを意味します。
• 表3の会員登録処理を見ると
  ・「2-a【入力されたメールアドレスが会員登録されていない場合】…“電子メールを送信しました.”と表示」
  ・「2-b【入力されたメールアドレスが会員登録されている場合】…“既に使用されているメールアドレスです.”とエラー表示」
  とあり、メッセージが異なります。
• 攻撃者は入力結果から登録有無を容易に判定でき、パスワードリスト攻撃の準備（スクリーング）が可能になります。したがって異なるメッセージを統一して判別を困難にする必要があります。
• 修正すべき箇所は、登録済みメールアドレス時の処理「2-b」。修正内容は未登録時と同じメッセージを返すことです。よって
  修正すべき処理：2-b
  修正後の処理：2-aと同じメッセージを表示する。

誤りやすいポイント

• 「メールアドレス重複チェック自体をなくす」と誤解しがちですが、重複チェックは必要であり“結果の通知方法”だけを統一します。
• 「2-aを変更する」と勘違いしがちですが、スクリーングを生むのは登録済み時の差分応答なので2-bが対象です。
• 「メール送信有無で判別される」と考え、送信処理を抑制しようとするミス。実際は画面メッセージの違いが問題です。

FAQ