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

解答の論理構成

1. 表1の説明には、 「“利用者の入力を基に HTTP レスポンスヘッダを生成する処理において、①改行コードを意味する文字列を入力したときに、HTTP ヘッダフィールドが追加されないことを確認する。」
   とあります。
2. HTTPヘッダは CR（Carriage Return, 0x0D）と LF（Line Feed, 0x0A）の並び “CRLF” で区切られます。これを挿入できると攻撃者は任意のヘッダやボディを追加できるため、脆弱性検査では “改行コードを意味する文字列” を入力してヘッダインジェクションの可否を確認します。
3. 選択肢を確認します。
   • ア：%0D%0A … URLエンコードされた “CR” と “LF”。
   • イ：%20 … URLエンコードされた半角スペース。
   • ウ：
     、エ：
     … HTML上の改行・段落タグ。
4. HTTPで問題となるのは “CRLF” であり、その URL エンコード表現が %0D%0A です。
5. したがって、①に入る文字列は ア となります。

誤りやすいポイント

• HTMLタグ（
  、
  ）は表示用の改行・段落であり、HTTPヘッダの区切りには無関係です。
• 単なる %20（スペース）ではヘッダは区切れずインジェクションは発生しません。
• 「改行＝LF だけ」と早合点し %0A を想起する受験者もいますが、HTTPヘッダの終端は必ず “CRLF” の連続である点に注意が必要です。

FAQ

解答の論理構成

1. 【問題文】の引用
   表1の「SQL インジェクション」対策には、 “SQL 文の組立てにおいて、SQL 文のひな形の中に②変数の場所を示す？記号を置く技法を利用する。”
   と記載されています。
2. “？記号を置く技法”は、SQL で値を埋め込む際に ? を使って変数の位置だけを示し、後から値をバインドする方法を意味します。
3. JDBC では prepareStatement() を用い、? を **「プレースホルダ」**にして setInt や setString で値を設定します。
4. したがって、下線②の名称は「プレースホルダ」となります。

誤りやすいポイント

• “バインド変数”と混同する
  両者は密接に関連しますが、表1が問うのは 記号の名前であり、技法全体ではありません。
• “プリペアドステートメント”と書く
  これは API 機能名であって “？記号”自体の呼び名ではないため不適切です。
• 英語で “placeholder” と記載する
  日本語指定の問題ではカタカナ表記「プレースホルダ」が無難です。

FAQ

解答の論理構成

1. 表1「メールヘッダインジェクション」の対策欄には
   “(3) 外部からの入力の全てについて、aを削除する。”
   と記載されています。
2. メールヘッダインジェクションは、ヘッダ区切りとして使われる CRLF（キャリッジリターン＋ラインフィード）、すなわち改行文字列を混入させることで、攻撃者が任意のヘッダを追加・改ざんする脆弱性です。
3. 同じ表1の「HTTP ヘッダインジェクション」対策検査項目でも “①改行コードを意味する文字列” が示されており、ヘッダ系インジェクションで問題となる文字列が改行コードであることが強調されています。
4. 以上より、a に入る字句は「改行コード」であると結論付けられます。

誤りやすいポイント

• 「CR」「LF」「CRLF」など英字表記で解答してしまう。表1は日本語で“改行コード”と書いているため、英字のみでは減点対象になり得ます。
• メール本文のサニタイズと混同し、「HTMLタグ」や「スクリプト」と誤答するケース。メールヘッダインジェクションはヘッダ行の区切り文字が核心です。
• 「タブ」「スペース」と回答するミス。ヘッダ区切りはタブやスペースではなく、改行コードです。

FAQ

解答の論理構成

• 【問題文】には「方法1：…GETリクエストのクエリ文字列に、“id=プロジェクトID”の形式で指定する。情報選択機能は、クエリ文字列からプロジェクトIDを取得する。」とあります。
• さらに「情報セキュリティ部は…③そのプロジェクトに参加しているかのように偽ってリスト可能…これは、情報選択機能においてクエリ文字列で受け取ったプロジェクトIDをチェックせずに利用していることに起因していた。」と指摘されています。
• つまり、利用者は自分のブラウザで送信する URL のクエリ文字列を書き換えるだけで、任意のプロジェクトIDをサーバ側に渡せます。チェックがないため、そのプロジェクトに属していなくても情報選択機能は受け入れてしまいます。
• したがって「未参加のプロジェクトのプロジェクトIDをクエリ文字列 id= に指定してアクセスする」という操作が、参加を偽る具体的手口となります。

誤りやすいポイント

• セッションIDが安全だからといって、クエリ文字列経由の値まで正しいと誤信する。
• 「id」というパラメータ名を固定値だと思い込み、ユーザが改変できないと考える。
• フロントエンドのプルダウン変更だけを想定し、直接 URL 入力やリクエスト改ざんを想像できない。

FAQ

解答の論理構成

