情報処理安全確保支援士 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

解答の導き方

1. まず本文から「何が既にできているか」「何が欠けているか」を整理します。問題文は「HTMLフォームによってファイルを選択する機能と、アップロード後にサーバへファイルを保存する機能を追加した」と記載しており、クライアント側でファイル選択とサーバへの保存は行える状態になっています。一方、もともとの構成では「入力チェック機能、入力チェック結果を利用者に通知する機能と、適合したファイルをアップロードする機能はJavaアプレットで実現されており」とあります。つまり、以前はアプレット側で（1）入力チェックと（2）結果通知を行ってからアップロードしていました。
2. なぜサーバ側で追加すべきかを論理的に示します。アプレット実装の一例としてコード中に「private static final long MAX_FILE_SIZE = 1000000; //読み込むことを許すファイルの最大サイズ」とあり、アプレット側でサイズチェック等をしていたことが分かります。しかしHTMLフォーム＋HTTPアップロードに置き換えた場合、クライアント側（ブラウザ）の検査は容易に改ざん・回避され得ます。したがって「クライアントが検査したから安全」という前提は成り立たず、サーバ側で同等の検査を必ず行う必要があります。
3. 以上から、サーバ側で追加すべき機能は次の二つが最小限でありかつ必須です（設問の要件＝二つ）：

• 入力チェック機能
  理由：問題文で定義される「ファイルが決められた書式であることとサイズが規定値以下であることの適合性チェック」をサーバ側で行い、改ざんされたリクエストや直接POSTによる不正なファイルを排除するためです。具体的にはファイル形式検証、サイズ検査（上記MAX_FILE_SIZE相当）をサーバで実施します。
• チェック結果の通知と不適合時の破棄
  理由：もともとアプレットでは「適合している場合…利用者に通知され、ファイル受信モジュールを通してアップロードされ…サーバマシン上にファイルとして保存される。適合していない場合、その旨が通知され、読み込んだデータは破棄されアップロードされない」とあり、この振る舞いを代替方式でも再現する必要があります。サーバは検査結果を利用者に返し、不適合なら保存しない（あるいは一時保存後に確実に消去）して、不要なファイルを残さないようにします。

• 入力チェック機能
• チェック結果の通知と不適合時の破棄

誤りやすいポイント

• クライアント側のHTMLフォームだけで十分と考える誤り：HTTPリクエストは改ざん可能で、サーバ側検査が必須です。
• 「通知」だけ実装してファイルを残す誤り：不適合ファイルを残すとサーバ内に悪意あるデータが蓄積されるリスクがあります。
• サイズチェックをクライアント実装の値に依存する誤り：コードにあるMAX_FILE_SIZEは参考値にすぎず、サーバ側でも同等の制限を厳格に適用すべきです。
• 検査範囲を狭く取る誤り：形式／サイズ以外にファイル名の正規化やパス走査対策、MIME確認等も考慮が必要です（設問の必須項目は形式とサイズですが、運用上の注意点として重要です）。

FAQ

解答の導き方

誤りやすいポイント

• 図1で示されたXシステムの構成要素（入力チェックアプレット／本体モジュール／ファイル受信モジュール）を抜かして書く。
• 図1にない一般用語（例：データベース）や周辺要素だけを挙げ、Xシステムの構成要素を示さない。
• ブラウザやJREといった環境名だけを書いて終わらせ、どのコンポーネントを確認するか明確にしない。
• 字数制限を意識するあまり重要語（例：ファイル受信モジュール）を省略してしまう。

FAQ

解答の論理構成

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

誤りやすいポイント

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

FAQ