情報処理安全確保支援士 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. 最終的に、

sql = sql + " WHERE head.order_no = ? ";
PreparedStatement stmt = conn.prepareStatement(sql);
stmt.setString(1, inOrderNo);

誤りやすいポイント

• プレースホルダ ? の前後に引用符 ' を残す
  （例：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

解答の導き方

1. 修正内容の確認
   • 「（1）図4の2行目から5行目までのソースコードを削除する」とあるため、以前のようにクラス内の静的変数とセッタで注文番号を共有する方式はやめています。
   • 図6に「public OrderInfoBean getOrderInfoBean(g) {」とあり、getOrderInfoBeanが引数を受け取るように変更されたことが示されています。
   • 図7に「OrderInfoBL　orderInfoBLObj　＝　h　OrderInfoBL();」および「OrderInfoBean　orderInfoBeanObj　＝　orderInfoBLObj．i；」とあるので、サーブレット側でOrderInfoBLのインスタンスを作成し、そのインスタンスのメソッドを呼んでいることが分かります。
   • 図5に「3: String orderNo; //注文番号」とあり、サーブレット側で注文番号はString型の変数orderNoとして保持していることが分かります。
2. g（メソッド引数）の決定理由
   • getOrderInfoBeanは注文番号を外部から受け取って処理する設計に変更されたため、引数は注文番号の型に合わせる必要があります。サーブレットの変数は「String orderNo」であるので、引数の型はStringです。
   • 引数名については呼び出し側の変数名と一致している必要はありません（Javaでは型と順序が一致すれば呼び出せます）が、図7で実際に渡しているのがorderNoであることから、問題の文脈では「String orderNo」が最も自然で適切です。
   • 以上より、図6の g には 「String orderNo」が入ります。
3. h（インスタンス生成演算子）の決定理由
   • 図7の左辺はローカル変数にインスタンスを代入する形になっており、右辺にはOrderInfoBLの生成式が入るべきです。Javaでオブジェクトを生成する演算子はnewです。
   • したがって、図7の h には 「new」が入ります。
4. i（メソッド呼び出し）の決定理由
   • 図6でgetOrderInfoBeanが引数を取るようになったため、図7での呼び出しも引数付きで行う必要があります。サーブレット側の注文番号変数は「orderNo」なので、呼び出しはgetOrderInfoBean(orderNo) です。
   • 以上より、図7の i には 「getOrderInfoBean(orderNo)」が入ります。

誤りやすいポイント

• DeliverySlipBLや別箇所にある引数名の「inOrderNo」と混同して「String inOrderNo」を選んでしまう。図5ではサーブレット側の変数が「String orderNo」である点を優先すること。
• メソッドの引数名は呼び出し側と同じである必要はないと混乱する（型が一致すれば呼び出せる）が、設問文の図7の記述と整合する名前を答えること。
• インスタンスメソッドを呼ぶのにインスタンス生成を忘れて静的呼び出しの形にしてしまう（newを入れない／入れ方を誤る）。
• getOrderInfoBeanに引数が必要になっているのに空の呼び出しgetOrderInfoBean() を書くミス。
• 根本原因を見落とし、static変数を残したままにして並行実行の不具合を解消していない理解で回答するミス。

FAQ

解答の論理構成

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

誤りやすいポイント

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

FAQ