1. 方法1は【問題文】の引用「“id=プロジェクトID”の形式で指定する。情報選択機能は、クエリ文字列からプロジェクトIDを取得する。」とあるように、プロジェクトIDをURLのクエリ文字列としてブラウザから送る設計です。
2. この設計では、同じく引用「③そのプロジェクトに参加しているかのように偽ってリスト可能」で示されたように、利用者が値を改ざんして別プロジェクトIDを送信でき、アクセス制御が破られます。
3. 方法2は引用「情報選択機能の利用時に、セッション情報から利用者情報を取得する。情報選択機能は、当該利用者情報からプロジェクトIDを取得する。」と記述されており、プロジェクトIDをサーバ側セッションから取り出します。
4. セッションIDは【問題文】注記のとおり「ログイン時に発行される推測困難な値であり、secure属性が付与されたcookieに格納」されているため、利用者はセッション内容を直接変更できません。
5. したがってプロジェクトを示すパラメタが外部入力ではなくなり、パラメータ改ざんが不可能となるため、「④方法1の脆弱性が方法2で解決される」と結論付けられます。

誤りやすいポイント

• 「セッションもHTTPリクエストだから改ざんできる」と思いがちですが、セッション属性はサーバ側保管です。改ざん可能なのはクッキー値であり、そこにプロジェクトIDは入っていません。
• 「Referer や Hidden フィールドに変えても同じ」と誤解しやすいですが、どちらもクライアント送信値なので本質的な対策になりません。
• セッション固定攻撃と混同し、方法2でも危険と判断してしまうケースがありますが、本問はセッションID自体が推測困難で secure 属性付きと明示されています。

FAQ

解答の論理構成

1. 図2 及び図3 には共通して
   「java.sql.b stmt = con.prepareStatement(sql);」
   というコードが示されています。
2. con.prepareStatement(sql) は JDBC において プリコンパイルされた SQL 文のオブジェクトを生成し、その戻り値の型は java.sql.PreparedStatement です。
3. さらに、表1 の「②変数の場所を示す？記号」を使う対策は プリペアドステートメントによるパラメータバインディングを指しており、PreparedStatement を用いた実装であることと整合します。
4. 以上より、b に入る適切な字句は PreparedStatement、解答群の記号では「ウ」と判断できます。

誤りやすいポイント

• Statement と PreparedStatement の混同
  • Statement でも SQL は実行できますが、パラメータを安全に埋め込む機能はなく、「SQL インジェクション」対策になりません。
• クラス名と生成メソッドの組合せミス
  • con.prepareStatement(...) を呼び出している場合、戻り値を Statement 型の変数に代入するとコンパイルエラーになります。
• ドライバ取得メソッド DriverManager.getConnection に引きずられ「イ」を選択してしまうケース。クラス名が似ていても用途が異なります。

FAQ

FAQ

解答の論理構成

1. 【問題文】図2の 7 行目では
   String sql = "SELECT 情報番号、情報名 FROM 情報管理テーブル WHERE プロジェクトID = ?";
   とあり、? のプレースホルダで 「SQL 文のひな形」 を構成しています。
2. 続く 8 行目で
   java.sql.b stmt = con.prepareStatement(sql);
   と変数 stmt が生成されています。stmt は java.sql.PreparedStatement 型で、後続のバインドや実行を担当します。
3. 9 行目の空欄 c は、この PreparedStatement 変数に対して setInt を呼び出し、先ほどのプレースホルダに値をバインドする箇所です。
   したがってメソッドを呼ぶ対象は 8 行目で宣言した stmt である必要があります。
4. よって、c に入る適切な字句は
   stmt です。

誤りやすいポイント

• 8 行目で b に当たる型名と c に当たる変数名を混同し、両方に同じ語を入れてしまうケース。
• PreparedStatement を意味する ps や pstmt など、社内コーディング規約に基づく別名だと思い込む誤答。
• con.prepareStatement(sql) を一行で書き出す例に慣れておらず、変数 stmt の存在自体を見落とすミス。

FAQ

解答の論理構成

1. 図3―8行目
   String sql = "SELECT 情報番号、情報名、情報内容 FROM 情報管理テーブル WHERE d";
   ここで d には WHERE 句が入ります。
2. 同ソース内の変数定義
   • 3行目で int documentNo = Integer.parseInt(request.getParameter("no")); として **リクエストから「情報番号」**を取得。
   • 7行目で int projectId = (省略); として **セッション情報から「プロジェクトID」**を取得。
3. 要件
   〔Sシステムの改修におけるアクセス制御要件の追加〕には
   “情報が表示できる利用者を、情報の作成者と同じプロジェクトに参加する利用者に限定”
   とあり、プロジェクト単位での絞り込みが必須です。
4. SQL の組み立て方
   表1―項番2の対策にある “②変数の場所を示す？記号を置く技法” ＝ プレースホルダを用いる指針に従うと、 d には2つのパラメータプレースホルダ ? を並べることになります。
5. 以上より、documentNo に対応する **「情報番号」**と projectId に対応する **「プロジェクトID」**を AND で結合した条件が正解です。
   ⇒ d = 情報番号 = ? AND プロジェクトID = ?

誤りやすいポイント

• 「情報番号 = ?」だけを書き、プロジェクト確認を忘れる。これでは改修目的のアクセス制御が成立しません。
• 条件を逆順に書いて “プロジェクトID = ? 情報番号 = ?” のように AND を省略する。SQL 構文エラーになります。
• プレースホルダを使わず直接数値連結を行い、SQL インジェクションを再度招く。

FAQ