情報処理安全確保支援士 2009年 秋期 午後1 問02

解答の論理構成

1. a に入る語
   • 原文: 「クラス群をa形式で一つにまとめ」
   • Java では複数クラスを単一ファイルにパッケージするときに用いるのは「jar 形式」(Java ARchive) です。
   • 解答: エ「jar」
2. b に入る語
   • 原文: 「有限体上の離散対数問題に基づく署名方式」
   • 離散対数問題を利用する代表的な電子署名方式は「DSA (Digital Signature Algorithm)」です。
   • 解答群の中で該当するのはウ「DSA」。
   • 解答: ウ「DSA」
3. d に入る語
   • 原文: 「Java 2 以降の JRE では、サンドボックス機構におけるd又はSecurityManager を用いて」
   • Java セキュリティアーキテクチャで SecurityManager と対になるクラスは AccessController であり、ポリシによるアクセス制御を司ります。
   • 解答群のアは「Access Controller」で一致します。
   • 解答: ア「Access Controller」
4. e に入る語
   • 原文: 「署名なし Javaアプレットとして実行した場合、dクラスによって、eがスローされる」
   • AccessController がアクセスを拒否するときに投げる例外は java.security.AccessControlException です。
   • 解答群で該当するのはカ「java.security.AccessControlException」。
   • 解答: カ「java.security.AccessControlException」

誤りやすいポイント

• 「有限体上の離散対数問題」というキーワードから「DH」を選んでしまう
  (Diffie-Hellmanは鍵共有であり署名方式ではありません)。
• policytool(キ) はセキュリティポリシファイルを編集する GUI ですが、 サンドボックスを「適用」する主体ではない点に注意。
• 例外名を java.io.IOException と誤解するケース
  (I/O 例外ではなく、セキュリティ違反を示す java.security.AccessControlException が正解)。
• WAR 形式や ZIP 形式と混同して jar を外すミス。
  WAR は Web アプリケーション用、ZIP は汎用圧縮であり文脈が異なります。

FAQ

解答の論理構成

1. 【問題文】には
   「ファイルが決められた書式であることとサイズが規定値以下であることの適合性チェック」
   と明記されています。
   ➔ “規定値以下” なので条件式は「サイズ ≤ 上限値」になる必要があります。
2. 図2のコードでは
   private static final long MAX_FILE_SIZE = 1000000; //読み込むことを許すファイルの最大サイズ
   と上限値を定義し、直後に
   long size = file.length();
   で実際のファイルサイズを取得しています。
3. if 文は「読み込みを許可するファイルだけ後続処理へ進む」ための判定です。
   したがって (size <= MAX_FILE_SIZE) が正しく、解答群では
   ウ：size <= が該当します。
4. もし file <= を選ぶと file は java.io.File 型なので比較演算子が使えずコンパイルエラー、 size >= を選ぶと “上限を超えたものだけ読み込む” という逆の意味になり仕様に反します。

誤りやすいポイント

• 変数名を見落とし file と比較してしまう。file はオブジェクトで数値比較できません。
• “規定値以下” を “未満” と早合点し演算子を逆にする。
• MAX_FILE_SIZE のコメントを読まず、ファイルサイズが「最小値」だと勘違いする。

FAQ

解答の論理構成

1. デフォルトポリシでの権限
   【問題文】には
   「Java 2 以降の JRE では、サンドボックス機構におけるd又はSecurityManager を用いて、任意のセキュリティポリシを適用できる。…署名がない Javaアプレットを実行する場合、そのアクセスは制限される。」
   とあります。したがって署名なしアプレットはローカルファイルへの入出力が禁止です。
2. アプレットがローカルファイルに触れた場合の挙動
   同じく
   「クライアントPCのブラウザ上で…署名なし Javaアプレットとして実行した場合、dクラスによって、eがスローされる。」
   とあり、ファイルアクセスの直前で例外が発生して処理が中断します。
3. 図2で下線がある3文の権限要求
   (ア) JButton loader = new JButton("ファイル読込み");
   画面部品を生成するだけでローカル資源を要求しません。よって実行可能です。
   (イ) fileData = new byte[(int)size]; の前に FileInputStream in = new FileInputStream(filePath); があり、ここでローカルファイルを開くため権限が必要です。署名がないため前項の例外が発生し実行されません。
   (ウ) errNo = inputCheck(fileData); は (イ) が成功しないと到達しません。
4. 以上より実際に動くのは (ア) だけです。
   解答： （ア）

誤りやすいポイント

• 「byte 配列を確保するだけだから (イ) も動く」と思い込みがちですが、実際には直前の FileInputStream が権限制限に引っ掛かります。
• 署名の有無と JRE バージョンの話を混同し、脆弱性が無い環境なら全て動くと早合点しやすいです。
• inputCheck はアプレット側ロジックなので安全と思って (ウ) を選びがちですが、呼び出し前に例外で処理が停止します。

FAQ

解答の論理構成

