SQLインジェクションという「古くて新しい」死角：プリペアドステートメントの先にある真実
「SQLインジェクションなんて、今どきフレームワークが自動でやってくれるだろう？」
もし貴方が現場のテックリードとしてそう考えているなら、それは危険な慢心だ。確かにORMやライブラリは進化したが、攻撃者たちはもはや「単純な `OR 1=1`」など投げない。彼らはアプリケーションの境界条件、暗黙的な型変換、そしてデータベースのパーサが「コマンド」と「データ」をどう解釈するかという、バイナリレベルの曖昧さを突いてくる。
今日は、教科書的な説明は省く。アーキテクトの視点から、SQLインジェクションの根本的な構造と、それを叩き潰すための防衛アーキテクチャについて、泥臭い知見を共有する。
1. なぜパーサは「データ」を「コマンド」と誤認するのか
SQLインジェクションの根本原因は、「制御情報（Control Plane）」と「ユーザー入力（Data Plane）」の分離が、パーサのレベルで論理的に行われていないことにある。
古典的な文字列連結 `SELECT FROM users WHERE id = ‘` + input + `’` がなぜ脆弱か。これは、データベースのパーサが「入力された文字列」を、構文解析のプロセスにおいて「命令の一部」として再評価してしまうからだ。
ここで重要なのは、DBエンジンが受け取るパケットそのものの構造だ。通信プロトコル（TDSやMySQLプロトコルなど）において、文字列としてシリアライズされたクエリは、サーバ側でレキシカル解析（字句解析）にかけられる。この時、シングルクォートなどのメタ文字が「データの終わり」ではなく「構文の区切り」として処理されることで、攻撃者のインジェクションが成立する。
2. プリペアドステートメントは「魔法」ではない
プリペアドステートメント（パラメータ化クエリ）の真価は、単なるエスケープ処理ではない。「SQLのテンプレート（実行計画）」と「バインドされた値」を、プロトコルレベルで別々のコンテナとしてDBエンジンに渡すことにある。
多くの開発者は、これを「文字列結合を防ぐもの」と理解している。しかし、セキュリティアーキテクトはこう考えるべきだ：「これはクエリのコンパイルと実行を分離する、強力なインフラ的ガードレイルである」と。
// 良くない実装：プリペアドステートメントの利点を殺している例
String query = “SELECT FROM users WHERE username = ‘” + userInput + “‘”;
statement.execute(query); // ここでパースが走り、インジェクションの余地が生まれる
// 正しい実装：クエリプランを先にDBに固定させる
String sql = “SELECT FROM users WHERE username = ?”;
PreparedStatement pstmt = connection.prepareStatement(sql);
// バインド変数は、DBエンジン側で決してコマンドとして解釈されない
// データベースは「?」というプレースホルダーに対して、純粋なデータ型として値を割り当てる
pstmt.setString(1, userInput);
ResultSet results = pstmt.executeQuery();
ここで重要なのは、`setString` メソッドが内部で行っている処理だ。これは単なる文字列置換ではない。DBとの通信プロトコルにおいて、入力値を「データバインドパケット」として別途送出し、実行計画を汚染させない仕組みになっている。
3. 次世代の脅威：プロンプトとSQLの境界線
いま、我々は生成AIという新たな「入力源」と格闘している。ユーザーがプロンプトを通じてデータベースを検索する仕組みを構築する場合、「プロンプトインジェクション」と「SQLインジェクション」が混ざり合うという悪夢のような事態が発生する。
例えば、RAG（検索拡張生成）のパイプラインにおいて、LLMが生成したSQLをそのままDBに投げるような設計は自殺行為だ。
防御のアーキテクチャ設計：ガードレイルの配置
1. 静的解析の強制: LLMが生成するSQLは、実行前にAST（抽象構文木）を解析し、許可されたテーブルやカラム以外へのアクセスを遮断するパーサを通す。
2. 特権分離: アプリケーションがDBに接続するユーザには、最低限の権限（`SELECT`のみ、特定のビューのみ）を付与し、`DROP`や`GRANT`、`UNION SELECT`による別テーブルへのアクセスを物理的に不可能にする。
3. バイナリプロトコルの監視: WAFでの正規表現マッチングに頼らず、DBの通信レイヤで異常なクエリパターン（通常のアプリアクセスとは異なる統計的なクエリ構造の変化）を検知するサイドカーを配置する。
4. チーフホワイトハッカーとしての提言
脆弱性管理の本質は、「コードを書くこと」ではなく「システム全体の挙動を制御下に置くこと」だ。
- 型安全性の徹底: SQLのパラメータには、必ず型を明示せよ。暗黙的な型変換（例: 数値型カラムに文字列を突っ込む際のDB側の挙動）が、意図しないバイパスを生むことがある。
- 監査ログの解像度: プリペアドステートメントを正しく使っていれば、DBの監査ログには「パラメータ化されたクエリのテンプレート」が記録されるはずだ。もしログに「生のクエリ（展開後の値が入ったもの）」が頻出しているなら、それは実装のどこかで連結が発生している証拠であり、アラートを上げるべきだ。
セキュリティは「どこで止めるか」の芸術だ。アプリケーションコード、データベースドライバ、そしてDBエンジン内部のパーサ。どのレイヤで「コマンド」と「データ」を分離すべきかを常に意識してほしい。
SQLインジェクションは既に解決された問題だと言われる。だが、我々が設計するシステムが複雑化するほど、その境界線はあやふやになる。常に「パケットの中身」を想像し、パーサの挙動を疑え。それが、我々エンジニアが守り抜くべき最後の防衛線だ。
コメント