FUNDAMENTAL INFORMATION TECHNOLOGY ENGINEER
基本情報技術者の問題解説：A社の管理画面では、担当者IDと期間を入力して売上明細を検索…
問題
A社の管理画面では、担当者IDと期間を入力して売上明細を検索する。担当者IDだけは数値チェックしているが、期間の条件は入力文字列を連結してSQLのWHERE句に埋め込んでいる。診断では、期間欄に論理式を含む文字列を入れると、他担当者の明細まで抽出できることが分かった。暫定的にWAFを導入したが、開発チームは根本対策を検討している。
根本対策として、最も適切なものはどれか。
- ア WAFの検知ルールを追加し、アプリケーション側のSQL生成方法はそのままにする。
- イ 期間欄の入力文字数を短くし、記号が多い場合だけエラーにする。
- ウ 期間条件もプレースホルダを使ったパラメタ化クエリにし、対象データの権限確認もサーバ側で行う。（正解）
- エ SQL文を複数行に分けて書き、攻撃者に推測されにくくする。
- オ 検索結果の列数を減らす。
正解と解説
正解：期間条件もプレースホルダを使ったパラメタ化クエリにし、対象データの権限確認もサーバ側で行う。
入力がSQL構文として解釈されることが原因なので、パラメタ化クエリで入力をデータとして扱う必要があります。他担当者の明細が見えるため、対象データへの権限確認も必要です。
WAFや文字数制限は補助策であり、SQL生成方法を変えなければ根本対策になりません。
Hardでの見抜き方：一部の入力だけ検査していても、別の入力がSQL文字列へ連結されていれば脆弱性は残ります。WAFや文字数制限は補助策であり、SQL構造と入力値を分離することが本質です。
選択肢ウが二段構えな理由：この事例には性質の異なる弱点が二つあります。入力がSQL構文として解釈される「インジェクション」と、他担当者の明細まで見えてしまう「認可（アクセス制御）」の不備です。パラメタ化クエリは前者を断つだけなので、正しい構文であっても本来見えてはいけない行を返す問題は残ります。だからウは権限確認も併記しており、両方を満たす点が決め手になります。
他の選択肢はなぜ違う？
- アWAFは補助策。SQL生成方法を変えなければ、すり抜ける攻撃文字列が残る。
- イ文字数制限や記号検査では、短い攻撃文字列を防ぎきれない。
- エSQL文を複数行に分けても、入力が構文として解釈される問題は残る。
- オ結果の列数を減らしても、不正抽出そのものは防げない。
この問題について
公開問題・サンプル問題のセキュリティ事例形式（A社シナリオ＋もっともらしい誤答）を参考にした独自問題です。本文・選択肢・解説は新規作成しています。
公式試験問題、公開問題、市販教材、外部問題サイトの問題文を転載・改題したものではありません。