XPathインジェクションの深淵：XMLデータストアを「見えない攻撃」から守るための防衛哲学
多くの開発者がSQLインジェクションには過敏になる一方で、XMLデータベースや設定ファイル、あるいはSOAPメッセージを処理するバックエンドに潜む「XPathインジェクション」を軽視している。これが命取りだ。
結論から言おう。XPathインジェクションは単なる「データ漏洩」の入り口ではない。XMLの構造そのものを操作し、認証をバイパスし、時にはシステム全体の権限を掌握するための、極めて攻撃者フレンドリーな脆弱性だ。今日は、教科書的な「サニタイズしましょう」という甘い言葉ではなく、アーキテクトが知るべき「内部構造の歪み」に焦点を当てて解説する。
—
1. 攻撃者が「木」を揺らす仕組み：XPath解析の盲点
XPathは、ツリー構造を辿るための言語だ。攻撃者が狙うのは、クエリ文字列を構築する際に生じる「メタ文字の混入」である。
例えば、ユーザー入力をそのままクエリに埋め込むコードを考えてみてほしい。
//user[username/text()=' + userInput + ' and password/text()=' + password + ']
ここで、攻撃者は ' or '1'='1 という古典的な文字列を注入する。これがXMLエンジンに到達した瞬間、XPath式は期待された「特定ノードの取得」から、「全てのノードの抽出」へと意味を書き換えられる。
ここで重要なのは「メモリ上のパース挙動」だ。
XMLパーサーは入力をトークン化する際、クエリ文字列を構文木（Abstract Syntax Tree）に変換する。攻撃者は、適切なクォーテーション操作によって、このASTの論理構造を意図的に崩壊させる。SQLiがテーブルの結合を悪用するのに対し、XPathインジェクションは「XML文書の親ノード・子ノード・兄弟ノードという階層構造そのもの」を自由に横断する権限を奪い取るという点が、この攻撃の恐ろしさである。
—
2. なぜ「サニタイズ」だけでは防ぎきれないのか
多くの現場では、' や " をエスケープすれば済むと考えている。だが、実務レベルのセキュリティ監査では、それは「運が良ければ防げる」程度の防衛策に過ぎない。
なぜなら、XMLの仕様そのものが複雑すぎるからだ。
XPath 1.0/2.0には多様な関数が存在する。concat() や string-length()、さらにはノードの位置を特定する position() など、エスケープをすり抜けるための「関数注入」の手段は無数にある。
本当の防御は、「入力の無害化」から「構造のパラメータ化」へのパラダイムシフトにある。
—
3. 実装のベストプラクティス：静的バインディングの強制
JavaやC#などのエンタープライズ環境では、javax.xml.xpath.XPathVariableResolver を活用したパラメータ化クエリ（Variable Binding）が唯一の解だ。文字列結合によるXPath構築をコードベースから完全に排除せよ。
以下に、Javaでの実装例を示す。
// 安全なXPathクエリの実行例
XPathFactory factory = XPathFactory.newInstance();
XPath xpath = factory.newXPath();
// 1. 変数リゾルバを定義し、入力をバインドする
SimpleVariableResolver resolver = new SimpleVariableResolver();
resolver.addVariable(new QName(“inputUser”), userInput); // 入力値は直接クエリに連結しない
xpath.setXPathVariableResolver(resolver);
// 2. クエリ内には変数名のみを記述する
String expression = “//user[username/text()=$inputUser]”;
// 3. コンパイルして評価
XPathExpression expr = xpath.compile(expression);
Object result = expr.evaluate(xmlDocument, XPathConstants.NODESET);
このアプローチにより、入力値はパーサーによって「データ」としてのみ扱われ、XPathの「命令（クエリ演算子）」として解釈される余地が完全に消滅する。
—
4. アーキテクトの視点：ガードレイルとしてのゼロトラスト
現在のAI時代において、LLMがXMLを生成し、それをバックエンドで処理するケースが増えている。ここには、「LLMが生成したXMLに対するプロンプトインジェクション」という新たな脅威が存在する。
これを防ぐためのアーキテクチャ・ガードレイルとして、以下の二重防衛を推奨する：
1. スキーマ検証による強制（XSD Validation）:
パーサーに渡す前に、必ず厳格なXSD（XML Schema Definition）によるバリデーションを通す。構造外の要素が含まれていれば、その時点で通信を遮断せよ。
2. 不変性の担保:
XPathクエリを実行するコンテキストに対し、読み取り専用の権限（Read-Only View）のみを割り当てる。万が一インジェクションが成功しても、データストアの破壊やシステム情報の列挙を封じる必要がある。
最後に：監査者へ送る言葉
セキュリティとは、完璧なコードを書くことではない。「コードが必ず壊れる（脆弱性が見つかる）前提」で、いかにダメージを局所化するかという設計思想だ。
XPathインジェクションの脆弱性は、古臭いバグのように見えて、実は今もなお多くのAPIゲートウェイや設定管理システムに牙を剥いている。明日からのコードレビューでは、「文字列結合でクエリを構築していないか？」という一点を執拗に追い詰めてほしい。
技術の深淵を覗く者は、常に攻撃者の頭の中にある「論理の隙間」を見つめている。君たちのコードが、その隙間を塞ぐ鉄壁であることを願っている。
コメント