境界線の崩壊：SQLインジェクションが炙り出す「構文解析」という名の深淵
多くのエンジニアにとって、SQLインジェクション（SQLi）は「今さら語るまでもない古典」だろう。しかし、現場の最前線にいる我々から見れば、依然として最も残酷で、かつ最もエレガントにシステムの「深部」をハックできる手法であり続けている。
なぜ、20年経ってもこの脆弱性が消えないのか。それは、我々が「データ」と「命令」を分かつ境界線を、あまりにも安易にデータベースエンジンの構文解析器（Parser）の慈悲に委ねているからだ。
1. メタ文字の解釈が引き起こす「意味論的転換」
SQLiの根本原因を単なる「文字列の連結」で片付けてはならない。これは、「アプリケーション層が意図した抽象的なデータ型」と「DBエンジンが解釈する物理的な構造」の間で生じる、意味論的な不一致（Semantic Mismatch）に他ならない。
例えば、SELECT FROM users WHERE id = ' + input + ' というクエリがあるとする。開発者はinputを「ただのIDという文字列」と定義しているが、DBエンジンはそれを「単一引用符（’）によって閉じられた境界の終了」として解釈する。
ここで重要なのは、攻撃者は「データの範囲内」で動いているのではなく、「構文解析器の再帰的ルール」を悪用しているという点だ。
— 攻撃者が入力する ‘ OR 1=1 — の挙動
— 構文解析器は以下のようにトークナイズし直す
SELECT FROM users WHERE id = ” OR 1=1 — ‘
— ‘–‘ 以降はコメントアウトとして処理され、WHERE句は常に真となる
このとき、DBエンジン内部では、AST（抽象構文木）が再構築されている。開発者が意図した木構造と、攻撃者が強制した木構造。この「ズレ」を検知できないアーキテクチャこそが、脆弱性の温床だ。
2. DBエンジン間の「構文解析の揺らぎ」が招く罠
セキュリティの監査において、最も危険なのは「データベースをブラックボックスとして扱うこと」だ。例えば、MySQLとPostgreSQLでは、バッククォート（`）や二重引用符（”）の識別子としての扱いが異なる。
ある環境で防御策として有効だった「エスケープ処理」が、別のストレージエンジンやドライバーレイヤーを通ることで無効化される現象を、我々は「パース・インコンシステンシー（解析の不整合）」と呼ぶ。
特に注意すべきは、マルチバイト文字のエンコーディング変換だ。Shift-JIS等のマルチバイト文字を許容する環境で、特定のバイト列がエスケープ文字（\）を飲み込み、本来ならエスケープされるはずのシングルクォートを「自由の身」にしてしまう。これはネットワークプロトコルレベルでのパケット分割や、DBドライバの正規化処理の隙を突く攻撃だ。
3. 次世代の防衛：構造的セキュリティの設計
では、どうやってこの「意味論的な崩壊」を防ぐべきか。単なるバリデーションやWAFによるシグネチャマッチングは、もはや「対症療法」に過ぎない。
A. プリペアードステートメントの真の価値
プリペアードステートメントは「入力をサニタイズする」ものではない。「クエリの構造をあらかじめDBエンジンに固定し、後からデータを流し込む」という、通信路の分離そのものである。
クライアント/サーバ間でクエリのプラン作成と実行を分けるプロトコル（バイナリプロトコル）を利用することで、メタ文字の解釈という概念自体を排除できる。
安全な実装例：パラメータ化クエリ（心理的安全性ではなく、プロトコルレベルの分離）
文字列の結合を一切行わない
query = “SELECT FROM users WHERE id = %s”
cursor.execute(query, (user_input,))
DBエンジン側でトークンとして識別され、決してSQLの命令として解釈されない
B. コンテキストを意識したガードレイル（LLM時代の教訓）
最近の生成AIに対するプロンプトインジェクションと、SQLiは構造が酷似している。どちらも「システムプロンプト（命令）」と「ユーザ入力（データ）」の境界線が曖昧になることで発生する。
防御アーキテクチャとして推奨するのは、「クエリの抽象化レイヤー（ORM等）」の監査だ。ORMが発行するSQLを静的解析し、構文木が開発者の意図から逸脱していないかをCI/CDパイプラインで自動検知する仕組みを構築せよ。
4. 最後に：プロフェッショナルとしての監査眼
耐量子暗号やゼロトラストアーキテクチャが叫ばれる現代において、SQLiのような古典的な攻撃を侮る者は、間違いなく足元をすくわれる。
攻撃者は、常に「システムの最も弱いリンク（仕様の隙間）」を探している。あなたが書くコードが、DBエンジンという巨大な構文解析エンジンの「どのレイヤー」で処理されているのか。パケットのバイト列がどう解釈されているのか。その「解像度」を高めることこそが、真のセキュリティアーキテクトへの道だ。
コードを書くとき、常に問いかけよ。
「この入力値は、解析器にとって『データ』か？ それとも『命令の一部』か？」
その答えを自分の中で明確に定義できた時、初めてあなたのアプリケーションは堅牢な砦となる。
コメント