令和6年度 春期 情報処理安全確保支援士試験 午後 問題 問4 セキュアプログラミングとOS権限設計
テクノロジセキュリティ技術
この問題は2024(R6)春 情報処理安全確保支援士 午後に出題されたものです。出題時点の法令・制度に基づく内容のため、現行の内容と一致しない場合があります。
本ページの問題文・選択肢は、原本の体裁を Web 表示用に正規化しています(改行・記号・数式・図表参照の調整)。設問の趣旨および正解に影響する変更は加えていません。
学習ガイド
JavaとRDBMSで実装されたWeb受注システムのセキュリティレビューを題材に、セキュアプログラミングとOSの権限設計を問う問題です。OSアカウントと所属グループの権限表から、アクセス禁止のはずの情報に触れてしまう組合せを見つける設問は、最小権限の原則を手を動かして適用する良い訓練になります。この記事では、権限マトリクスの読み方から始めて、ソースコードの修正すべき行とその根拠を特定していきます。
この記事で押さえる論点
- Linuxの所有者・グループ・権限設定から情報漏えいの穴を見つける
- Javaコードの脆弱な箇所を行番号レベルで特定し修正する
- 最小権限の原則をファイル・DB・プログラムに一貫して適用する
出題情報
- 出題
- 2024(R6)春 情報処理安全確保支援士 午後 問4
- 配点
- 50点満点
- 模範解答
- 公表(設問ごとに掲載)
出題趣旨・採点講評(IPA 公表)
JavaとRDBMSで実装されたWebアプリケーションプログラムの開発において,有識者によるセキュリティレビューを実施することによって,セキュリティの不備が発見される場合がある。本問では,JavaとRDBMSで実装されたWebアプリケーションプログラムを題材として,セキュアプログラミングに関する能力を問う。
問4では,Webアプリケーションの脆弱性対策を題材に,Linuxの権限設定及びセキュアコーディングについて出題した。全体として正答率は平均的であった。
問題本文
問4 Webアプリケーションプログラムに関する次の記述を読んで,設問に答えよ。
A社は,加工食品の製造・販売を行う従業員500名の会社である。問屋や直販店からの注文の受付に,商品の注文と在庫を管理するシステム(以下,業務システムという)を利用している。業務システムは,A社内に設置したサーバ上に構築されている。
このたび,販売拡大を目指して,インターネットを使ったギフト販売を行うことになり,個人顧客から注文を受けるためのWebシステム(以下,Web受注システムという)を構築することになった。
A社はITベンダーのB社との間で開発の委託契約を締結し,両社はWeb受注システムの開発に着手した。
〔Web受注システムの要件〕
Web受注システムの要件を表1に示す。

図の説明テキスト
| No. | 要件名 | 要件内容 |
|---|---|---|
| 1 | 機能 | 個人顧客が利用できる機能:商品検索,在庫照会,注文,決済,注文変更,注文キャンセル,注文照会,配送照会,ユーザー登録,ユーザー情報変更,パスワード変更,退会である。これら機能全てをアプリケーション(以下,APという)サーバに実装する。 その他の機能:(省略) |
| 2 | アクセス方式 | Webブラウザからインターネット経由でアクセスして利用する。 |
| 3 | 想定ユーザー | 個人顧客 |
| 4 | 想定ユーザー数 | 登録ユーザーの数が 100,000 までを想定 |
| 5 | 重要情報 1) に該当するデータ項目 | 氏名,住所,電話番号,メールアドレス,パスワード,銀行口座情報,決済情報 |
| 6 | 商品数 | 1,000 |
| 7 | 想定トランザクション数 | 注文:1,000 件/日 注文変更・注文キャンセル:各 30 件/日 注文照会・配送照会:各 2,000 件/日 |
| 8 | 稼働時間 | 24 時間 365 日。ただし,メンテナンス時間は除く。 |
| 9 | メンテナンス時間 | 毎週月曜日 0:00~5:00。ただし,緊急の脆弱性修正プログラム適用など,他の日時に臨時でメンテナンスを実施する場合もある。 |
| 10 | 稼働率目標 | 99.9%。ただし,メンテナンス時間は除く。 |
| 11 | 開発体制 | A社とB社が協働で開発する。 |
| 12 | 開発言語/DBMS | Java/RDBMS |

