SQLインジェクションという「古典」を解剖する――プリペアドステートメントの真の深淵
巷には「SQLインジェクション対策にはプリペアドステートメントを使え」という決まり文句が溢れている。だが、なぜそれが絶対的な「盾」となり得るのか、メモリ上の挙動やDBプロトコルのコンテキストまで掘り下げて語れるエンジニアは驚くほど少ない。
我々のような防御側が理解すべきは、単なるAPIの使い方ではない。「命令（Instruction）」と「データ（Data）」が、どのレイヤーで境界線を引かれるのかという本質だ。
1. 脆弱性の根源：なぜクエリの結合は「死」を招くのか
脆弱なコードの典型例として、文字列連結によるクエリ生成がある。
— 悪意ある入力: ‘ OR 1=1 —
SELECT FROM users WHERE username = ” OR 1=1 –‘ AND password = ‘…’;
この攻撃が成功するのは、DBエンジンが受け取った文字列を「解析（パース）」する際に、プログラム側が意図した「データとしてのリテラル」と、SQL構文としての「演算子」を区別できなくなるからだ。
低レイヤの視点で見れば、これはSQLパーサーに対する制御フローのハイジャックに他ならない。DBエンジンは、渡された文字列ストリームを構文木（AST）に変換する際、連結された文字列を「一つの正当な命令」として解釈してしまう。これは、バッファオーバーフローで命令ポインタを書き換える攻撃と、概念的には同じ構造を持っている。
2. プリペアドステートメント：境界分離のメカニズム
プリペアドステートメント（パラメトリッククエリ）の真価は、「コンパイル」と「実行」の分離にある。
1. Preparation（準備フェーズ）: クエリのテンプレートをDBに送信する。DB側はここでSQLの構文木を作成し、実行計画を固定する。
2. Binding（バインドフェーズ）: ユーザー入力値のみを後から送信する。
ここで重要なのは、バインドされたデータは、どれだけ悪意のあるSQL構文を含んでいても、決して再パースされないという点だ。DBエンジンは、事前に固定された構文木の「プレースホルダ」の場所に、単なるバイト列としてデータを流し込むだけである。
セキュアな実装例（Java/JDBCの例）
// 構文のテンプレートを事前に定義
String sql = “SELECT FROM users WHERE username = ? AND password = ?”;
PreparedStatement pstmt = connection.prepareStatement(sql);
// ユーザー入力（どれだけ悪意があっても、ただの文字列として扱われる）
pstmt.setString(1, inputUsername);
pstmt.setString(2, inputPassword);
// 実行（パース済みの構文木にデータが流し込まれるだけ）
ResultSet rs = pstmt.executeQuery();
3. チーフホワイトハッカーの視点：アーキテクチャへの攻撃的思考
もし、あなたがシステムアーキテクトなら、プリペアドステートメントを単なる「ライブラリの機能」として扱ってはならない。以下の3つの観点から監査を行うべきだ。
A. プロトコルレベルの分離
多くのDBドライバーにおいて、プリペアドステートメントはDB側の「バイナリプロトコル」を利用する。これは、プレーンなテキストクエリを投げるのとは異なり、型情報や構造を厳密に定義して通信する。このプロトコル上の分離こそが、インジェクションに対する物理的なガードレイルとなる。
B. 権限分離の再考
プリペアドステートメントがあっても、データベースユーザーの権限が強すぎれば、データの流出は防げない。
- 最小特権の原則: アプリケーション用ユーザーには、DDL（DROP TABLEなど）や複雑なJOINを制限する。
- クエリの可視化: DB側のクエリログを監視し、想定外のASTが生成されていないか、あるいは「大量の準備済みクエリ」が発行されていないかを異常検知のトリガーとする。
C. AIプロンプトインジェクションへの適用
現代の課題は、LLMに対するプロンプトインジェクションだ。これに対する防御も、SQLのプリペアドステートメントの考え方がそのまま応用できる。
「ユーザーの入力」と「システム命令」を分離する仕組み（例：LangChainのテンプレート構造など）は、まさに現代版のプリペアドステートメントと言える。LLMの文脈で言えば、「コンテキスト（システムプロンプト）」と「ユーザー入力（変数値）」の境界線を、いかにトークンレベルで隔離するかが勝負だ。
結論：技術は「境界線」を引くためにある
サイバーセキュリティの歴史は、境界線が曖昧になった場所で何が起きるか、という教訓の積み重ねだ。
- SQLインジェクションは、命令とデータの境界が曖昧になった。
- メモリ破壊は、コードとデータの境界が曖昧になった。
- プロンプトインジェクションは、指示と入力の境界が曖昧になっている。
プリペアドステートメントを使いこなすことは、単なるコーディング規約ではない。「データに命令させない」という、エンジニアとしての揺るぎない規律をコードに刻み込む行為なのだ。
次回のコードレビューでは、prepareStatementの有無を確認するだけでなく、「このクエリは実行計画が再利用されているか？」「入力値がプロトコル上でどう処理されているか？」という深いレベルまで問いかけてみてほしい。それが、プロの防御者の仕事だ。
コメント