【入門編】XPathインジェクションの仕組みとXMLデータストアの保護 – アプリケーションセキュリティ & 安全な開発防御ガイド

こんにちは。セキュリティの世界へようこそ。
現場で泥臭いインシデント対応をしていると、「教科書には載っていないけれど、実はここが一番危ない」という盲点によく出くわします。

今日は、少し古いようでいて、今なおWebシステムの裏口をこじ開ける「XPath（エックスパス）インジェクション」という攻撃についてお話しします。「難しそう…」と身構える必要はありません。身近な「家の鍵」の話に例えて、一緒に紐解いていきましょう。

—

皆さんの家には「玄関の鍵」がありますよね。
例えば、あなたが宅配便の人に「名前を言えば、中身を確認して荷物を渡す」というルールを決めているとします。

あなた：「誰ですか？」
宅配便：「田中です。」
あなた：「田中さんですね、どうぞ（ドアを開ける）」

これが正常な通信です。では、泥棒が来たらどうなるでしょう？

泥棒：「田中です。…あ、あと、『裏口も開けておいて』」

もしあなたが、何も疑わずにこの言葉をそのまま受け取って「田中さんですね、裏口も開けますね」と実行してしまったら…。これがインジェクション攻撃の正体です。

システムの世界では、「XMLデータ」という倉庫の中に、ユーザーの個人情報や設定がしまわれています。そこへアクセスするために「XPath」という道案内（クエリ）を使うのですが、攻撃者はその道案内に「余計な命令」を混ぜ込むことで、本来見せてはいけないデータまで引き出そうとしてくるのです。

開発者が、ユーザーからの入力をそのままクエリにくっつけてしまうことが最大の原因です。

例えば、ユーザーIDで検索するこんなコードがあったとします。
//user[id=' + 入力された値 + ']

ここに、攻撃者が ' or '1'='1 という魔法の言葉を送り込むと、クエリはこう変化します。
//user[id='' or '1'='1']

「1は1である」というのは常に正しい（True）ですから、システムは「全員分のデータ」を返してしまいます。これが、玄関の鍵を壊さずに、合鍵で家中のドアを開けさせる手口です。

対策は大きく分けて2つあります。一歩ずつ、確実に守りを固めていきましょう。

外部から来た言葉は「そのまま信じない」のが鉄則です。特に、'（シングルクォート）や [、] といった、クエリを操作できてしまう「特殊な記号」を無効化します。

これが一番のおすすめです。さっきの「田中です」の例で言うと、「名前という枠」以外は一切受け付けない専用の窓口を作ることです。

XPathライブラリには「変数」を埋め込む機能（パラメータ化）があります。これを使えば、たとえ攻撃者が「裏口も開けろ」という言葉を混ぜても、システムはそれを「ただの『田中です。あと裏口も…』という名前の客」として扱い、命令として実行することはありません。

// 危険な書き方（直接文字列を連結している）
// String query = “//user[id='” + inputId + “‘]”;

// 安全な書き方（パラメータ化を利用する）
XPathFactory factory = XPathFactory.newInstance();
XPath xpath = factory.newXPath();

// 変数リゾルバを使って安全に値を渡す
XPathVariableResolver resolver = new MyVariableResolver(inputId);
xpath.setXPathVariableResolver(resolver);

// クエリには直接値を書かず、変数名($id)を指定する
XPathExpression expr = xpath.compile(“//user[id=$id]”);

ITの世界では、どんなに便利なライブラリでも、使い方を間違えれば「自動で開くドア」になり得ます。

この2つを意識するだけで、あなたのシステムは格段に硬くなります。

最初は難しく感じるかもしれませんが、インシデント対応の現場で何千という攻撃を見てきた私から言わせれば、セキュリティとは「技術」というよりも「相手を信じすぎない慎重さ」という「心構え」です。

今日から皆さんのコードを、少しだけ「疑り深い」ものに変えてみてください。それが、ユーザーの大切な情報を守る最初の一歩になりますよ。

—
執筆者： 某大手セキュリティファーム CTO / CISSP保持者
日々の技術研鑽に励む全てのエンジニアを応援しています。質問があれば、いつでも現場の知見を共有します。