図の説明テキスト
| No. | 要件名 | 要件内容 |
|---|---|---|
| 13 | システム基盤 | APサーバ,バッチサーバ,ログサーバは,IaaS上に構築する。Web受注システムのデータベース(以下,データベースをDBという)は,クラウドサービスのマネージドDBを利用する。 本番環境は,本番APサーバ,本番バッチサーバ,本番ログサーバ,本番DBで構成する。 開発環境は,開発APサーバ,開発バッチサーバ,開発ログサーバ,開発DBで構成する。重要情報は保管されない。 |
| 14 | サーバOS | APサーバ,バッチサーバ,ログサーバのOSはLinuxを使用する。 |
| 15 | APログ注2) | APサーバのプログラム及びバッチサーバのプログラムはAPログをログサーバに転送し,ログサーバはAPログをテキストファイル形式で保存する。 |
| 16 | APサーバの標準出力と標準エラー出力 | APサーバの標準出力と標準エラー出力は,リダイレクトしてAPサーバの/var/log/serverlogディレクトリ配下のテキストファイルに出力する。なお,/var/log/serverlogディレクトリのオーナーはwebappuserであり,パーミッションは774注3)とする。その配下のテキストファイルのオーナーはwebappuserであり,パーミッションは664注3)とする。 |
| 17 | システム運用 | システム運用はB社に委託し,システム運用担当者はB社の要員とする。重要情報の取扱いは重要情報取扱運用者だけとし,重要情報取扱運用者はA社での役職が管理職以上の要員とする。各サーバ及び各DBの管理はシステム管理責任者が行い,システム管理責任者はA社の情報システム部の管理職とする。 |
| 18 | システムのユーザーと役割 | (1) 個人顧客 Web受注システムのAPサーバで注文,決済などを行う。 (2) システム運用担当者 本番APサーバ及び本番バッチサーバの稼働を監視する。バッチ処理が異常終了したときは,手動で再実行する。これら以外のサーバについては,統合監視システムの画面から死活監視だけを行う。重要情報にアクセスしてはならない。 (3) 重要情報取扱運用者 本番環境に保管されている重要情報を参照し,個人顧客からの問合せに対応する。 (4) システム開発者 開発環境においてプログラムの開発・保守を行う。障害発生時は,本番ログサーバにアクセスして障害原因を調査する。重要情報にアクセスしてはならない。 (5) システム管理責任者 各サーバのOS,ミドルウェアの脆弱性修正プログラムの適用などのメンテナンス作業を行う。各サーバのOSアカウントを管理する。各DBのアカウント管理を行う。 |
| 19 | パスワードの保存 | パスワードは,CRYPTREC暗号リスト(令和5年3月30日版)の電子政府推奨暗号リストに記載されているハッシュ関数でハッシュ化してDBに保存する。 |
注1) A社では,扱う情報を“重要情報”と“その他の情報”に分類している。
注2) システム稼働時に出力され,システム障害の際に,システム開発者が障害原因調査のために確認するファイルである。
注3) chmodコマンドの絶対モードでLinuxのパーミッションを設定する。
〔Web受注システムの設計〕
A社とB社はWeb受注システムを設計した。
Web受注システムのサーバで定義されるOSアカウントの一覧を表2に,所属グループとその権限を表3に示す。

図の説明テキスト
| No. | ユーザーID | 所属グループ | OSアカウントが定義されるサーバ | 説明 |
|---|---|---|---|---|
| 1 | root | root | (省略) | システム管理責任者が利用する。 |
| 2 | operator | operation | (省略) | システム運用担当者が利用する。 |
| 3 | personal | personal | (省略) | 重要情報取扱運用者が利用する。 |
| 4 | developer | develop | (省略) | システム開発者が利用する。 |
| 5 | batchappuser | operation | 本番バッチサーバ | データ連携機能 1)の各プログラムの実行に利用される。 |
| 6 | webappuser | personal | 本番 AP サーバ | AP サーバのプログラムの実行に利用される。 |
注記 root, operation, personal, develop という所属グループは各サーバに定義されている。
注1) 業務システムと Web 受注システムがデータ連携を行うための機能である。

