基本情報技術者 2024年 科目A 問10
問題文
SQLインジェクションの対策として、有効なものはどれか。
選択肢
ア：URLをWebページに出力するときは、“http://”や“https://”で始まるURLだけを許可する。
イ：外部からのパラメータでWebサーバ内のファイル名を直接指定しない。
ウ：スタイルシートを任意のWebサイトから取り込めるようにしない。
エ：プレースホルダを使って命令文を組み立てる。（正解）
🔒 解説は解答すると表示されます
SQLインジェクション対策【午前解説】
正解の理由
SQL 文に外部入力を直接つなげて実行すると、不正な SQL を注入されデータ漏洩や改ざんを招きます。プレースホルダ（パラメータ化クエリ）を使うことで、SQL 文の構造とパラメータを分離し、入力値があくまでデータとして扱われるため、意図しない SQL が実行されることを防げます。したがって正解はプレースホルダを使う選択肢、すなわち エ です。
解法ステップ
- 「攻撃対象が SQL であるか」を確認する（外部入力が SQL 文に組み込まれているか）。
- SQL を安全に扱う方法が選択肢にあるかを探す（パラメータ化、プレースホルダ、PreparedStatement 等）。
- SQL 以外のセキュリティ対策（URL 検証、ファイル名制御、外部 CSS 制限）は別の攻撃（XSS、パス・トラバーサル等）に有効であり、SQL インジェクションの直接対策にはならないと判断する。
- よって SQL インジェクション対策として最も有効な エ を選ぶ。
選択肢別の誤答解説
- ア: URL を Web ページに出力するときにスキームを限定するのは、オープンリダイレクトや悪意あるリンクの対策にはなるが、SQL 文への挿入を防ぐ直接的手段ではありません。SQL インジェクション対策としては不十分です。
- イ: 外部パラメータでサーバ内のファイル名を直接指定させないことは、パス・トラバーサルやローカルファイル読み出しの防止になりますが、SQL 文の組み立て／実行に関する問題（SQLi）を解決する一般解ではありません。
- ウ: スタイルシートの外部読み込み制限は、主にクロスサイトスクリプティング（XSS）やコンテンツポリシー（CSP）の制御に関係します。SQL インジェクションの防止策とは別分野です。
- エ: プレースホルダ（パラメータ化クエリ）を使うことで、入力は常にデータとして扱われ SQL 構造に影響を与えられなくなります。これが SQL インジェクション対策の代表的かつ効果的な方法です。
よくある誤解
- プレースホルダ不要で「入力をエスケープすれば安全」と考える誤り：エスケープは実装や文字コードによって失敗することがあり、パラメータ化に比べ堅牢性が劣ります。
- SQL インジェクション対策＝入力検証だけでよいと考える誤り：入力検証は重要ですが、予期しないエンコーディングやバイパスがあり得るため、パラメータ化と併用すべきです。
- ORMs やフレームワークを使えば常に安全になると思う誤り：多くの ORM はパラメータ化を行いますが、生 SQL を組み立てるケースやフレームワークの使い方次第で脆弱になることがあります。
補足コラム
プレースホルダの実例（脆弱な例と安全な例）
脆弱な例（文字列連結で SQL を組み立てる）
# 危険: user_input が "'; DROP TABLE users; --" のような値だと危険
sql = "SELECT * FROM users WHERE name = '" + user_input + "';"
cursor.execute(sql)
安全な例（パラメータ化）
# 安全: プレースホルダで値をバインド（sqlite3 の場合は ? を使用）
sql = "SELECT * FROM users WHERE name = ?"
cursor.execute(sql, (user_input,))
補助的対策
- 最小権限の原則：DB 接続は必要な権限だけ与える（SELECT のみ等）。
- 入力検証とホワイトリスト：受け付ける値の形式を明確にし、可能なら許可リストで制限する。
- ログと監査：異常なクエリやエラーを検出してアラートを上げる。
- WAF（Web アプリケーションファイアウォール）：追加の防御層として有効だが万能ではない。
実運用ではプレースホルダ（パラメータ化）を第一選択とし、上記の補助対策を重ねるのが実務的です。
FAQ
Q: プレースホルダで LIKE 検索はどうする？
A: ワイルドカードはパラメータ内で扱えます（例："%keyword%" を作ってバインド）。プレースホルダ自体でワイルドカードを付与する実装上の差に注意してください。
A: ワイルドカードはパラメータ内で扱えます（例："%keyword%" を作ってバインド）。プレースホルダ自体でワイルドカードを付与する実装上の差に注意してください。
Q: ストアドプロシージャを使えば安全？
A: ストアドプロシージャは有効ですが、内部で文字列連結して SQL を実行していれば脆弱になります。やはりパラメータ化が重要です。
A: ストアドプロシージャは有効ですが、内部で文字列連結して SQL を実行していれば脆弱になります。やはりパラメータ化が重要です。
Q: ORM を使えば SQL インジェクションは心配ない？
A: 多くの ORM は安全なクエリ生成を提供しますが、生の SQL を使う場合や不適切なテンプレートルールを適用すると脆弱になります。ORM の仕様を理解して使うことが必要です。
A: 多くの ORM は安全なクエリ生成を提供しますが、生の SQL を使う場合や不適切なテンプレートルールを適用すると脆弱になります。ORM の仕様を理解して使うことが必要です。
関連キーワード: SQLインジェクション、プレースホルダ、パラメータ化クエリ、PreparedStatement、エスケープ、入力検証、最小権限、バインディング
\ せっかくなら /
基本情報技術者を
クイズ形式で学習しませんか？
クイズ画面へ遷移する→
すぐに利用可能！