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

解答の論理構成

1. 図4には「1. SQL文の組立てには、プレースホダ及びバインド機構を使用すること」と明示されています。プレースホルダ ? を使った SQL を実行するには、java.sql.PreparedStatement を生成し、バインド後に executeQuery() を呼び出すのが王道です。
2. 【問題文】のコード断片は
   java String sql = "SELECT * FROM atable WHERE name=?"; a stmt.setString(1, param); b
   となっており、stmt という変数がこの後に setString を呼び出していることから、stmt は PreparedStatement 型でなければなりません。
3. 解答群を照合すると、stmt を PreparedStatement として生成する文は
   「ア：java.sql.PreparedStatement stmt = con.prepareStatement(sql);」
   しかありません。よって a は「ア」です。
4. 次に SQL を発行する行 b では戻り値を ResultSet で受ける必要があります。
   executeQuery() メソッドは引数なしで呼ぶのが PreparedStatement の基本形です。
5. 解答群でこれに一致するのは
   「イ：java.sql.ResultSetrs = stmt.executeQuery();」
   です（java.sql.ResultSet 型 rs に結果を受け取る）。
6. 以上より
   • a＝「ア」
   • b＝「イ」
   となります。

誤りやすいポイント

• 選択肢「ウ」は executeQuery(sql) を呼び出しており、PreparedStatement を利用する意味がなくなります（SQL が文字列連結される危険）。
• 「エ」「オ」は JDBC に存在しないメソッド名なので誤りですが、似た名前に惑わされやすいです。
• Statement と PreparedStatement の違いを把握せずに、単に「SQL を実行できれば良い」と考えてしまうと SQL インジェクション対策が抜け落ちます。問題文では「プレースホルダ及びバインド機構」を強調している点に注意が必要です。

FAQ

解答の論理構成

1. プロジェクト計画書では、脆弱性テストが図2の工程表で「システムテスト」の後半、すなわち「本番稼働直前」に 1 回だけ計画されています。
2. F主任はこれを見て、下線①「本番稼働直前の脆弱性テストだけで安全な Web アプリケーションを開発しようとする計画には、プロジェクトマネジメント上、問題がある」と指摘しました。
3. 本番稼働直前に重大な脆弱性が見つかると、(a) 修正・再テストに要する追加工数が大きくなり (b) 予定していた「運用テスト」や「本番稼働」の開始日を後ろ倒しにせざるを得なくなります。
4. したがって、指摘の理由は「脆弱性が発見された場合に修正期間を確保できず、本番稼働が遅延するリスクが高い」ことです。
5. 模範解答「修正に期間が掛かり、本番稼働が延期となる可能性があるから」に対応します。

誤りやすいポイント

• 「セキュリティ上問題がある」＝脆弱性が残存する、とだけ考え「本番延期リスク」に触れない。
• テスト工程が存在するので十分と早合点し、工程間のバッファを見落とす。
• 下線①の主語が「安全な Web アプリケーション」なので品質面だけを論じ、スケジュール影響を外す。

FAQ

解答の論理構成

1. 要件定義段階では「要件定義には、セキュリティ要件の定義も含まれている」と問題文に記載されています。したがって、以後の工程では“定義済みセキュリティ要件を正しく実装へ落とし込めているか”を確認する必要があります。
2. ところが当初計画では「①本番稼働直前の脆弱性テスト」しか用意されておらず、設計段階での確認が抜けていました。このままでは要件‐設計間のギャップを検出できず、後戻りコストが増大します。
3. この問題を受けてP課長は「②レビューを設計工程（基本設計、詳細設計）及び製造・単体テスト工程に追加」しました。追加したレビューの目的は、要件定義で定めたセキュリティ要件が設計成果物へ正しく反映されているか、さらにコーディングへ継承されているかを確認することに他なりません。
4. 以上より、設計フェーズに追加したレビューの具体的内容は「セキュリティ要件が正しく設計に反映されているかどうか」を確認することであると導けます。

誤りやすいポイント

• 「追加レビュー＝コードレビュー」と早合点し、設計工程での確認事項を答えない。
• “脆弱性検査の前倒し”と混同し、テスト手法の説明を書いてしまう。
• セキュリティ以外の品質（性能・可用性など）のレビューを書く。

FAQ

解答の論理構成

• 本文中の下線②には「“レビューを設計工程（基本設計、詳細設計）及び製造・単体テスト工程に追加する形で計画を変更した”」とあります。製造段階のレビュー対象は“作られたソースコード”です。
• 同じ段落には「“外部委託先については、X社から開発ガイドライン準拠チェックリスト…を提供”」とあり、レビュー時に確認すべき基準を示しています。
• さらに、コーディング開始前に「“F主任は…開発ガイドラインを基に…具体的なコーディングルールも作成した”」とあるため、ソースコードがこのルールに従っているかを点検することが妥当です。
• 以上より、製造・単体テスト工程で実施すべきレビューは「開発ガイドラインおよびコーディングルールに沿って正しくコーディングされていることの確認」と導けます。