図の説明テキスト
| No. | 所属グループ | 権限 |
|---|---|---|
| 1 | root | 特権ユーザーである。全てのアクセス権がある。 |
| 2 | operation | 一般ユーザー権限である。本番 AP サーバと本番バッチサーバへのアクセス権がある。 |
| 3 | personal | 一般ユーザー権限である。本番環境へのアクセス権がある。 |
| 4 | develop | 一般ユーザー権限である。開発環境と本番ログサーバへのアクセス権がある。 |
注記 Web 受注システムでは、OS アカウントの権限を所属グループ単位で管理する。
業務システムとWeb受注システムは,CSV形式のデータ連携用ファイル(以下,CSVファイルという)でデータ連携を行う。1時間ごとに業務システムのバッチサーバとWeb受注システムのバッチサーバにおいてCSVファイルを作成し,HTTPSで他方のバッチサーバに送信し,他方のバッチサーバでは受信したCSVファイルを保存する。保存したCSVファイルを使用してWeb受注システム又は業務システムのDBに対して更新処理を実行する。更新処理後のCSVファイルは,障害発生に備えて1週間保存する。
データ連携機能のプログラム一覧を表4に示す。

図の説明テキスト
| No. | プログラム名 | 実行するサーバ | 概要 |
|---|---|---|---|
| 1 | バッチ処理管理1 | Web受注システムのバッチサーバ | Web受注システムの各バッチ処理のプログラムの起動,監視などを行う。 |
| 2 | バッチ処理管理2 | 業務システムのバッチサーバ | 業務システムの各バッチ処理のプログラムの起動,監視などを行う。 |
| 3 | 注文データCSV出力バッチ処理 | Web受注システムのバッチサーバ | Web受注システムのDB内の注文テーブルから注文データを取得し,CSVファイルに出力する。 |
| 4 | 注文データCSV取込みバッチ処理 | 業務システムのバッチサーバ | 保存されたCSVファイルを読み込んで,業務システムのDBを更新する。 |
| 5 | 在庫データCSV出力バッチ処理 | 業務システムのバッチサーバ | 業務システムのDB内の在庫テーブルから在庫データを取得し,CSVファイルに出力する。 |
| 6 | 在庫データCSV取込みバッチ処理 | Web受注システムのバッチサーバ | 保存されたCSVファイルを読み込んで,Web受注システムのDBを更新する。 |
| 7 | データ送信1バッチ処理 | Web受注システムのバッチサーバ | CSVファイルを業務システムのバッチサーバにHTTPSで送信する。 |
| 8 | データ送信2バッチ処理 | 業務システムのバッチサーバ | CSVファイルをWeb受注システムのバッチサーバにHTTPSで送信する。 |
| 9 | データ受信1バッチ処理 | Web受注システムのバッチサーバ | 受信したCSVファイルをWeb受注システムのバッチサーバの指定されたディレクトリに保存する。 |
| 10 | データ受信2バッチ処理 | 業務システムのバッチサーバ | 受信したCSVファイルを業務システムのバッチサーバの指定されたディレクトリに保存する。 |
表4のうち,No. 3のプログラムの内容を図1に示す。