• 【問題文】には「当該脆弱性を悪用すると、署名なし Java アプレットであっても、この制限を回避して、ローカルのコンピュータリソースにアクセスできてしまう。」とあります。脆弱性を利用する主体は“署名なし Java アプレット”であり、これは外部サイトから配布される可能性が高いです。
• さらに「普段 B社従業員らがインターネットの閲覧にも用いる社内標準仕様のプラウザを用いて、クライアントPC上で行っている。」とあるように、在庫管理と同じブラウザで一般の Web サイトも閲覧しています。
• したがってクライアントPC の JRE を更新しないまま外部サイトを閲覧すると、悪意のある“署名なし Java アプレット”が読み込まれ、ローカル資源に不正アクセスされるおそれが顕在化します。
• よって「XシステムのクライアントPC上のブラウザでインターネットのWebブラウジングを行うとき」が危険度の高まる場面となります。

誤りやすいポイント

• 「Xシステム専用ブラウザなので安全」と思い込み、社員が同一ブラウザで外部サイトを閲覧している事実を見落とす。
• 署名付きアプレットだけが危険と誤解し、【問題文】で指摘されている“署名なし”アプレットのサンドボックス回避を軽視する。
• 脆弱性が「サーバ側 JRE」のみ関係すると勘違いし、クライアント側で読み込むアプレット経由のリスクを評価しない。

FAQ

解答の論理構成

• 【問題文】には、Javaアプレットで実現していた三つの機能として
  「ファイルが決められた書式であることとサイズが規定値以下であることの適合性チェック(以下、入力チェックという) 機能、入力チェック結果を利用者に通知する機能 と、適合したファイルをアップロードする機能」が明示されています。
• 代替方式では「HTML フォームによってファイルを選択する機能」と「アップロード後にサーバへファイルを保存する機能」を既に追加するとあるため、アプレットが担っていた残りの機能はまだサーバ側にありません。
• したがってサーバ側で新たに補完すべきなのは、
  1. 「入力チェック機能」そのもの
  2. 入力チェックの結果に応じた処理 ― 具体的には
     ・結果をクライアントに返して利用者へ通知すること
     ・不適合ファイルであればサーバに残さず削除すること
• 設問は「二つ挙げよ」としているため、「チェック結果を利用者へ通知する機能」「アップロードされたファイルを消去する機能」を答とします。

誤りやすいポイント

• 「入力チェック機能」を回答に含めてしまう
  → 問題設定では既に「アップロード後にサーバへファイルを保存する機能」を持つと述べており、チェック自体は当然行う前提と見なされやすい。設問が求めているのはチェック後の追加動作です。
• 「保存機能」や「アップロード機能」を重複して記述する
  → 両者は題意で追加済み。回答字数を浪費して減点になります。
• 「エラーログ出力」など副次的機能を書く
  → 必須要件ではないためポイントから外れます。

FAQ

解答の論理構成

• 【問題文】には「Xシステム全体は、入力チェックアプレット、本体モジュールとファイル受信モジュールで構成されている。」とあります。
  → JRE を更新すれば、これら3要素が新環境でも正しく動くかを確かめる必要が生じます。
• また ①Xシステムのサーバ側とクライアント側のIRE のバージョンアップに伴う確認作業 と明記され、バージョンアップ後の“確認”が論点であると示されています。
• JRE は Java プログラムの実行基盤なので、アップデートにより API 仕様や内部挙動が変わるとアプリケーションが動作しなくなる恐れがあります。
  → 従って「新しいバージョンのJREで、図1の3モジュールが正常動作するか」を確かめることが確認作業の核心になります。
• 以上を踏まえ「新しいバージョンのJREで、本体モジュール、ファイル受信モジュールと入力チェックアプレットの動作確認」という解答に導かれます。

誤りやすいポイント

• 「JRE 自体のインストール確認」と答えてしまい、実際に動かすアプリケーション側の検証を欠いてしまう。
• 図1にない用語（例：データベース、ブラウザ）を対象に挙げて減点される。
• クライアントとサーバの両方で行う点を強調し過ぎ、モジュール名が抜け落ちる。

FAQ

解答の論理構成

• 【問題文】では「Xシステム全体は、入力チェックアプレット、本体モジュールとファイル受信モジュールで構成されている。」とあり、サーバ上で動くのは後者 2 つの Javaアプリケーションだけです。
• 当該脆弱性は「署名なし Java アプレットであっても、この制限を回避して、ローカルのコンピュータリソースにアクセスできてしまう。」というサンドボックス回避に関するものです。
• サーバ側ではアプレット（ブラウザ経由で読み込まれるコード）を一切実行せず、運用上ロードするのは自社が配置した「本体モジュール」「ファイル受信モジュール」だけであるなら、脆弱性を悪用できる Java クラスが入り込む余地がありません。
• したがって「サーバ側のJREを更新しなくても問題ないか」を判断する鍵は、当該 JRE が外部から提供される未署名アプレット／クラスを実行する可能性が存在しないことを確認する点にあります。

誤りやすいポイント

• 「アプレットではないから安全」と短絡し、将来追加される plug-in や運用スクリプトが外部クラスを動的ロードし得ることを見落とす。
• 脆弱性がサンドボックス機構に起因するため、サーバプロセスなら無関係と思い込み、管理系 GUI などでアプレットを使用していないかを確認しない。
• クライアントだけ更新したので十分と判断し、サーバ JRE が Web コンソールなど別用途に共有されていないかを調査し忘れる。

FAQ