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

解答の論理構成

1. 静的解析ツールの指摘は「ディレクトリトラバーサル」であり、 「ファイルアクセスに用いるパス名の文字列作成で、利用者が入力したデータを直接使用している。」と説明されています。
2. 図1のソースコードを確認すると、入力値 inOrderNo を含めて OS のパス文字列を生成している箇所は次の行です。
   13: File fileObj = new File(PDF_DIRECTORY + "/" + clientCode + "/" + "DeliverySlip" + inOrderNo + ".pdf");
   ここで inOrderNo はサーブレットから受け取った利用者入力であり、パスに直接連結されています。
3. 以上より、a に該当する行番号は「13」と判断できます。

誤りやすいポイント

• 行「12: String clientCode …」を選んでしまうケース
  • clientCode も文字列ですが、ディレクトリ名生成そのものは行 13 で行われます。
• 「SQL インジェクション」の修正箇所（8〜11 行目）と混同するケース
  • 同じ入力値 inOrderNo を扱っているため要注意です。
• 「ファイル存在確認 → 入力チェック済み」と早合点するケース
  • 存在確認の前にファイルパスが生成されている点を見落としがちです。

FAQ

解答の論理構成

1. 表1の指摘内容には「変数 stmt、変数 resultObj、変数bが指すリソースが解放されない。」とあります。
2. 図1のリソース生成箇所を確認すると、次の3種類のリソースが生成されています。
   • 10行目：Statement stmt = conn.createStatement();
   • 11行目：ResultSet resultObj = stmt.executeQuery(sql);
   • 14行目：BufferedInputStream in = new BufferedInputStream(new FileInputStream(fileObj));
3. 表1で既に列挙済みの stmt と resultObj に続く“3番目のリソース”は、図1の14行目で生成された BufferedInputStream 型の変数です。ここで使われている変数名は「in」です。
4. よって、b に入る適切な変数名は「in」になります。

誤りやすいポイント

• buf と回答してしまう
  • byte[] buf = new byte[in.available()] はメモリ領域の確保であり、ファイルやストリームのような「外部リソース」ではないため解放対象ではありません。
• fileObj と回答してしまう
  • File オブジェクト自体はディスクリプタを保持せず、明示的な close は不要です。
• ソース全体を見ずに行番号だけに着目する
  • 表1の指摘は行番号ではなく「リソース解放漏れ」に関する網羅性を問うため、登場する全てのリソース型変数を確認する必要があります。

FAQ

解答の論理構成

1. 静的解析ツールが指摘した項番1は「SQL インジェクション」です。図1の
   sql = sql + " WHERE head.order_no = '" + inOrderNo + "' ";
   という記述は、利用者入力 inOrderNo を文字列連結しており、攻撃者が任意の SQL を注入できる危険があります。
2. 図2ではこの脆弱性を除去するため、SQL 文にプレースホルダを用いて PreparedStatement でバインド方式に変更しています。したがって c には「プレースホルダ付き WHERE 句」をそのまま文字列として設定する必要があります。
   ・従来の文字列連結部分をそのまま残すと意味がない
   ・setString で 1 番目のパラメータへ inOrderNo を束縛するため、? が 1 個だけ必要
   よって c は
   WHERE head.order_no = ?
   が適切です。
3. Statement を生成していた 10 行目もプレースホルダ処理に合わせて PreparedStatement に置き換えます。図2の d には
   PreparedStatement stmt = conn.prepareStatement(sql)
   が入ることが示されています（模範解答より）。
4. 最終的に、 java sql = sql + " WHERE head.order_no = ? "; PreparedStatement stmt = conn.prepareStatement(sql); stmt.setString(1, inOrderNo);
   という形になり、ユーザ入力が SQL 文に直接挿入されないため、指摘事項「SQL インジェクション」が解消されます。

誤りやすいポイント

• プレースホルダ ? の前後に引用符 ' を残す
  （例：WHERE head.order_no = '?'）とバインド時に型不一致や検索失敗を招きます。
• PreparedStatement 生成後に executeQuery(sql) を呼び出す
  （正しくは executeQuery()）。ツールでは検出されても実行時にエラーになります。
• setString の添字を 0 から始めると java.sql.SQLException が発生します。Java の JDBC は 1 始まりです。

FAQ

解答の論理構成

• 【問題文】には「原因は、図4で変数 e が f として宣言されていることである。」とある。
• 図4の2行目には「private static String orderNo; //注文番号」と記載されており、ここで使われている変数名が e に該当する。
• したがって e に入る変数名は「orderNo」となる。
• さらに図4の8行目以降で「psObj.setString(1, orderNo);」と利用されていることから、注文番号を保持する目的の変数であると確認できる。
• 以上より、e の正答は【 orderNo 】となる。

誤りやすいポイント

• 静的解析で指摘された納品書PDFダウンロードクラス（図1・図2）と、今回問われているビジネスロジッククラス（図4）を混同してしまう。
• 「static」の有無だけに注目し、変数名を見落とすと「orderNo」以外のキーワードを記入してしまう。
• 図5のサーブレット側にも「orderNo」が局所変数で登場するため、両者を区別しないと混乱しやすい。

FAQ

解答の論理構成

• 【問題文】には「原因は、図4で変数 e が f として宣言されていることである。」とあり、図4の2行目には
  2: private static String orderNo;
  と示されています。ここから f に入る語が static であることが読み取れます。