図の説明テキスト
・注文テーブルの連携済フラグ 1) が0である注文データを,CSVファイルとして平文で /var/data ディレクトリに出力する。なお,/var/data ディレクトリのオーナーは batchappuser で,パーミッションは 770 2) とする。CSVファイルのオーナーは batchappuser で,パーミッションは 660 2) とする。
・注文テーブルの内容は,次のとおりである。
注文ID 3),注文番号,注文ユーザーID,注文日時,決済金額,銀行コード,銀行支店コード,預金種別,銀行口座番号,銀行口座氏名,注文ステータス,お届け先郵便番号,お届け先住所,お届け先電話番号,お届け先氏名,送り主郵便番号,送り主住所,送り主電話番号,送り主氏名,連携済フラグ
注1) “0”はCSVファイル出力前であることを,“1”はCSVファイル出力後であることを示す。
注2) chmod コマンドの絶対モードで Linux のパーミッションを設定する。
注3) 主キーである。
Web受注システムの開発が進み,結合テスト前に,A社は,設計書とソースコードのセキュリティレビューを,セキュリティ専門会社のC社に委託した。C社の情報処理安全確保支援士(登録セキスペ)のE氏は,セキュリティレビューを実施した。
〔データ連携機能のセキュリティレビュー〕
E氏は,表2〜4及び図1の内容では表1の要件を満たしておらず,aがCSVファイルを閲覧できてしまうという問題を発見した。また,CSVファイルには重要情報が記録されるので,本番バッチサーバにアクセスできる者が不正に閲覧するリスクを軽減するための保険的対策も併せて実施することを提案した。具体的には,次のように提案した。
(1) 問題に対しては,表2のbatchappuserについて,所属グループをbに変更する。
(2) 保険的対策としては,表4のNo. 3のプログラムに暗号化を行う処理を追加し,表4のNo. cのプログラムに復号を行う処理を追加する。
A社は,E氏の提案どおり修正することにした。
〔ユーザー登録機能のセキュリティレビュー〕
ユーザー登録機能は,UserDataクラスによって実現している。UserDataクラスのプログラム仕様を図2に,UserDataクラスのソースコードを図3に示す。

図の説明テキスト
・addUser メソッドは,データをユーザーマスターテーブルに挿入する。
・各インスタンス変数は,ユーザーマスターテーブルの各レコードに対応し,画面から入力された値を String 型で保持する。
・ユーザーマスターテーブルの列名は,次のとおりである。
ユーザーOID 1), ユーザーID, パスワード 2), 氏名, 郵便番号, 住所, 電話番号, メールアドレス, 作成日時, 更新日時
注1) 主キーである。オブジェクト ID であり,データを一意に識別する文字列が格納される。
注2) パスワードのハッシュ値が格納される。

図の説明テキスト
(省略) //package 宣言,import 宣言など
1: public UserData(HttpServletRequest request) {
2: this.userId = request.getParameter("userId");
3: this.password = request.getParameter("password");
(省略) //入力値チェックなど
4: try {
5: MessageDigest mdObj = MessageDigest.getInstance("SHA-1");
6: byte[] hashByte = mdObj.digest(this.password.getBytes());
7: this.password = String.format("%x", new BigInteger(1, hashByte));
8: } catch (NoSuchAlgorithmException e) {
9: log.debug("error:" + e);
10: }
(省略)
11: }
//引数 conn は DB コネクションオブジェクトを示す。
12: public void addUser(Connection conn) {
13: PreparedStatement psObj;
14: String sql = "INSERT INTO USER_MASTER" +
15: "(USER_OID, USER_ID, PASSWORD, USER_NAME, ZIP_CODE" +
(省略);
16: try {
17: psObj = conn.prepareStatement(sql);
18: psObj.setString(1, this.userOid);
19: psObj.setString(2, this.userId);
20: psObj.setString(3, this.password);
(省略)
//次の 2 行はデバッグログの出力
21: System.out.println("SQL:" + sql);
22: System.out.println("InsertData:" + this.toString());
//次の 2 行はログサーバへの AP ログの出力
23: log.debug("SQL:" + sql);
24: log.debug("InsertData:" + this.toString());
25: psObj.execute();
26: conn.commit();
27: } catch (SQLException e) {
(省略) //例外処理
28: }
(省略)
29: }
(省略)
注記: log.debug()は、引数の文字列をログサーバに送信するメソッドである。
E氏は,図3のソースコードについて,次のように指摘した。
- パスワードからハッシュ値を得るためのハッシュ関数が,表1の要件を満たしていない。
- 今後,メンテナンスなどで実行環境を変更した場合に,d行目でeが発生すると,25,26行目では,パスワードが平文でユーザーマスタテーブルに保存されてしまう。
- ①システム運用担当者とシステム開発者が,要件でアクセスが禁止されている情報にアクセスできてしまう。
- 利用するAPサーバの実装では,変数 psObj の指すメモリ領域においてメモリリークが発生する可能性がある。
E氏の指摘を受け,システム開発者は,UserDataクラスのソースコードを修正した。
修正後のUserDataクラスのソースコードを図4に示す。