誤りやすいポイント

• 「単体テスト結果をレビューする」と誤解し、コード規約の確認を忘れる。
• 「外部委託先のみ対象」と考え、自社実装分のレビューを漏らす。
• ガイドラインとコーディングルールを分けて考えず、どちらか片方しか書かない。

FAQ

解答の論理構成

1. 図7の処理では、勤務実績表示の SQL 文に
   AND USR_ID = [選択した従業員の利用者ID]
   がそのまま埋め込まれています。
2. さらに本文には
   ――「VALUE属性として送信されてきた利用者IDに対し、データの型をチェックした後、図7中のSQL文にそのまま使用する設計」
   とあります。
3. ところが店舗間のチェックは行われておらず、Gさんは
   ――「これでは④ほかの店舗の従業員の勤務実績を権限なく閲覧される可能性があります」
   と指摘しています。
4. つまり外部から送る HTTP リクエストで、従業員選択画面のフォームパラメタ（利用者ID）を書き換え、ログイン店舗とは異なる USR_ID を与えれば、認可を受けていない勤務実績が取得できます。
5. よって回答は「【選択した従業員の利用者ID】を表すリクエストパラメタの値としてほかの店舗の利用者IDを与える」という内容になります。

誤りやすいポイント

• 「SQLインジェクション」と混同し、パラメタに悪意の SQL 断片を入れるケースと誤認する。今回の問題は認可チェック欠如による情報漏えいであり、SQLインジェクションではありません。
• 「自分の店舗以外の従業員がプルダウンに出ないから安全」と考えてしまい、クライアント側での入力制御だけに頼りがちになる。HTTP パラメタは容易に改ざんできる点を見落としがちです。
• 「顧客 ID」で顧客間は分離できているから大丈夫だと思い込み、店舗単位の追加チェックを忘れる。マルチテナント設計では顧客・店舗など複数粒度の認可が必要です。

FAQ

解答の論理構成

1. 現状の SQL では
   「SELECT … WHERE CUST_ID = [ログイン中の利用者の顧客ID] AND USR_ID = [選択した従業員の利用者ID] …」
   という条件しか付与しておらず、店舗を識別する STORE_ID が条件に含まれていません。
2. そのため、同じ顧客内であれば別店舗の従業員ＩＤを任意に送信するだけでデータが取得できます。Gさんは
   「④ほかの店舗の従業員の勤務実績を権限なく閲覧される可能性があります」
   と指摘しています。
3. 根本原因は「利用者IDがログイン利用者と同一店舗であるか」という業務的な権限制約をサーバ側で検証していないことです。
4. よってデータ型チェック後に
   「【選択した従業員の利用者ID】がログイン中の利用者と同じ店舗に属しているか」
   を確認する権限チェックを追加すれば、不正参照を防止できます。

誤りやすいポイント

• 顧客共通の CUST_ID 条件だけで十分と誤解し、店舗単位のアクセス制御を忘れる。
• クライアント側（ブラウザのプルダウン制御）だけで安全と判断し、サーバ側検証を省略する。
• USR_ID を検証しても、それが同一店舗かどうかを突き合わせないため抜け穴が残る。

FAQ

解答の論理構成

• 本文には、マルチテナント方式として「③データベースの各テーブルで、顧客を識別するカラムを追加する方式」が採用されているとあります。
• この方式では 1 つのテーブルに複数顧客のデータが混在するため、WHERE CUST_ID = … の句が外されたり改変された場合、他顧客データにアクセスできてしまいます。実際に本文でも「SQLインジェクション脆弱性の作り込みが発見された」と報告されています。
• 被害を局所化する安全策は、物理的または論理的にデータそのものを分離し、アクセス権でガードすることです。すなわち、顧客ごとに
  1. 専用テーブル（またはスキーマ）を用意し、
  2. そのテーブルにのみアクセス可能な DB アカウントを割り当てる
     という対策に改めれば、万一「SQLインジェクション」が成立しても他顧客領域を操作することは困難になります。
• したがって模範解答の「データベースのテーブルとアカウントを顧客ごとに分離し、アクセス権を設定する」が妥当です。

誤りやすいポイント

• 「顧客IDカラムがあれば十分」と思い込み、権限制御の層を増やさない。
• 「ビューで絞れば良い」と考え、基底テーブルを共有したままにする。インジェクションでビューを回避される危険を見落としがち。
• DB を分けずにアプリケーション層だけでロールを切り替える設計。攻撃者はアプリ層を突破する前提で考える必要がある。

FAQ

解答の論理構成

1. 問題の所在を確認
   • 本文には、外部委託先である“Z社”が作り込んだコードに「SQLインジェクション脆弱性」が残存していたにもかかわらず、提出されたチェックリストには“コーディングルールに適合”と記載されていたとあります（引用：「Z社は、X社のコーディングルールの内容は十分に理解していたが、コーディングルール違反をレビューで見逃したままチェック結果をX社に提出していた」）。
   • さらに「プロジェクト管理部は、SQL インジェクション脆弱性の作り込みを踏まえた⑤開発委託先管理の問題点を指摘」しています。
