XPathインジェクション：レガシーの皮を被った「XMLの心臓」を射抜く死角
多くのエンジニアが「SQLインジェクションは過去の遺物」と高を括る一方で、エンタープライズの深部やレガシーなB2B連携システムでは、今もなおXML処理が静かに息を潜めている。特にXPathインジェクションは、単なる「データ漏洩」の域を超え、XMLドキュメントの構造そのものを操作することで、認証バイパスや特権昇格、果てはバックエンドの解析エンジンに対するDoS攻撃のトリガーとなり得る。
今日は、教科書的な「入力をエスケープせよ」という陳腐な忠告ではなく、XMLパーサの低レイヤの挙動と、現代のアーキテクチャに求められるガードレイルの設計思想について深掘りする。
—
1. XPathインジェクションの解剖：なぜ「構造」が狙われるのか
SQLインジェクションが「データベースのテーブル」を狙うのに対し、XPathインジェクションは「XMLのツリー構造」を狙う。攻撃者は、アプリケーションがユーザー入力をXPath式の一部として結合する際の「構文解析の曖昧さ」を突く。
例えば、ログイン認証などで以下のようなクエリが生成されるとしよう。
ここで攻撃者が ' or '1'='1 を注入すると、XPathエンジンは or 演算子を評価し、論理値として true を返す。さらに巧妙なのは、count() 関数や substring() 関数を用いた「ブラインド型」の攻撃だ。レスポンスの有無やわずかな応答時間の差から、XML内の機密ノード（例えば管理者トークンや設定ファイル内の秘密鍵）を1文字ずつ抽出する。これは、メモリ上のDOMツリーを再帰的に走査させることで、リソースを枯渇させる攻撃にも発展する。
—
2. 根本的な欠陥：パーサとアプリケーションの「解釈の乖離」
この脆弱性の根本原因は、「データ」と「命令（XPathクエリ）」の分離が、アプリケーション層で疎かにされている点にある。
多くの言語の標準ライブラリ（例えばJavaのjavax.xml.xpath）は、残念ながらSQLのPreparedStatementのような直感的なパラメータ化を標準で提供していないケースが多い。開発者は「XMLを扱っているから安全だ」という思い込みから、入力を文字列結合で埋め込む。
これを防ぐためのアーキテクチャ上の正解は、「XPath変数のバインディング」を強制することだ。
実装例：JavaにおけるXPath変数バインディング
文字列結合を避け、XPathVariableResolver を用いて、入力をクエリから完全に分離する。
// 危険なコード例：文字列連結（絶対に行わないこと）
// String expression = “//user[username='” + userInput + “‘]”;
// 安全なコード例：変数のバインディング
XPath xpath = XPathFactory.newInstance().newXPath();
// 変数リゾルバを定義
xpath.setXPathVariableResolver(variableName -> {
if (variableName.getLocalPart().equals(“userInput”)) {
return sanitizedInput; // 安全に検証された値のみを渡す
}
return null;
});
// 式自体には直接値を埋め込まない
XPathExpression expr = xpath.compile(“//user[username=$userInput]”);
// 評価時に変数として渡すことで、構文解析を分離する
Object result = expr.evaluate(xmlDocument, XPathConstants.NODESET);
—
3. 生成AI時代のガードレイル：入力層でのXMLバリデーション
昨今、LLMを利用したXML生成や、構造化データ変換パイプラインにおいて、この種のリスクが再燃している。LLMが生成したXPathクエリをそのままバックエンドで実行させるのは、自ら脆弱性の扉を開ける行為に等しい。
ここで我々が導入すべきは、「スキーマ強制」と「静的解析によるクエリ検証」の多層防御だ。
1. Strict XML Schema (XSD) Validation:
入力されたXML自体が、期待された構造から逸脱していないかをパース前に厳格にチェックする。
2. XPath Query Parser/Validator:
動的に生成されたXPath式を、実行前に「構文解析」し、禁止された関数（document()やcount()など）が含まれていないか、また、想定外のノードへアクセスしようとしていないかを検証するミドルウェアを挟む。
—
4. チーフホワイトハッカーとしての提言：レガシーからの脱却
XMLは、JSONやProtobufに比べれば「構造の柔軟性」という武器がある反面、その柔軟性が攻撃者に「操作の余地」を与えている。
もし、貴方の組織が機密性の高いシステムでXMLとXPathを使い続けているのであれば、以下のチェックリストを即座に実行せよ。
- ライブラリの更新: XMLパーサ（Xercesなど）は、XXE（XML外部実体攻撃）やXPathインジェクションの脆弱性が度々発見される。常に最新のパッチを適用し、
disallow-doctype-declを有効にすること。 - 権限の最小化: アプリケーションが読み込むXMLファイルへのアクセス権限は、OSレベルで必要最小限に絞り込まれているか？
- 耐量子暗号への布石: 今後、XML署名（XML-DSIG）を利用している場合は注意が必要だ。将来的な耐量子暗号（PQC）への移行を見据え、暗号方式を切り替え可能な抽象化層を今のうちに設計しておくことが、アーキテクトとしての責任である。
セキュリティは「防壁を作る」ことではなく、「攻撃者が動くたびにノイズを出し、検知可能な状態を作り続ける」ことだ。XMLの深い森の中で、貴方のコードが静かな監視の目となり、異常なクエリを弾き飛ばすことを期待している。
コメント