Coders Conquer Security:シェア＆ラーンシリーズ - XMLインジェクション
XMLインジェクション攻撃は、XMLデータベースを搭載したシステムを危険にさらすために、ハッカーが考案したちょっとした悪意ある攻撃です。これには、従来のデータベースで思い浮かぶような、薬から映画まであらゆる情報を詳細に保存したものが含まれます。XMLデータストアの中には、許可されたユーザーをチェックするために使用されているものもあります。そのため、新しいXMLコードを注入すると、ホストシステムがその時点から受け入れることができる新しいユーザーが作成されます。
攻撃者がXMLインジェクションを実行するためには、XMLデータベースに依存しているか、少なくともXMLデータベースにアクセスしているアプリケーションが必要です。その際、ユーザーの入力が適切に吟味されていないと、新しいXMLコードがデータストアに追加されてしまいます。攻撃者のスキルにもよりますが、新しいXMLコードを追加することで、かなりのダメージを与えることができますし、データベース全体へのアクセスが可能になることもあります。
読み進めていくと、XMLインジェクションが、前回取り上げたSQLインジェクション攻撃と密接に関連していることに気づくかもしれません。この2つの攻撃は、異なる種類のデータベースを対象としているにもかかわらず、非常によく似ているからです。そして、ありがたいことに、修正方法も似ています。一方の攻撃を防ぐ方法を学ぶことで、もう一方の攻撃を防ぐための作業を有利に進めることができます。
このエピソードでは、以下のことを学びます。
- XMLインジェクションの仕組み
- なぜ彼らは危険なのか
- 完全に阻止するための防御策を講じることができます。
攻撃者はどのようにしてXMLインジェクションを引き起こすのか？
XML インジェクションは、権限のないユーザーが XML コードを記述し、それを既存の XML データベースに挿入することができれば、必ず成功します。これが機能するためには、XMLデータベースに依存している、または接続しているアプリケーションと、攻撃者が攻撃を開始するための安全でないデータ経路の2つが必要です。
XMLインジェクションは、ユーザーの入力がサーバーに送られて処理される前に、サニタイズやその他の制限が行われていなければ、ほぼ必ず成功します。これにより、攻撃者は通常のクエリ文字列の最後に独自のコードを書いたり、注入したりすることができます。これが成功すると、サーバーを騙してXMLコードを実行させ、レコードの追加や削除、さらにはデータベース全体の公開を可能にします。
ハッカーは、通常のクエリにXMLコードを追加することで、XMLインジェクション攻撃を行います。これには、検索フィールドからログインページまで、あらゆるものが含まれます。また、クッキーやヘッダーなども含まれることがあります。
例えば、登録フォームで、ユーザー名やパスワードの欄の後に次のようなコードを追加するとします。
<user></user>
<role>administrator</role>
<username>John_Smith</username><password>Jump783!Tango@12</password>
この例では、John_Smithという名前の新しいユーザーが管理者権限で作成されます。少なくとも、この新しいユーザーはパスワード密度の高いルールを採用しています。しかし、実際には攻撃者であることが残念です。
ハッカーは、XMLインジェクションで成功するために、必ずしも常にこのようなホームランを打つ必要はありません。クエリを操作し、サーバーが返すさまざまなエラーメッセージを記録することで、XMLデータベースの構造を把握することができるかもしれません。そしてその情報は、他のタイプの攻撃を強化するために使用することができます。
なぜXML注射は危険なのか？
XMLインジェクション攻撃の危険度は、対象となるXMLデータベースにどのような情報が保存されているか、またはその情報がどのように使用されているかによって異なります。例えば、ユーザーの認証にXMLデータベースを使用している場合、XMLインジェクションによって攻撃者はシステムにアクセスすることができます。これにより、攻撃者は対象となるネットワークの管理者になることができるかもしれませんが、これはもちろん非常に危険な状況です。
従来のデータベースに対して行われるXMLインジェクションでは、情報が盗まれたり、誤ったデータがストアに追加されたり、場合によっては正常なデータが上書きされたりする危険性があります。XMLコードの習得はそれほど難しくなく、コマンドの中には、情報フィールド全体を上書きしたり、データストアの内容を表示したりするなど、非常に強力なものもあります。
一般的に、データベースに保存されている情報に価値がなければ、誰もデータベースを構築しません。ハッカーはこのことを知っているので、しばしばデータベースを標的にします。そのデータに従業員や顧客の個人情報などが含まれている場合、その情報が漏洩すると、評判の失墜、経済的影響、多額の罰金、さらには訴訟にまで発展する可能性があります。
XMLインジェクション攻撃の阻止
XMLインジェクションは、攻撃の難易度が低く、XMLデータベースが普及していることもあり、かなり一般的に行われています。しかし、これらの攻撃は長い間存在しています。そのため、これらの攻撃が実行されないようにするための鉄板の修正方法がいくつかあります。
このような攻撃を阻止する最善の方法の一つは、コンパイル済みのXMLクエリのみを使用するようにアプリケーションを設計することです。これにより、クエリの機能は、許可された活動のサブセットに制限されます。プリコンパイルされたクエリの機能と一致しない余分な引数やコマンドが入ってきたものは、単に実行されません。ここまで制限したくない場合は、パラメータ化を使用することもできます。これは、ユーザの入力を特定のタイプのクエリやデータに制限するもので、例えば整数のみを使用するといったものです。これらのパラメータから外れたものは無効とみなされ、クエリは失敗に終わります。
また、プリコンパイルされたクエリやパラメータ化されたクエリに、カスタマイズされたエラーメッセージを組み合わせるのも良いアイデアです。アプリケーションは、失敗したクエリからデフォルトの説明的なエラーメッセージを送り返すのではなく、それらのレスポンスをインターセプトして、より一般的なメッセージに置き換えるべきです。理想的には、なぜクエリが失敗したのかをユーザに伝えたいが、データベース自体に関する情報は伝えたくないということです。このようなカスタムメッセージをいくつかの選択肢に限定すれば、ハッカーは失敗したクエリから有益な偵察を行うことができなくなります。
XMLインジェクションが開発された当初は大きな成功を収めました。しかし、それが昔のことであるならば、今日では、もはや破られることのない防御策を簡単に構築することができます。
XML Injectionsの詳細情報
さらに詳しく知りたい方は、OWASPのXMLインジェクションに関する記事をご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
Jaap Karan Singh
セキュアコーディングに関する最新の知見をブログでご紹介しています。
当社の豊富なリソースライブラリは、安全なコーディングアップスキルに対する人間的なアプローチを強化することを目的としています。
開発者主導のセキュリティに関する最新の研究成果を入手する
ホワイトペーパーからウェビナーまで、開発者主導のセキュアコーディングを始めるために役立つリソースが満載のリソースライブラリです。今すぐご覧ください。
Coders Conquer Security:シェア＆ラーンシリーズ - XMLインジェクション
XMLインジェクション攻撃は、XMLデータベースを搭載したシステムを危険にさらすために、ハッカーが考案したちょっとした悪意ある攻撃です。これには、従来のデータベースで思い浮かぶような、薬から映画まであらゆる情報を詳細に保存したものが含まれます。XMLデータストアの中には、許可されたユーザーをチェックするために使用されているものもあります。そのため、新しいXMLコードを注入すると、ホストシステムがその時点から受け入れることができる新しいユーザーが作成されます。
攻撃者がXMLインジェクションを実行するためには、XMLデータベースに依存しているか、少なくともXMLデータベースにアクセスしているアプリケーションが必要です。その際、ユーザーの入力が適切に吟味されていないと、新しいXMLコードがデータストアに追加されてしまいます。攻撃者のスキルにもよりますが、新しいXMLコードを追加することで、かなりのダメージを与えることができますし、データベース全体へのアクセスが可能になることもあります。
読み進めていくと、XMLインジェクションが、前回取り上げたSQLインジェクション攻撃と密接に関連していることに気づくかもしれません。この2つの攻撃は、異なる種類のデータベースを対象としているにもかかわらず、非常によく似ているからです。そして、ありがたいことに、修正方法も似ています。一方の攻撃を防ぐ方法を学ぶことで、もう一方の攻撃を防ぐための作業を有利に進めることができます。
このエピソードでは、以下のことを学びます。
- XMLインジェクションの仕組み
- なぜ彼らは危険なのか
- 完全に阻止するための防御策を講じることができます。
攻撃者はどのようにしてXMLインジェクションを引き起こすのか？
XML インジェクションは、権限のないユーザーが XML コードを記述し、それを既存の XML データベースに挿入することができれば、必ず成功します。これが機能するためには、XMLデータベースに依存している、または接続しているアプリケーションと、攻撃者が攻撃を開始するための安全でないデータ経路の2つが必要です。
XMLインジェクションは、ユーザーの入力がサーバーに送られて処理される前に、サニタイズやその他の制限が行われていなければ、ほぼ必ず成功します。これにより、攻撃者は通常のクエリ文字列の最後に独自のコードを書いたり、注入したりすることができます。これが成功すると、サーバーを騙してXMLコードを実行させ、レコードの追加や削除、さらにはデータベース全体の公開を可能にします。
ハッカーは、通常のクエリにXMLコードを追加することで、XMLインジェクション攻撃を行います。これには、検索フィールドからログインページまで、あらゆるものが含まれます。また、クッキーやヘッダーなども含まれることがあります。
例えば、登録フォームで、ユーザー名やパスワードの欄の後に次のようなコードを追加するとします。
<user></user>
<role>administrator</role>
<username>John_Smith</username><password>Jump783!Tango@12</password>
この例では、John_Smithという名前の新しいユーザーが管理者権限で作成されます。少なくとも、この新しいユーザーはパスワード密度の高いルールを採用しています。しかし、実際には攻撃者であることが残念です。
ハッカーは、XMLインジェクションで成功するために、必ずしも常にこのようなホームランを打つ必要はありません。クエリを操作し、サーバーが返すさまざまなエラーメッセージを記録することで、XMLデータベースの構造を把握することができるかもしれません。そしてその情報は、他のタイプの攻撃を強化するために使用することができます。
なぜXML注射は危険なのか？
XMLインジェクション攻撃の危険度は、対象となるXMLデータベースにどのような情報が保存されているか、またはその情報がどのように使用されているかによって異なります。例えば、ユーザーの認証にXMLデータベースを使用している場合、XMLインジェクションによって攻撃者はシステムにアクセスすることができます。これにより、攻撃者は対象となるネットワークの管理者になることができるかもしれませんが、これはもちろん非常に危険な状況です。
従来のデータベースに対して行われるXMLインジェクションでは、情報が盗まれたり、誤ったデータがストアに追加されたり、場合によっては正常なデータが上書きされたりする危険性があります。XMLコードの習得はそれほど難しくなく、コマンドの中には、情報フィールド全体を上書きしたり、データストアの内容を表示したりするなど、非常に強力なものもあります。
一般的に、データベースに保存されている情報に価値がなければ、誰もデータベースを構築しません。ハッカーはこのことを知っているので、しばしばデータベースを標的にします。そのデータに従業員や顧客の個人情報などが含まれている場合、その情報が漏洩すると、評判の失墜、経済的影響、多額の罰金、さらには訴訟にまで発展する可能性があります。
XMLインジェクション攻撃の阻止
XMLインジェクションは、攻撃の難易度が低く、XMLデータベースが普及していることもあり、かなり一般的に行われています。しかし、これらの攻撃は長い間存在しています。そのため、これらの攻撃が実行されないようにするための鉄板の修正方法がいくつかあります。
このような攻撃を阻止する最善の方法の一つは、コンパイル済みのXMLクエリのみを使用するようにアプリケーションを設計することです。これにより、クエリの機能は、許可された活動のサブセットに制限されます。プリコンパイルされたクエリの機能と一致しない余分な引数やコマンドが入ってきたものは、単に実行されません。ここまで制限したくない場合は、パラメータ化を使用することもできます。これは、ユーザの入力を特定のタイプのクエリやデータに制限するもので、例えば整数のみを使用するといったものです。これらのパラメータから外れたものは無効とみなされ、クエリは失敗に終わります。
また、プリコンパイルされたクエリやパラメータ化されたクエリに、カスタマイズされたエラーメッセージを組み合わせるのも良いアイデアです。アプリケーションは、失敗したクエリからデフォルトの説明的なエラーメッセージを送り返すのではなく、それらのレスポンスをインターセプトして、より一般的なメッセージに置き換えるべきです。理想的には、なぜクエリが失敗したのかをユーザに伝えたいが、データベース自体に関する情報は伝えたくないということです。このようなカスタムメッセージをいくつかの選択肢に限定すれば、ハッカーは失敗したクエリから有益な偵察を行うことができなくなります。
XMLインジェクションが開発された当初は大きな成功を収めました。しかし、それが昔のことであるならば、今日では、もはや破られることのない防御策を簡単に構築することができます。
XML Injectionsの詳細情報
さらに詳しく知りたい方は、OWASPのXMLインジェクションに関する記事をご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