• static 修飾子で宣言したフィールドはクラスに一つしか存在せず、全スレッド・全インスタンスで共有されます。
• 【問題文】では不具合の性質を「①並列動作する複数の処理が同一のリソースに同時にアクセスしたとき、想定外の処理結果が生じる」と説明しています。orderNo が共有されてしまうため、あるリクエストが OrderInfoBL.setOrderNo で値を設定した直後に、別のリクエストが上書きし、最初のリクエストが誤った注文番号で検索を実行する ―― まさに並行アクセスによるレースコンディションです。
• よって f には static が入ります。

誤りやすいポイント

• private や String といったキーワードを原因と勘違いし、アクセス修飾子や型に意識が向き過ぎる。
• static メソッドと static フィールドを混同し、「メソッドが static だから問題」と誤解する。実際の不具合はフィールド共有によるものです。
• 「Servlet はシングルスレッドで動く」と思い込み、マルチスレッド環境でのクラス変数共有問題を軽視する。

FAQ

解答の論理構成

1. 【問題文】では「①並列動作する複数の処理が同一のリソースに同時にアクセスしたとき、想定外の処理結果が生じる」と明記されています。
2. この現象は、処理(スレッドやプロセス)間でリソース共有の同期が取れていないために発生します。
3. コンピュータシステムの典型的な障害分類では、上記のような“同時アクセスによる競合”を「レースコンディション」と呼びます。
4. よって、設問の下線①の不具合名は「レースコンディション」と判断できます。

誤りやすいポイント

• 「デッドロック」と混同する
  同期が取れていない点は同じですが、デッドロックは“お互いがロックを待ち続けて停止する”状態であり、想定外のデータ混在や上書きは起きません。
• 「クリティカルセクション」がキーワードだと思い違いする
  クリティカルセクションは対策概念であり、不具合名ではありません。
• “競合状態”を日本語そのままで書いてしまう
  出題は正式な用語を求めているため、「レースコンディション」と記述する必要があります。

FAQ

解答の論理構成

• 【問題文】では、並列アクセスによる不具合の原因を「図4で変数 e が f として宣言されている」ことと説明し、対策として
  （1）「図4の2行目から5行目までのソースコードを削除する。」
  （2）「図4の6行目を、図6に示すソースコードに修正する。」
  （3）「図5の4行目と5行目を、図7に示すソースコードに修正する。」
  と指示しています。
• まず（1）で削除されるのは
  private static String orderNo; public static void setOrderNo(String inOrderNo) { … }
  すなわち static フィールドと static セッタです。よって以降は「インスタンスメソッドに引数で注文番号を渡す」形に改めなければなりません。
• （2）の図6は「public OrderInfoBean getOrderInfoBean(g) {」という宣言のみ示されており、ここに入るのは「呼び出し側（サーブレット）から渡される注文番号」の型と変数名です。メソッド本体には既に
  psObj.setString(1, orderNo);
  という参照が残っているため、パラメータ名は orderNo でなければコンパイルできません。型は文字列なので String orderNo となります。したがって
  g：String orderNo
• （3）の図7 1 行目はインスタンス生成文を示しており、Java でオブジェクトを生成するキーワードは new しかありません。
  h：new
• 同じく図7 2 行目はインスタンスメソッド呼出しであり、引数に注文番号を渡しているため
  i：getOrderInfoBean(orderNo)
  となります（【模範解答】もこれを示しています）。

誤りやすいポイント

• 「static の削除」＝「そのまま static 呼出しをインスタンス呼出しに変えるだけ」と思い込み、メソッドに引数を追加し忘れる。
• 図4内部の orderNo 参照を見落とし、パラメータ名を inOrderNo などにしてしまいコンパイルエラーになる。
• Java のインスタンス生成キーワードを new() と書く、あるいは OrderInfoBL() だけにしてしまうミス。

FAQ

解答の論理構成

1. セッションに保持されている情報を確認
   • 【問題文】「ログイン処理時に、ログインした利用者IDと、利用者IDにひも付く得意先コード及び得意先名はセッションオブジェクトに保存されている。」
     ⇒ セッションには「得意先コード」が格納済みです。
2. 追加すべき抽出条件の指示内容を確認
   • 【問題文】「図4の10行目の抽出条件に、セッションオブジェクトに保存されたjと注文ヘッダーテーブルのjの完全一致の条件をAND条件として追加する。」
     ⇒ セッションにある属性と注文ヘッダーテーブル上の同一属性を照合する必要があります。
3. 注文ヘッダーテーブルに存在する対応属性を確認
   • 【図3】注文ヘッダーテーブルの属性一覧に「得意先コード」が存在。
   • 利用者マスターにも「得意先コード」が存在し、セッション保持情報とも一致。
4. 上記 1〜3 から、セッションと注文ヘッダーテーブルの両方に共通に存在し完全一致を取るべき属性は「得意先コード」であると結論付けられます。

誤りやすいポイント

• 「利用者ID」と誤認する
  セッションには利用者IDも保存されますが、注文ヘッダーテーブルには利用者IDが存在しないため抽出条件に使えません。
• 「注文番号」を選択する
  既に WHERE 句で完全一致条件が設定済み（図4 13行目）なので追加条件には該当しません。
• 「得意先名」を選ぶ
  文字列表記ゆれや重複のリスクがあり、リレーションも外部キーではないため誤りです。

FAQ