基本的なXPathインジェクション

まず前回で作成したauth.phpを利用したXPathインジェクションを行います。auth.phpはaccount.xmlに保存されたユーザ情報を参照し、コマンドラインから渡されたユーザ名とパスワードが一致するかチェックするプログラムです。

[yohgaki@dev tmp]$ php auth.php user1 password1
OK to login
[yohgaki@dev tmp]$ php auth.php user1 password2
Not OK to login

auth.phpは次のXPathクエリを実行し、ユーザ名とパスワードが一致したノードだけを抽出します。

$nodelist = $xpath->query('/account/user[name="'.$argv[1].'" and password="'.$argv[2].'"]');

このXPathクエリには必要なエスケープ処理を怠る致命的な欠陥があるので、XPathインジェクションが可能になります。この場合、ユーザ名部分に

" or 1=1 or ""="

をパラメータとして与えると、パスワードパラメータに関わらず認証してしまいます。

[yohgaki@dev tmp]$ php auth.php '" or 1=1 or ""="' password2
OK to login

これは不正なパラメータによりXPathクエリの意味が変わってしまったために発生する問題です。

/account/user[name="" or 1=1 or ""="" and password="password2"]

プログラマが意図しない形で文字列を終了させクエリの意味を変えてしまう、文字列SQLインジェクションと似たような攻撃がXPathでも可能です。

ブラインドXPathインジェクション

ブラインドSQLインジェクションとは、データベースサーバの種類、テーブル名やフィールド名などの内部構造を外部から解析し、SQLインジェクション攻撃を行う攻撃手法です。この手法が利用可能な場合、データベース構成をまったく知らない外部のユーザに任意のデータの取得や改竄を許してしまいます。XPathインジェクションでも、細かい手法は異なっても、同類の攻撃が可能であることが知られています。

先ほどのXPathインジェクションの例では、ユーザがログインできたかできなかったしか分かりません。しかし、結果の論理値化（true/false化）によりたったこれだけの脆弱性でもXPathを利用してXMLドキュメントの内容を解析できます。

詳しいブランドXPathインジェクションの解説は長くなるので省略します。英文ですが非常にわかりやすい文書が公開されているので、興味がある方は以下のページを参照してください。

Watchfire : Blind XPath Injection

https://secureitalliance.org/blogs/watchfire/archive/2006/02/10/660.aspx

XPathインジェクション対策

XPathインジェクション対策もSQLインジェクション対策と同じです。XPathのリテラルはSQLと同様に文字リテラルと数値リテラルに大別できます。

[42]    Literal           ::=    NumericLiteral | StringLiteral
[43]    NumericLiteral    ::=    IntegerLiteral | DecimalLiteral | DoubleLiteral
[71]    IntegerLiteral    ::=    Digits
[72]    DecimalLiteral    ::=    ("." Digits) | (Digits "." [0-9]*)
[73]    DoubleLiteral     ::=    (("." Digits) | (Digits ("." [0-9]*)?)) [eE] [+-]? Digits
[74]    StringLiteral     ::=    ('"' (EscapeQuot | [^"])* '"') | ("'" (EscapeApos | [^'])* "'")
[75]    EscapeQuot        ::=    '""'
[76]    EscapeApos        ::=    "''"
[81]    Digits            ::=    [0-9]+

この定義から、文字リテラルは

"文字列"

または

'文字列'

と定義され、それぞれ "（ダブルクオート）は ""、'（シングルクオート）は '' とエスケープしなければならないことが分かります。

つまり、PHPの場合はmb_ereg_replace関数を用いたエスケープ処理が必要です。文字エンコーディングを考慮しないstr_repalce関数を使用すると、文字エンコーディングを利用したインジェクション攻撃を許してしまう可能性もあるので必ずマルチバイト文字対応の文字列置換関数を適切な文字エンコーディングで利用するようにしなければなりません。

mb_regex_encoding('UTF-8');
$escaped = mb_ereg_replace('\'', '\'\'', $input);

XPath実装によりますが、文字リテラルと数値リテラルは、SQLクエリパーサの実装と同様に、厳密に区別されていないケースが多いです。

PHPのXPath（正確にはlibxml2のXPath）も四則演算をサポートしており

"10.0" = 5*2

は等価と評価されます。

XML文書自体がテキスト形式なので当然です。数値リテラルの場合、数値リテラルの定義を利用したバリデーションの利用も可能ですが、すべてのパラメータは、文字リテラルとして扱える処理系の場合は文字リテラルとして扱ったほうが漏れが発生する可能性が減るのでより安全です。

前々回で紹介したPostgreSQL 8.3の場合、文字リテラルを '（シングルクオート）でエスケープする場合、pg_escape_string関数を利用することも可能です。

$escaped = pg_escape_string($connection, $input);

ただし、XML宣言でデータベース文字エンコーディングと異なる文字エンコーディングを指定可能なので、エンコーディングが異なる場合は注意が必要です。通常、DBとXML文書の文字エンコーディングには同じ文字エンコーディングを利用するべきです。

MySQL 5.1にもXML機能が追加されています。MySQLの場合、エスケープ方式がSQL標準準拠ではないのでPostgreSQLのようにmysql_real_escape_string関数を利用してエスケープ処理できないことに注意してください。

まとめ

XPathインジェクションはSQLインジェクションと似たような攻撃手法であり、SQLインジェクションと同類の対策で防御可能であることを解説しました。文字エンコーディングベースの攻撃も考慮し、エスケープする際には文字エンコーディングに留意しなければならない点も同じです。

SQLインジェクション対策には便利なプリペアードクエリも利用可能ですが、XPathインジェクション対策には同類の仕組みは利用できません。以前にSQLインジェクション対策としてすべてのパラメータを文字列（文字リテラル）として処理する対策を紹介しました。XPathインジェクション対策には「すべてのパラメータを文字列として扱いエスケープ処理」する対策を利用します。

XPathインジェクション対策はSQLインジェクション対策と同様、非常に単純かつ完全な対策が可能です。XPathはXQuery, XLSTなどの標準にも含まれています。今後、ますますXPathを利用する場面は多くなると考えられます。ちょっとした知識と注意で脆弱性を完全に防止できます。XPathなどの新しいシステムや規格を利用する場合、そのマニュアルや規格書を参照して脆弱性を作ってしまわないよう、必要な対策を必ず行うよう注意してください。