2. 課題を整理
   • Z社だけのセルフチェックに依存したため、脆弱性が検出されなかった。
   • チェックリスト提出時に“判定の根拠”を求めていないため、虚偽（または漏れ）を見抜けなかった。
3. 解決策の要件
   • X社自身が最終成果物をレビュー／テストする（受入検査）。
   • チェックリスト各項目の判定基準を明確化し、エビデンス提出を義務付ける。
   • これにより、委託先のレビュー漏れや形式的な合格報告を防止できる。
4. 解答例（50字以内）
   • 「委託先レビューに加えX社で受入検査を実施し、判定基準と根拠付きチェックリスト提出を義務化する。」

誤りやすいポイント

• 「レビューを強化する」とだけ書き、受入検査の主体を明示しない。
• 「テストを増やす」と漠然と述べ、チェックリストの基準や根拠提出に触れない。
• 開発ガイドラインやコーディングルールの改訂だけを解としてしまい、委託先管理の視点を欠落させる。

FAQ

解答の論理構成

1. 図8には次のように記載されています。
   「…10月1日現在、脆弱性による不正な動作を再現するcは公開されていない。」
   「再現する」ものが公開されていない、という文脈は“実際に攻撃を試すためのプログラムやコード”が存在しないことを示唆します。
2. 同じ段落の冒頭には「ネットワーク経由でこの管理画面にアクセスすることによって、ログインしなくてもDoS攻撃が可能」とあり、脆弱性の悪用可否を判断するキーワードが「DoS攻撃」です。DoS攻撃を“再現”するには一般に“攻撃コード（エクスプロイトコード）”が必要です。
3. 解答群のうち、この趣旨に合致する選択肢が「ア」であるため、cには「ア」を入れるのが妥当です。

誤りやすいポイント

• 「シグネチャ」「パッチ」などと取り違える
  「再現する」対象は攻撃動作であり、検知や修正に用いる“シグネチャ”や“パッチ”ではありません。
• 「検証手順」「テスト手順」と誤解する
  手順書はあっても実際の不正動作はコードが無ければ再現できない、という点を見落としがちです。
• “公開されていない＝安全”と短絡的に判断する
  攻撃コードが公開されていなくてもゼロデイで作られる可能性は残るため、根本対策（パッチ適用）は依然として重要です。

FAQ

解答の論理構成

1. 図8の「○脆弱性の内容」には
   “管理画面があり、TCP ポート番号8080で利用できるようになっている”
   とあり、DoS 攻撃はこのポートに到達できるかどうかで決まります。
2. 同じく図8の「○影響」で
   “インターネットから直接に攻撃を受けるわけではない”
   と記載されています。外部から到達できない理由＝既にポートを閉じている対策が存在するはずです。
3. “FW”を含むネットワーク図（図1）とFWルール表を見ると、インターネット→Webサーバは “80, 443” のみ “許可” で、その他は “拒否” です。
   よって “TCP ポート番号8080” は外部に開放されていません。
4. 以上より、実施済み対策 d は
   「ファイアウォールで、インターネットからのTCPポート番号8080への通信を拒否する」
   であると論理的に導けます。

誤りやすいポイント

• “8080” を遮断する手段を IDS と取り違える。IDS は検知であり遮断ではありません。
• 「内部セグメントでの制限」と思い込み、外部公開を前提に書いてしまう。問題文は “インターネットから直接に攻撃を受けるわけではない” 点を強調しています。
• ポート番号を書かずに「管理画面へのアクセスを制限」とだけ答えると具体性不足になります。

FAQ

解答の論理構成

1. 脆弱性が「偶然見つけた」
   【問題文】には「本番稼働の2日前に、…ニュースサイトを見ていたところ…脆弱性が1か月前に公表されていることを、偶然見つけた。」とあります。計画的な収集・管理がなかった事実を示しています。
2. ⑥の指摘内容
   「開発プロジェクトにおける本番稼働前のシステムに対する⑥脆弱性情報の管理の問題点」と明記され、管理プロセスそのものに欠陥があることが示されています。
3. 改善は組織的プロセスで行うべき
   個人の偶発的な発見では再発を防げません。X社全体で標準化し、誰が・いつ・どの情報源を監視するかを明文化する必要があります。
4. 解答の結論
   よって「X社の標準開発プロセスに脆弱性情報の収集と管理責任を規定する。」が最適解となります。標準プロセスに組み込めば、各プロジェクトは必ず実施し、責任者も明確になります。

誤りやすいポイント

• 「パッチ適用の手順を作る」だけでは情報の“収集”が抜け落ち、不十分です。
• 「運用部門に任せる」とすると開発中の製品が対象外になり、指摘の主旨を満たしません。
• 単に「定期的に確認する」では“誰が”“どの工程で”行うか不明確なため管理責任が曖昧です。

FAQ