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

解答の論理構成

• 問題文には、Java を採用した理由として
  「Javaバーチャルマシンによってメモリの使用状況が管理されるために、C言語又はC＋＋言語で開発したプログラムにおいてよく発生するaによるセキュリティ上の脆弱性が発生しない」
  とあります。
• C／C＋＋で“メモリを使用する際の境界チェックをしない”ことが原因で生じる代表的な脆弱性は「バッファオーバフロー」です。
• Java では配列や文字列アクセス時に境界外参照があれば例外を投げるため、同じタイプの脆弱性は原理的に起こりにくい点が理由として説明されています。
• よって、a に入る字句は
  「バッファオーバフロー」
  となります。

誤りやすいポイント

• 「メモリリーク」と混同する
  → メモリ解放忘れは可用性低下の問題であり、境界チェック不足とは別問題です。
• 「スタックオーバフロー」「ヒープオーバフロー」と細分類で答えてしまう
  → 問題文は C／C＋＋で頻発する一般的な脆弱性を指しており、総称の「バッファオーバフロー」が適切です。
• Java でも OutOfMemoryError があるので勘違いする
  → これはメモリ枯渇であって境界外書き込みではありません。

FAQ

解答の論理構成

1. Javaサーブレットは通常「1インスタンスをマルチスレッドで並行実行」する設計です。したがって同じクラスのインスタンス変数は同時アクセスする全スレッドで共有されます。
2. 図3のコード 12 行目に「File tempPDF;」とあり、これはインスタンス変数です。
3. 22〜32 行目の doGet では、24 行目で「String tempUserID = request.getRemoteUser();」を取得し、25 行目で「tempPDF = new File(...)」と代入し、30 行目で「out.println("<a href="" + KINMUHYO_URL_PATH + tempPDF.getName() + "">…」とリンクを生成しています。
4. 25 名が同時アクセスした状況では、スレッドＡが tempPDF に利用者Ａのファイルパスを設定した直後に、スレッドＢが同じ tempPDF を利用者Ｂのパスで上書きし得ます。
5. 結果としてスレッドＡが 30 行目を実行する時点で tempPDF が利用者Ｂの値となり、利用者Ａは他人の勤務時間集計表を示すリンクを受け取ってしまいます。
6. したがって下線①の苦情は「インスタンス変数 tempPDF が複数スレッドから同時に書き換えられ、誤ったファイル名が生成されたこと」が直接原因となります。

誤りやすいポイント

• Javaサーブレットはリクエストごとにインスタンスを生成すると誤解し、インスタンス変数の共有を見落とす。
• static かどうかだけに注目し、「非 static なら安全」と早合点してしまう。
• request.getRemoteUser() で取得した利用者 ID が常に一致すると考え、後段の変数競合を確認しない。
• テスト環境で単一ユーザのみで試験し、マルチユーザ同時実行による競合を想定しない。

FAQ

解答の論理構成

1. 現象の整理
   • 苦情は「①マニュアルどおりに操作したにもかかわらず、ダウンロードした勤務時間集計表が他人のものだった」というものです。
   • 発生時は「25名」の同時アクセスがあり、別の日にも「23名」で再現しています。これは複数スレッド同時実行時のみ起こる典型的な並行性問題を示唆します。
2. プログラム上の原因
   • 図3で File tempPDF; がインスタンス変数として宣言され、doGet 内で tempPDF = new File(...); と再代入されています。
   • Javaサーブレットは「シングルインスタンス・マルチスレッド」モデルで動作するため、同一インスタンスに対し複数スレッドが doGet を並行実行します。
   • 結果として、一方のスレッドが tempPDF.getName() を出力する直前に、他方のスレッドが tempPDF を上書きし、リンクに誤ったファイル名が入る恐れがあります。
3. 不具合の典型的名称
   • 共有リソースに対する排他制御がなく、スレッド間の実行順序に依存して誤動作が起きるバグは「レースコンディション」または「競合状態」と呼ばれます。
   • よって設問が求める15字以内の呼称は「レースコンディション」または「競合状態」です。

誤りやすいポイント

• Javaサーブレットはスレッドセーフだと誤解し、インスタンス変数を安全に使えると思ってしまう。
• tempPDF を ThreadLocal 変数やローカル変数にしないまま、ファイル名だけランダム化しても根本解決にならない点を見逃しやすい。
• 同時利用者数「25名」「23名」という情報を軽視し、単なるプログラムミスと考えてしまう。

FAQ

解答の論理構成

• ①の現象は「ダウンロードした勤務時間集計表が他人のものだった」という内容であり、同時アクセスが「25名の利用者」に及んでいました。
• 図3では、サーブレットクラスに
  「File tempPDF;」
  が宣言され、doGet 内で
  「tempPDF = new File(KINMUHYO_LOCAL_PATH, tempUserID + ".pdf");」
  と上書きされています。
• Java サーブレットは1インスタンスを複数スレッドで共有するため、インスタンス変数は各リクエスト間で競合します。したがって複数ユーザ処理中に tempPDF の内容が上書きされ、後続行
  「out.println("<a href="" + KINMUHYO_URL_PATH + tempPDF.getName() + "">…」」
  で誤ったファイル名が生成される可能性があります。
• 競合の原因はインスタンス変数である点にあるため、tempPDF をスレッドごとに独立した ローカル変数 とし、各リクエスト専有にすれば問題は解消されます。
• 以上より、模範解答「インスタンス変数tempPDFをdoGetメソッドのローカル変数として定義する。」が導かれます。

誤りやすいポイント

• サーブレットで synchronized を追加してしまう
  → 全リクエストが直列化され性能が極端に低下するリスクがあります。
• tempPDF を ThreadLocal にする案
  → 過剰設計であり、単純なローカル変数化で十分です。
• セッション属性に保存する案
  → ファイル生成を終えれば不要なデータをサーバに長期間残すことになり、メモリを無駄遣いします。

FAQ

解答の論理構成

• 下線①の苦情は、「25名の利用者が同時に勤務時間管理システムへアクセスしていた」ときに発生しています。
• 図3のプログラムでは File tempPDF; がクラス変数として宣言され、doGet 内で
  tempPDF = new File(KINMUHYO_LOCAL_PATH, tempUserID + ".pdf");
  と再代入されています。Javaサーブレットは同一インスタンスをマルチスレッドで使うため、同時アクセス時に変数内容が上書きされ、他人のファイル名がリンクに出力される競合が起こります。
• したがってバグの有無を確認するには、スレッド競合を意図的に誘発する必要があります。
• 具体的には、異なる「6けたの数字からなる従業者番号」をそれぞれ Authorization／Cookie などに設定した複数リクエストを同時に送信し、リンク先が混在するかを観察すればよいと導けます。
• 以上より模範解答「利用者IDが異なる、多数のHTTPリクエストを、ほぼ同時にWebサーバに送信する。」となります。

誤りやすいポイント

• 単発リクエストや順次実行では競合が起きず、再現できないと判断してしまう。
• テスト対象をブラウザ操作に限定し、HTTPレベルでの同時送信（スクリプト／負荷試験ツール）の必要性を見落とす。
• 問題原因を「ファイル名の衝突」とだけ捉え、サーブレットのスレッドモデル（共有インスタンス変数）を理解せず対策を誤る。

FAQ

解答の論理構成

• 【問題文】には「システムの利用者IDには、6けたの数字からなる従業者番号を使用する」とあります。
  → ファイル名に使われる文字列は6桁の数字で推測が容易です。
• 図3のコードでは
  tempPDF = new File(KINMUHYO_LOCAL_PATH, tempUserID + ".pdf");
  として勤務時間集計表を保存し、 out.println("<a href="" + KINMUHYO_URL_PATH + tempPDF.getName() + "">…");
  でそのままリンクを生成しています。
  → ファイル名は「利用者ID.pdf」で固定され、URL も公開領域に配置されます。
• 下線②の説明は「他人のパスワードを使用しなくても、容易に他人の勤務時間集計表をダウンロードできる脆弱性」です。
  → 利用者がログインしなくても、6桁の従業者番号を変えて URL を直接入力すれば該当 PDF が取得できてしまいます。
• 以上より解答は「他人の従業者番号を基に、勤務時間集計表のURLを推測し、ダウンロードを試みる。」となります。

誤りやすいポイント

• パスワード漏えいと混同し、ID・パスワードを盗む方法を書く。
• URL を推測するのではなく PDF の内容を改ざんすると誤解する。
• 「ブラウザの履歴」や「キャッシュ」から取得すると考えてしまう。
• ファイル名に乱数を付与すれば十分と誤認し、本質が公開領域配置にある点を見逃す。

FAQ

解答の論理構成

1. 図4の修正仕様では、ファイルの保存場所を「Web公開領域ではなくJavaサーブレット経由でだけアクセス可能な領域」とし、ブラウザへは直接リンクではなく別のデータを送信する方式に変更しています。
   引用：
   ・「Web公開領域ではなくJavaサーブレット経由でだけアクセス可能な領域に保存する。」
2. 同じ図4の③（問題文では箇条書き 3.）には、 引用：
   ・「Webサーバ内のJavaサーブレットは、bをブラウザへ送信する。利用者は、ブラウザのPDFプラグイン機能によって表示された内容を印刷する。」
   とあります。
3. ブラウザの「PDFプラグイン機能」で閲覧・印刷する前提から、サーブレットが送信するのは HTML ではなく PDF コンテンツそのものだと分かります。
4. したがって b に当てはまる語句は、送信対象を具体的に示す「PDFファイル形式の勤務時間集計表」となります。

誤りやすいポイント

• 「HTML」「リンク情報」など図2の旧仕様に引きずられて記述してしまう。図4はリンクを廃止している点を見落としやすいです。
• 「PDFデータ」や「勤務時間集計表PDF」など曖昧・略語で記入し、設問の意図である“送信する対象を正確に表す”要求を満たせなくなるケース。
• ブラウザのプラグイン機能のヒントを軽視し、画像ファイルやテキストを送ると勘違いするミス。

FAQ