【令和4年春期 午後Ⅰ】情報処理安全確保支援士 問題別・学ぶべき知識（Web実装・機器侵害・本人確認）

令和4年春期 午後Ⅰで問われたWeb実装・機器侵害・本人確認の知識を、攻撃・影響・対策の流れと、全設問で必要になる補足知識に分けて整理します。

午後Ⅰ 問１　Webアプリケーションプログラム開発のセキュリティ対策

• 攻撃・原因 → 影響（成立の流れ）

  起点：外部入力のidへ改行コードを混入

  結果・補足：HTTPヘッダーを分割・追加して応答を操作する。HTTP出力では改行を拒否し、SQL値には文字列連結ではなくプレースホルダを使うなど、入力の利用先ごとに対策を変える

• 対策・確認

  プロジェクトIDをクエリ文字列から信用せず、ログイン時にサーバ側セッションへ保存した所属情報を使う。

  情報番号とプロジェクトIDをWHERE条件へ入れ、取得・更新のたびにレコード単位で認可する

  設問別の補足知識（全3設問）

  設問1：

  (1) HTTPヘッダインジェクションは、改行コード（CRLF: %0D%0A）を挿入することで意図しないヘッダフィールドやレスポンスボディを追加する攻撃です。

  (2) SQL文のひな型にあらかじめ変数の位置を予約しておく仕組みを「プレースホルダ（Placeholder）」と呼びます。

  (3) HTTPレスポンスヘッダに挿入される入力値から「改行コード」（CR, LF）を削除またはエスケープすることがヘッダインジェクション対策となります。

  設問2：

  (1) 方法1ではGETリクエストのURLクエリ文字列（?id=プロジェクトID）をそのまま信用していたため、利用者が未参加のプロジェクトIDをURLに指定してリクエストを送信することで他プロジェクトの情報を不正取得できました。

  (2) 方法2ではクライアントから送信されるリクエストパラメタではなく、サーバー側のセッション情報に保存された認証済み利用者情報からプロジェクトIDを取得するため、外部から偽装・改ざんすることができなくなります。

  (3) プレースホルダ（?）を含むSQLを事前コンパイルして実行するJava JDBCのインターフェースは「PreparedStatement」（ウ）です。

  (4) 作成したPreparedStatementオブジェクト（stmt）のsetIntメソッドを呼び出すため、「stmt」が入ります。

  設問3：

  情報表示機能において、情報番号（documentNo）だけでなく、利用者の参加するプロジェクトID（projectId）の両方が一致するレコードのみを抽出することで、他プロジェクトの情報へのアクセスを防止（認可制御）します。

午後Ⅰ 問２　セキュリティインシデント対応

• 攻撃・原因 → 影響（成立の流れ）

  起点：UPnP設定変更でWAN側へ管理機能が公開

  攻撃の進行：パストラバーサルで機密ファイルを読み、OSコマンドインジェクションでtarをsudo実行

  結果・補足：LAN側設定変更や通常操作外領域の暗号化に至る

• 対策・確認

  URLデコード後にパスを正規化して許可ディレクトリ内か検証し、シェルへ渡す値は固定化する。

  POST本文を監査ログへ残し、sudoersではtarへの任意オプションを禁止して、侵入経路と権限昇格を個別に断つ

  設問別の補足知識（全4設問）

  設問1：

  (1) DDNSではホスト名に対応するIPアドレスレコードである「Aレコード」（ア）を更新し、DNSキャッシュによる遅延を抑えるため「TTL（Time To Live）」（エ）を短く設定します。

  (2) WAN側から認証なしのUPnPリクエストを受け付けてしまうと、外部の攻撃者によってルータのポートフォワーディングやファイアウォール設定が勝手に書き換えられ、LAN内機器への侵入を許す危険が生じます。

  (3) ランサムウェアが感染PC経由でSMB共有フォルダを暗号化しただけであればPC権限外のファイルは影響を受けませんが、PCからはアクセス権のない「/root」配下のシステムファイルまで暗号化されていたことから、NAS機器自体が直接侵害されたと判断できます。

  設問2：

  (1) 相対パス記法（../や..%2f）を用いてアクセス制限されたディレクトリ外のファイルにアクセスする攻撃は「パストラバーサル（ディレクトリトラバーサル）」です。

  (2) 入力値にセミコロン等を付加して不正なシステムコマンドを実行させる攻撃は「OSコマンドインジェクション」です。

  (3) URLエンコードされたトラバーサル文字（%2f等）を検知するためには、まず「URLデコード（e: ア）」を行い、次に「パス名の正規化（f: ウ）」を実施して本来の参照先パスを確定させた上で、「除外リストとの比較（g: イ）」を行う必要があります。

  設問3：

  (1) Webサーバーの標準的なアクセスログにはリクエスト行（URIおよびクエリ文字列）は記録されますが、POSTリクエストのメッセージボディの内容は記録されないためです。

  (2) sudoers設定で引数をワイルドカードで許可せず、使用する固定引数のみを指定するか、ラッパースクリプト経由で実行させることで不正なオプション（--checkpoint-action等）の実行を防止します。

  設問4：

  検索エンジンのクローラーに対して該当Webページを検索インデックスに登録させないよう指示するrobotsメタタグの値は「noindex」または「none」（noindex, nofollowと同義）です。

午後Ⅰ 問３　スマートフォン向けQRコード決済サービスの開発

• 攻撃・原因 → 影響（成立の流れ）

  起点：漏えいした口座番号・暗証番号で第三者が決済口座を登録

  攻撃の進行：他人になりすまして送金する

  結果・補足：本人確認書類、容貌、都度表示するランダム数字を同時撮影するeKYCで実在性と同一性を確認する

• 対策・確認

  署名用電子証明書は有効期限と失効状態まで検証する。

  スマートフォン盗難時はアプリ起動PINで端末内の鍵・決済機能を保護し、生体認証だけに本人確認全体を委ねない

  設問別の補足知識（全3設問）

  設問1：

  身元確認は登録する氏名・住所等が正しいことを確認する行為であるため初回登録である「アカウント作成（a: イ）」時に行います。

  当人認証は登録済みアカウントの正当な保有者であることを確かめる行為であるため「Qサービスへのログイン（b: ア）」時に行います。

  設問2：

  (1) 攻撃者が事前に入手した他人の銀行口座情報（漏洩リストやフィッシング詐欺などで不正取得した口座番号および4桁の暗証番号）を入力して連携させる手口です。

  (2) オンライン本人確認（eKYC）において、本人確認書類の偽造防止および顔写真との照合を行うため「写真（顔写真）」付きの本人確認書類（運転免許証やマイナンバーカード等）を用います。

  (3) マイナンバーカード内のICチップに格納された「秘密鍵（d: ウ）」で署名を生成し、認証側は証明書に含まれる「公開鍵（e: イ）」で検証します。

  (4) 電子証明書が現在失効（失効申請や名義変更など）していないか、有効期間内であるかをJ-LIS（地方公共団体情報システム機構）の公的個人認証サービスに問い合わせて確認します。

  (5) あらかじめ用意された静止画や動画の使い回し（なりすまし）を防止するため、アプリ側が毎回指定するランダムな番号を手書きした紙を同時に撮影させる（動的チャレンジ）手法です。

  設問3：

  (1) スマートフォンを紛失または盗難された場合、端末の画面ロックがないと拾得者・盗難者がログイン済みQアプリをそのまま起動して決済できてしまいます。

  (2) 端末自体のログイン保持とは別に、決済アプリ起動時や送金実行時にPINコード（暗証番号）や生体認証（指紋・顔認証）を要求する機能を追加します。