図の説明テキスト
(省略) //package 宣言, import 宣言など
1: public UserData(HttpServletRequest request) {
2: this.userId = request.getParameter("userId");
3: this.password = request.getParameter("password");
(省略) //入力値チェックなど
4: try {
5: MessageDigest mdObj = MessageDigest.getInstance("<span id="q4_blank_f" class="blank-label">f</span>");
6: byte[] hashByte = mdObj.digest(this.password.getBytes());
7: this.password = String.format("%x", new BigInteger(1, hashByte));
8: } catch (NoSuchAlgorithmException e) {
9: log.debug("error:" + e);
//回復不能な例外発生
10: <span id="q4_blank_g" class="blank-label">g</span>;
11: }
(省略)
12: }
//引数conn は DB コネクションオブジェクトを示す。
13: public void addUser(Connection conn) {
14: PreparedStatement psObj = null;
15: String sql = "INSERT INTO USER_MASTER" +
16: "(USER_OID, USER_ID, PASSWORD, USER_NAME, ZIP_CODE" +
(省略);

図の説明テキスト
17: try {
18: psObj = conn.prepareStatement(sql);
19: psObj.setString(1, this.userOid);
20: psObj.setString(2, this.userId);
21: psObj.setString(3, this.password);
(省略)
22: UserData userMaskDataObj = this.maskUserData(this);
//次の 2 行はログサーバへの AP ログの出力
23: log.debug("SQL:" + sql);
24: log.debug("InsertData:" + userMaskDataObj.toString());
25: psObj.execute();
26: conn.commit();
27: } catch (SQLException e) {
(省略) //例外処理
28: } <span id="q4_blank_h" class="blank-label">h</span> {
29: if (psObj != null) {
30: try {
31: psObj.close();
32: } catch (SQLException e) {
(省略) //例外処理
33: }
34: }
35: }
(省略)
36: }
37: private UserData maskUserData(UserData inUserData) {
(省略) //UserData 内の重要情報を含む変数の値を * に置換する。
38: return userMaskDataObj;
39: }
(省略)
図4のソースコードについて,E氏は,セキュリティレビューを再度実施した。
E氏は,図4のソースコードでは,レインボーテーブル攻撃を受けたときに攻撃が成立してしまうので,図2の仕様及び②図4のソースコードの6,7行目を修正すべきであると指摘した。
A社は,E氏の指摘の対応を完了した。その後,テストを実施し,Web受注システムをリリースした。
設問と解答・解説
設問1
〔データ連携機能のセキュリティレビュー〕について答えよ。
(1)
本文中の a に入れる適切な字句を,解答群の中から選び,記号で答えよ。
模範解答
選択肢ア: システム運用担当者
配点 4点
解説
システム運用担当者は、本番環境のログ等を確認し、セキュリティインシデントへの対応や権限管理の運用を行う役割を持ちます。したがって、ログの監視・確認主体として適任です。
各選択肢の解説
- ア: 正解。システム運用担当者は本番環境での運用管理やログ監視を担います。
- イ・エ: システム開発者は本番環境へのアクセス権限を持たないべきであり、本番ログの確認主体としては不適切です。
- ウ: システム開発者は本番環境にアクセスするべきではないため不適切です。
- オ: 重要情報取扱運用者は重要情報の取り扱いを行うユーザー側であり、システムログの監視運用を直接行う立場ではないため不適切です。
(2)
本文中の b に入れる適切な所属グループを,表3中から選び答えよ。
模範解答
personal
採点基準(配点 6点)
正確性(内容)(6点)
- 6点: 正解となる所属グループ「personal」が正確に記述されている。
- 3点: 正解に近い記述が含まれるが、不要な文字が含まれているなど完全ではない。
- 0点: 不正解、または無解答。
解説
データ連携機能において、特定のグループに属するユーザーに限定したアクセス制御を行う設定を問う問題です。表3の内容に基づき、該当する所属グループは「personal」となります。
高得点のポイント
- 求められている「personal」というグループ名が正確に抜き出せていること。
- 余計な文字列(空白や記号)が含まれていないこと。
(3)
本文中の c に入れる適切なプログラムを,表4中から選び,No.列の番号で答えよ。
模範解答
4
配点 5点
解説
データ連携に関する処理プログラムとして、表4から適切なNoを選択する問題です。権限やアクセス範囲の仕様に基づき、No.4のプログラムが該当します。
各選択肢の解説
- 4: 正解。該当するデータ連携プログラムの仕様(実行権限やアクセスするデータの内容)を満たしています。
- その他の番号: 仕様と合致しないため不適切です。
設問2
〔ユーザー登録機能のセキュリティレビュー〕について答えよ。
(1)
本文中の d に入れる適切な行番号を,図3中から選び,答えよ。
模範解答
5
配点 4点
解説
ユーザー登録機能におけるセキュリティレビューで、脆弱性が存在する箇所(図3の行番号)を指摘する問題です。5行目の処理において、セキュリティ上の不備が存在します。
各選択肢の解説
- 5: 正解。この行の処理で脆弱性(SQLインジェクションや不正アクセス等につながる例外処理の不備など)を引き起こす原因となる実装が含まれています。
- その他の行番号: セキュリティ上の問題の直接的な原因箇所ではないため不適切です。
(2)
本文中の e に入れる適切な字句を答えよ。
模範解答
例外
採点基準(配点 5点)
正確性(内容)(5点)
- 5点: 「例外」という字句が正確に記述されている。
- 2点: 関連する記述が含まれるが、指定された字句と完全には一致しない。
- 0点: 不正解、または無解答。
解説
Javaプログラムにおいて、予期せぬ事象が発生した際にスローされる仕組みを指します。プログラム言語での適切な 例外 処理はセキュアコーディングの基本となります。
高得点のポイント
- 「例外」という字句が正確に記述されていること。
(3)
本文中の下線①について,システム運用担当者とシステム開発者が,アクセスが禁止されているのにアクセスできてしまう情報は何か。図2中のユーザーマスターテーブルの列名で,それぞれ全て答えよ。
模範解答
不備により設問が成立しない。
パスワード,氏名,住所,電話番号,メールアドレス
採点基準(配点 5点)
正確性(内容)(5点)
- 5点: 対象となる全ての列名(パスワード、氏名、住所、電話番号、メールアドレス)が正確に列挙されている、または設問不成立を正しく指摘している。
- 2点: 一部の列名が欠けている、または誤った列名が含まれている。
- 0点: 不正解、または無解答。
解説
ユーザーマスターテーブルにおいて、アクセスが禁止されているにもかかわらずアクセスできてしまう可能性のある情報(列名)を全て挙げる問題です。図2中のユーザーマスターテーブルの列名を網羅する必要があります。
高得点のポイント
- 「パスワード」「氏名」「住所」「電話番号」「メールアドレス」の全てが網羅されていること。
- または、設問の不備により設問が成立しない旨を指摘していること。
(4)
また,その情報が出力される場所を,解答群の中から選び,それぞれ記号で答えよ。
模範解答
選択肢オ: 本番ログサーバのAPログを保存したテキストファイル
配点 4点
解説
出力された情報が保存される場所を問う問題です。アプリケーションのログは一元管理と改ざん防止の観点から、本番ログサーバに転送・保存されます。
各選択肢の解説
- オ: 正解。本番ログサーバのAPログを保存したテキストファイルが出力場所となります。
- ア: 開発ログサーバには本番環境のログは出力されません。
- イ:
/sbinはシステム管理コマンドのバイナリが配置される場所であり、ログの出力先ではありません。 - ウ: CSVファイルはデータ出力用であり、ログの出力先としては不適切です。
- エ: APログの保存先として、ログサーバではなく本番APサーバのローカルディレクトリを指定している点が誤りです。
(5)
図4中の f に入れる適切な字句を答えよ。
模範解答
SHA-256
SHA-384
SHA-512
採点基準(配点 5点)
正確性(内容)(5点)
- 5点: 「SHA-256」「SHA-384」「SHA-512」のいずれかの字句が正確に記述されている。
- 2点: ハッシュ関数に関する記述であるが、指定の字句と完全には一致しない。
- 0点: 不正解、または無解答。
解説
パスワードのハッシュ化において、安全性の高いハッシュアルゴリズムを指定する必要があります。MessageDigest.getInstance で指定するアルゴリズムとして、現在推奨される SHA-2 以上のアルゴリズムが適切です。
高得点のポイント
- 「SHA-256」「SHA-384」「SHA-512」のいずれかのアルゴリズム名が正確に記述されていること。
(6)
図4中の g に入れる適切な処理を,ソースコード又は具体的な処理内容のいずれかで答えよ。
模範解答
throw new RuntimeException(e)
ランタイムエラーを例外としてthrowする。
採点基準(配点 5点)
知識・理解度(内容)(3点)
- 3点: ランタイムエラー等の例外を正しくスローする処理が過不足なく記述されている。
- 1点: 例外処理の意図は読み取れるが、コードや説明に不備がある。
- 0点: 不正解、または無解答。
論理性(構造)(2点)
- 2点: ソースコードまたは処理内容として明確に理解できる論理的な記述となっている。
- 1点: 意味は通じるが、文法や構造にやや不自然な点がある。
- 0点: 論理的に意味が通じない、または無解答。
解説
Java言語において、キャッチした例外(例えば NoSuchAlgorithmException)を上位の呼び出し元に伝える、あるいはアプリケーションとしてエラー処理を行うために、非検査例外(RuntimeException)でラップして再スローする必要があります。例外発生時の動作は脆弱性につながりやすいため、適切な記述が求められます。
高得点のポイント
- キャッチした例外を上位に伝播させる処理(
throw)が含まれていること。 RuntimeExceptionなど、適切な非検査例外でラップするコードや処理内容が説明されていること。
(7)
図4中の h に入れる適切なソースコードを答えよ。
模範解答
finally
採点基準(配点 4点)
正確性(内容)(4点)
- 4点: 「finally」が正確に記述されている。
- 2点: スペルミスなど、軽微な誤りがある。
- 0点: 不正解、または無解答。
解説
リソースの解放など、例外の発生有無にかかわらず必ず実行しなければならない処理は finally ブロックに記述します。これはリソースリークを防ぐための重要な仕組みです。
高得点のポイント
- 「finally」という予約語が正確に記述されていること。
(8)
本文中の下線②について,図4の6,7行目をどのように修正すればよいか。
修正後の適切なソースコードを解答群の中から選び,記号で答えよ。ここで,変数 salt には,addUser メソッドの呼出しごとに異なる 32 バイトの固定長文字列が入っているものとし,ユーザーマスターテーブルの定義に変更はないものとする。
模範解答
選択肢ア: byte[] hashByte = mdObj.digest((salt + this.password).getBytes());
this.password = salt + String.format("%x", new BigInteger(1, hashByte));
配点 3点
解説
ソルト付きハッシュパスワードの正しい生成と保存方法を問う問題です。パスワードにソルトを付加した文字列からハッシュ値を計算し、DBに保存するパスワード文字列には「ソルト自体」と「計算したハッシュ値」を含めて格納する必要があります。これにより、認証時に同じソルトを使用して検証することが可能になります。
各選択肢の解説
- ア: 正解。
saltとthis.passwordを連結してハッシュ値を計算し、その結果にsaltを前置して格納しています。これにより、DBにはソルトとハッシュ値の両方が保持されます。 - イ: DBに格納する文字列にソルトが含まれておらず、認証時の照合ができなくなるため不適切です。
- ウ: パスワードとソルトのハッシュ値を別々に連結しているだけであり、ソルト付きハッシュ(ソルト+パスワードのハッシュ化)の本来の目的を果たせていません。
- エ: ハッシュ計算時にソルトを付加していないため、レインボーテーブル攻撃を防ぐことができません。
- オ: 最終的にDBに保存する文字列にソルト平文が含まれていないため、検証時にソルトを取得できず不適切です。
設問2(5)は,正答率が低かった。Java言語での例外処理仕様を理解していないと思われる解答が散見された。例外発生時の動作は脆弱性につながりやすい部分である。プログラム言語での適切な例外処理はセキュアコーディングの基本的内容であり,正確に理解してほしい。設問2(6)は,正答率がやや低かった。Java言語には例外発生時でも必ず実行される処理を記述する仕組みが用意されており,リソースリークを防ぐために重要な仕組みである。正確に理解してほしい。