【情報処理安全確保支援士・FE・AP】SQLインジェクション完全攻略｜攻撃原理・IPA過去問の頻出パターン・根本的対策（プレースホルダ）徹底解説
情報処理技術者試験（基本情報・応用情報・情報セキュリティマネジメント）および情報処理安全確保支援士（登録セキスペ）のセキュリティ分野において、毎年のように午前・午後問わず出題される最頻出テーマが「SQLインジェクション（SQL Injection / SQLi）」です。
「名前や対策（プレースホルダ）は知っているけれど、午後試験で『なぜ脆弱になるのか』『プレースホルダが使えない場合の代替策は何か』と記述を求められると筆が止まってしまう……」という受験生も多いのではないでしょうか。
本記事では、SQLインジェクションの攻撃成立メカニズムから、IPA試験で狙われる攻撃手法のバリエーション、「根本的対策」と「保険的対策（多層防御）」の違い、そして午後記述試験で満点を取るためのキーワードまで、試験合格に必要な知識を完全網羅して解説します。
1. SQLインジェクションとは？ 攻撃成立のメカニズム
SQLインジェクションとは、Webアプリケーション等の入力値検証やSQL文の組み立て処理の不備を突き、攻撃者が意図的に作成した悪意あるSQL文の断片を注入（Inject）することで、データベースを不正に操作（データの閲覧・改ざん・削除・認証回避など）する攻撃です。
なぜ脆弱性が生まれるのか？（構文とデータの混同）
最大の本質は、「SQL文の構造（コマンド・命令文）と、ユーザーが入力したデータ（値・文字列）が混ざり合って解釈されること」にあります。
例えば、ユーザー認証を行う以下のようなプログラムがあるとします。
-- 開発者が意図していたSQL構造
SELECT * FROM users WHERE username = '【入力値】' AND password = '【入力値】';ここで、攻撃者がユーザー名入力欄に admin' -- や ' OR '1'='1 と入力した場合、文字列連結によって以下のようなSQLが完成してしまいます。
-- 攻撃文字列が注入された結果のSQL
SELECT * FROM users WHERE username = '' OR '1'='1' AND password = 'xxx';SQLでは '1'='1' は常に真（TRUE）となるため、パスワードの照合条件が無力化され、パスワードを知らなくても管理者としてログイン（認証バイパス）されてしまいます。
2. IPA試験で頻出の攻撃手法バリエーション
午前問題や午後試験のシナリオでは、単なるログイン回避だけでなく、攻撃目的や手法に応じた多様な攻撃パターンが出題されます。
攻撃パターン | 攻撃手法の概要 | IPA試験での出題ポイント |
|---|---|---|
① 認証回避 (Tautology) | ' OR '1'='1 や ' OR ''=' などを注入し、WHERE句の条件式を常に真にする。 | 午前問題の選択肢や、簡易ログイン画面の脆弱性診断シナリオで頻出。 |
② UNION SELECT 攻撃 | 元のクエリの後ろに UNION SELECT を結合し、別テーブル（個人情報やパスワード等）の内容を一覧画面に出力させる。 | 「元のクエリと列数およびデータ型を一致させる必要がある」という制約が試験で問われる。 |
③ エラーベース (Error-based) | 意図的に型変換エラーや構文エラーを起こし、エラーメッセージ内にDB構造やテーブル名、データを露出させる。 | 「DBのエラーメッセージを画面に表示させない」という保険的対策とセットで出題。 |
④ ブラインド SQLi (Blind SQLi) | 画面にデータもエラーも出ない場合、条件が真の時だけ応答を遅延させたり (Time-based)、真偽で画面表示の一部が変わる差分 (Boolean-based) を利用して1文字ずつ特定する。 | 支援士午後試験のログ解析問題や、SLEEP関数の注入ログを読み解く設問で登場。 |
⑤ セカンドオーダー SQLi | 入力時は安全に保存されるが、後から別のバッチ処理や管理画面で取り出されて動的SQLに組み込まれた際に発火する。 | 「入力時だけでなく、DBからの再取得時・再利用時にもプレースホルダが必要」という論点。 |
3. 防御対策の鉄則：根本的対策 vs 保険的対策
IPA試験（特に支援士・応用情報の午後試験）で最も重視されるのが、「根本的対策（Vulnerability Remediation）」と「保険的対策（Defense in Depth / 多層防御）」の明確な区別です。
分類 | 対策手法 | 役割・効果 | 試験での位置づけ |
|---|---|---|---|
根本的対策 ① | 静的プレースホルダ (Prepared Statement) | SQL文の構文解析（コンパイル）を先に行い、後から値をパラメータとして渡す（構造と値の完全分離）。 | 【最優先の正解】 記述問題で「どのような対策を行うか」と問われた際の第1選択肢。 |
根本的対策 ② | 識別子のホワイトリスト検証 | テーブル名やカラム名、ソート順(ASC/DESC)など、プレースホルダが使えない箇所を固定リストと突き合わせて検証する。 | 午後試験の応用問題で「プレースホルダが適用できない箇所への対策」として出題。 |
根本的対策 ③ | エスケープ処理 (特殊文字の無害化) | シングルクォートなどの特殊文字を適切にエスケープする専用APIを使用する。 | プレースホルダが使えない場合の代替。文字コードの不一致やエスケープ漏れのリスクがあるため次善策。 |
保険的対策 ① | WAF (Web Application Firewall) | HTTPリクエストを監視し、SQLiの特徴的な文字列パターンを検知して遮断する。 | アプリ改修までの応急措置や多層防御として有効だが、バイパス手法が存在するため根本対策ではない。 |
保険的対策 ② | DBアカウントの最小権限の原則 | Webアプリが使うDBユーザーから DROP/ALTER 権限や不要なテーブルへのアクセス権を剥奪する。 | SQLi被害（テーブル削除や他システムへの侵入）を局所化する多層防御策。 |
保険的対策 ③ | 詳細エラーメッセージの非表示 | DBのエラーをそのままブラウザに返さず、汎用的なエラー画面を表示し、詳細は内部ログに記録する。 | Error-based SQLiによるDB構造の漏洩を防止する。 |
静的プレースホルダ（Prepared Statement）の仕組み
静的プレースホルダでは、データベースエンジンに対して以下の2ステップでクエリを実行します。
- ステップ1（プリペア / 構文解析）: SQL文の骨格（命令とプレースホルダ ?）だけを先にDBサーバへ送り、構文解析と実行計画の確定を完了させる。
- ステップ2（バインド・実行）: 後からユーザー入力値を単なる「リテラル値（文字列や数値などのデータ）」としてのみ引き渡す。
この仕組みにより、入力値の中に ' OR '1'='1 や ; DROP TABLE users; といったSQL構文が含まれていても、それらは「そういう名前の文字列データ」として扱われるため、SQLの命令構造が改変されることは原理的にあり得ません。
4. 午後記述式試験（SC・AP）で使える記述テンプレート
午後試験の記述問題でSQLインジェクション対策を問われた場合、文字数制限（25字〜40字程度）の中で過不足なく得点キーワードを盛り込む必要があります。
【定番記述フレーズ①（対策内容）】 「プレースホルダを利用して、SQL文の組み立てと入力値を分離する。」（33字） 「パラメータ化クエリ（Prepared Statement）を用いて実装する。」（36字）
【定番記述フレーズ②（プレースホルダが使えない場合の対策）】 「あらかじめ許可された文字列のホワイトリストと入力値を照合する。」（32字）
【定番記述フレーズ③（被害極小化の対策）】 「Webアプリケーションが使用するDBアカウントの権限を最小限にする。」（35字）
5. 試験に出る！ 関連用語と過去問チェック
本サイトの教科書用語および過去問演習機能で、理解度を今すぐチェックしましょう。
- 関連用語: 「SQLインジェクション」「SQL インジェクション対策（プレースホルダほか）」「WAF（Web Application Firewall）」「OSコマンドインジェクション」
- 関連過去問: SC 令和5年秋期 午前Ⅱ 問17（SQLインジェクション対策）、SC 令和元年秋期 午前Ⅱ 問17（対策の組合せ）、SG 令和5年 科目A 問7、SC 令和3年秋期 午前Ⅱ 問12（安全なWebアプリケーションの作り方）
下のリンクから関連する教科書用語や過去問へジャンプし、実際の出題形式に触れて知識を定着させてください。