エンジニアのためのセキュリティ攻略：共有＆学習シリーズ - XQueryインジェクション

XQueryインジェクション攻撃は、より一般的なSQLインジェクション攻撃の「弟分」のように考えられることがあります。両者は根本的な原因が似ており、攻撃者が悪用するコマンドも非常に近いためです。ただし、XQueryインジェクション攻撃はXMLデータに対するXPathクエリの実行中にのみ発生します。そのため、攻撃手法にちなんでXPathインジェクションや単にXPath攻撃と呼ばれることもあります。

非常に多くのウェブサイトが、ユーザーのログイン情報、顧客データ、個人情報、機密データといった重要な情報を保持するためにXMLデータベースを使用しており、XQuery攻撃に対して非常に広い攻撃対象領域をさらしています。

本エピソードでは、以下の内容を学びます。

• 攻撃者はどのようにXQueryインジェクションを利用するのか
• XQueryインジェクションが危険な理由
• この脆弱性を修正する技術

攻撃者はどのようにしてXQueryインジェクションを引き起こすのか？

多くのコンピュータ言語と同様に、XPathのコードもシンプルさを重視して設計されています。実際、XPathは標準化された言語であり、どのアプリケーションで使用しても表記法や構文は変わりません。つまり、XPathクエリを操作するためのコマンドは広く知られており、自動化さえ可能なのです。

XPathクエリの本質は、XMLデータベースに対してどの情報を検索すべきかを指示する単純なステートメントです。最も単純な例では、ユーザーレコードの存在を確認し、ログイン情報を取得するために使用されます。問題は、XPathクエリにユーザー入力が含まれるため、ハッカーがクエリを操作して保護されるべき情報を引き出せてしまう点にあります。

例えば、ログインセキュリティを回避しようとする際、攻撃者はXPathクエリの末尾に変数を追加してプロセス全体を無効化できます。例を挙げると以下のようになります。

//Employee[UserName/text()=anyone or 1=1 or a=a And Password/text()=doesnotmatter]

ここでは、「1=1」や「a=a」というステートメントにより、ユーザー名フィールドが任意のユーザーと一致するように仕向けられています。クエリの最初の部分が真であればよいため、パスワードフィールドの内容は関係なくなります。

なぜXQueryインジェクションは危険なのか？

XQueryインジェクション攻撃が非常に危険な主な理由は、ログインやアカウントのセキュリティを回避できる点にあります。しかも、アプリケーションごとに変わることのない標準言語を使用するため、自動化された手法で実行可能です。攻撃者はウェブサイトやアプリケーションを自動スキャンしてこの脆弱性を探し出し、発見次第すぐに行動に移せます。アプリに脆弱性があれば、攻撃者に侵害されてしまいます。アカウントセキュリティの侵害に加え、XQuery攻撃はデータ流出にも利用されます。例えば、攻撃者がXMLデータベースからすべてのレコードを転送してしまうといったことが可能です。

XQueryインジェクション攻撃の排除

同様の脆弱性に対する対策と同様に、重要な防御策は「ユーザー入力を決して信頼しない」ことです。データベースクエリの有無にかかわらず、ユーザーが情報を入力できる場所はすべて精査する必要があります。これは、物理的な建物の窓やドアを施錠して侵入を防ぐのと変わりません。

XQueryインジェクションを防ぐには、フィルタリングによるユーザー入力のサニタイズや、ホワイトリストを用いた入力バリデーションを行います。また、SQLクエリのプリペアドステートメントと同様に、パラメータ化されたXPathインターフェースを使用することも有効です。

最後に、すべてのアプリケーションに対して最小権限の原則を適用してください。例えば、アプリケーションのクエリを実行するユーザーには読み取り専用の権限のみを付与するといった対策が考えられます。

これらの技術を用いることで、ウェブサイトやアプリケーションに対するあらゆるXQueryインジェクションの試みを阻止することが可能です。

XQueryインジェクションに関する詳細情報

詳細については、OWASPによるXQueryインジェクションの解説をご覧ください。また、サイバーセキュリティチームを最強のサイバー戦士へと育成するSecure Code Warriorプラットフォームの無料デモで、習得した防御知識を試すことも可能です。この脆弱性やその他の脅威への対策について詳しくは、Secure Code Warriorブログをご覧ください。