Coders Conquer Security:シェア＆ラーンシリーズ - XQueryインジェクション
XQueryインジェクション攻撃は、より広く普及しているSQLインジェクション攻撃の弟分のように考えられることがあります。この2つの攻撃は根本的な原因が似ており、攻撃者が攻撃のきっかけとして利用するコマンドも非常に似ています。ただ、XQueryインジェクション攻撃は、XMLデータに対するXPathクエリの際にのみ発生します。このため、XQueryインジェクション攻撃は、XPathインジェクションと呼ばれることもあれば、XPathを利用した攻撃と呼ばれることもあります。
大多数のWebサイトでは、ユーザーのログイン認証情報、顧客情報、個人の識別情報、機密データなどの重要な機能に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]
ここでは、User Nameフィールドは、1=1またはa=aの記述により、どのユーザーにもマッチするようになっています。クエリの最初の部分だけが真であればよいので、パスワードフィールドは問題になりません。
XQueryインジェクションはなぜ危険なのか？
XQueryインジェクション攻撃が危険である第一の理由は、攻撃者がログインやアカウントのセキュリティを回避することができるからです。また、アプリケーションによって異なることのない標準的な言語を使用して、自動化された方法で実行することができます。攻撃者は、ウェブサイトやアプリケーションを自動的にスキャンして、この脆弱性を発見したらすぐに行動することができます。あなたのアプリに脆弱性があれば、攻撃者はそのアプリを侵害します。アカウントのセキュリティを侵害するだけでなく、XQuery攻撃はデータの流出にも利用できます。例えば、攻撃者はXMLデータベースからすべてのレコードを転送することができます。
XQueryインジェクション攻撃の排除
同様の脆弱性と同様に、重要な防御策の1つは、単純にユーザーの入力を信用しないことです。ユーザーが情報を入力する際には、それがデータベースへの問い合わせであるかどうかにかかわらず、そのプロセスを精査する必要があります。これは、物理的な建物の窓やドアを保護することと同じです。なぜなら、これらの窓やドアは人がアクセスできる主な方法だからです。
XQuery のインジェクション対策としては、フィルタリングによるユーザー入力のサニタイズや、ホワイトリストによるユーザー入力の検証を行うことで実現しています。また、SQL クエリのプリペアド・ステートメントと同様に、パラメータ化された XPath インターフェイスを使用することもできます。
最後に、すべてのアプリケーションに最小の特権を適用するようにしてください。これは、すべてのアプリケーションのクエリを実行するために、読み取り専用の特権を持つユーザーを作成することを意味します。
これらの技術を用いることで、ウェブサイトやアプリケーションに対するXQueryインジェクションの試みをすべて阻止することができます。
XQuery Injectionsの詳細情報
さらに、OWASPがXQuery Injectionsについてどのように述べているかを見ることができます。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策についての詳細は、Secure Code Warriorブログをご覧ください。
大多数のWebサイトでは、ユーザーのログイン認証情報、顧客情報、個人の識別情報、機密データなどの重要な機能にXMLデータベースが使用されているため、XQuery攻撃の攻撃対象はかなり大きくなっています。
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
XQueryインジェクション攻撃は、より広く普及しているSQLインジェクション攻撃の弟分のように考えられることがあります。この2つの攻撃は根本的な原因が似ており、攻撃者が攻撃のきっかけとして利用するコマンドも非常に似ています。ただ、XQueryインジェクション攻撃は、XMLデータに対するXPathクエリの際にのみ発生します。このため、XQueryインジェクション攻撃は、XPathインジェクションと呼ばれることもあれば、XPathを利用した攻撃と呼ばれることもあります。
大多数のWebサイトでは、ユーザーのログイン認証情報、顧客情報、個人の識別情報、機密データなどの重要な機能に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]
ここでは、User Nameフィールドは、1=1またはa=aの記述により、どのユーザーにもマッチするようになっています。クエリの最初の部分だけが真であればよいので、パスワードフィールドは問題になりません。
XQueryインジェクションはなぜ危険なのか？
XQueryインジェクション攻撃が危険である第一の理由は、攻撃者がログインやアカウントのセキュリティを回避することができるからです。また、アプリケーションによって異なることのない標準的な言語を使用して、自動化された方法で実行することができます。攻撃者は、ウェブサイトやアプリケーションを自動的にスキャンして、この脆弱性を発見したらすぐに行動することができます。あなたのアプリに脆弱性があれば、攻撃者はそのアプリを侵害します。アカウントのセキュリティを侵害するだけでなく、XQuery攻撃はデータの流出にも利用できます。例えば、攻撃者はXMLデータベースからすべてのレコードを転送することができます。
XQueryインジェクション攻撃の排除
同様の脆弱性と同様に、重要な防御策の1つは、単純にユーザーの入力を信用しないことです。ユーザーが情報を入力する際には、それがデータベースへの問い合わせであるかどうかにかかわらず、そのプロセスを精査する必要があります。これは、物理的な建物の窓やドアを保護することと同じです。なぜなら、これらの窓やドアは人がアクセスできる主な方法だからです。
XQuery のインジェクション対策としては、フィルタリングによるユーザー入力のサニタイズや、ホワイトリストによるユーザー入力の検証を行うことで実現しています。また、SQL クエリのプリペアド・ステートメントと同様に、パラメータ化された XPath インターフェイスを使用することもできます。
最後に、すべてのアプリケーションに最小の特権を適用するようにしてください。これは、すべてのアプリケーションのクエリを実行するために、読み取り専用の特権を持つユーザーを作成することを意味します。
これらの技術を用いることで、ウェブサイトやアプリケーションに対するXQueryインジェクションの試みをすべて阻止することができます。
XQuery Injectionsの詳細情報
さらに、OWASPがXQuery Injectionsについてどのように述べているかを見ることができます。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策についての詳細は、Secure Code Warriorブログをご覧ください。
XQueryインジェクション攻撃は、より広く普及しているSQLインジェクション攻撃の弟分のように考えられることがあります。この2つの攻撃は根本的な原因が似ており、攻撃者が攻撃のきっかけとして利用するコマンドも非常に似ています。ただ、XQueryインジェクション攻撃は、XMLデータに対するXPathクエリの際にのみ発生します。このため、XQueryインジェクション攻撃は、XPathインジェクションと呼ばれることもあれば、XPathを利用した攻撃と呼ばれることもあります。
大多数のWebサイトでは、ユーザーのログイン認証情報、顧客情報、個人の識別情報、機密データなどの重要な機能に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]
ここでは、User Nameフィールドは、1=1またはa=aの記述により、どのユーザーにもマッチするようになっています。クエリの最初の部分だけが真であればよいので、パスワードフィールドは問題になりません。
XQueryインジェクションはなぜ危険なのか？
XQueryインジェクション攻撃が危険である第一の理由は、攻撃者がログインやアカウントのセキュリティを回避することができるからです。また、アプリケーションによって異なることのない標準的な言語を使用して、自動化された方法で実行することができます。攻撃者は、ウェブサイトやアプリケーションを自動的にスキャンして、この脆弱性を発見したらすぐに行動することができます。あなたのアプリに脆弱性があれば、攻撃者はそのアプリを侵害します。アカウントのセキュリティを侵害するだけでなく、XQuery攻撃はデータの流出にも利用できます。例えば、攻撃者はXMLデータベースからすべてのレコードを転送することができます。
XQueryインジェクション攻撃の排除
同様の脆弱性と同様に、重要な防御策の1つは、単純にユーザーの入力を信用しないことです。ユーザーが情報を入力する際には、それがデータベースへの問い合わせであるかどうかにかかわらず、そのプロセスを精査する必要があります。これは、物理的な建物の窓やドアを保護することと同じです。なぜなら、これらの窓やドアは人がアクセスできる主な方法だからです。
XQuery のインジェクション対策としては、フィルタリングによるユーザー入力のサニタイズや、ホワイトリストによるユーザー入力の検証を行うことで実現しています。また、SQL クエリのプリペアド・ステートメントと同様に、パラメータ化された XPath インターフェイスを使用することもできます。
最後に、すべてのアプリケーションに最小の特権を適用するようにしてください。これは、すべてのアプリケーションのクエリを実行するために、読み取り専用の特権を持つユーザーを作成することを意味します。
これらの技術を用いることで、ウェブサイトやアプリケーションに対するXQueryインジェクションの試みをすべて阻止することができます。
XQuery Injectionsの詳細情報
さらに、OWASPがXQuery Injectionsについてどのように述べているかを見ることができます。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策についての詳細は、Secure Code Warriorブログをご覧ください。
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
XQueryインジェクション攻撃は、より広く普及しているSQLインジェクション攻撃の弟分のように考えられることがあります。この2つの攻撃は根本的な原因が似ており、攻撃者が攻撃のきっかけとして利用するコマンドも非常に似ています。ただ、XQueryインジェクション攻撃は、XMLデータに対するXPathクエリの際にのみ発生します。このため、XQueryインジェクション攻撃は、XPathインジェクションと呼ばれることもあれば、XPathを利用した攻撃と呼ばれることもあります。
大多数のWebサイトでは、ユーザーのログイン認証情報、顧客情報、個人の識別情報、機密データなどの重要な機能に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]
ここでは、User Nameフィールドは、1=1またはa=aの記述により、どのユーザーにもマッチするようになっています。クエリの最初の部分だけが真であればよいので、パスワードフィールドは問題になりません。
XQueryインジェクションはなぜ危険なのか？
XQueryインジェクション攻撃が危険である第一の理由は、攻撃者がログインやアカウントのセキュリティを回避することができるからです。また、アプリケーションによって異なることのない標準的な言語を使用して、自動化された方法で実行することができます。攻撃者は、ウェブサイトやアプリケーションを自動的にスキャンして、この脆弱性を発見したらすぐに行動することができます。あなたのアプリに脆弱性があれば、攻撃者はそのアプリを侵害します。アカウントのセキュリティを侵害するだけでなく、XQuery攻撃はデータの流出にも利用できます。例えば、攻撃者はXMLデータベースからすべてのレコードを転送することができます。
XQueryインジェクション攻撃の排除
同様の脆弱性と同様に、重要な防御策の1つは、単純にユーザーの入力を信用しないことです。ユーザーが情報を入力する際には、それがデータベースへの問い合わせであるかどうかにかかわらず、そのプロセスを精査する必要があります。これは、物理的な建物の窓やドアを保護することと同じです。なぜなら、これらの窓やドアは人がアクセスできる主な方法だからです。
XQuery のインジェクション対策としては、フィルタリングによるユーザー入力のサニタイズや、ホワイトリストによるユーザー入力の検証を行うことで実現しています。また、SQL クエリのプリペアド・ステートメントと同様に、パラメータ化された XPath インターフェイスを使用することもできます。
最後に、すべてのアプリケーションに最小の特権を適用するようにしてください。これは、すべてのアプリケーションのクエリを実行するために、読み取り専用の特権を持つユーザーを作成することを意味します。
これらの技術を用いることで、ウェブサイトやアプリケーションに対するXQueryインジェクションの試みをすべて阻止することができます。
XQuery Injectionsの詳細情報
さらに、OWASPがXQuery Injectionsについてどのように述べているかを見ることができます。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策についての詳細は、Secure Code Warriorブログをご覧ください。
始めるためのリソース
セキュア・バイ・デザインベストプラクティスの定義、開発者の能力向上、予防的セキュリティ成果のベンチマーク
このリサーチペーパーでは、Secure Code Warrior 共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士、そして専門家であるクリス・イングリス（Chris Inglis）氏（元米国サイバーディレクター、現パラディン・キャピタル・グループ戦略顧問）、デヴィン・リンチ（Devin Lynch）氏（パラディン・グローバル・インスティテュート・シニアディレクター）が、CISO、アプリケーション・セキュリティ担当副社長、ソフトウェア・セキュリティの専門家など、企業のセキュリティ・リーダー20人以上への詳細なインタビューから得られた主な知見を明らかにします。
セキュリティ スキルのベンチマーク: 企業におけるセキュアな設計の合理化
セキュアバイデザイン（SBD）構想の成功に関する有意義なデータを見つけることは、非常に困難である。CISO は、セキュリティプログラム活動の投資収益率（ROI）とビジネス価値を、従業員レベルと企業レベルの両方で証明しようとすると、しばしば困難に直面します。言うまでもなく、企業にとって、現在の業界標準に対して自社の組織がどのようにベンチマークされているかを把握することは特に困難です。大統領の国家サイバーセキュリティ戦略は、関係者に「デザインによるセキュリティとレジリエンスを受け入れる」ことを求めている。セキュアバイデザインの取り組みを成功させる鍵は、開発者にセキュアなコードを保証するスキルを与えるだけでなく、規制当局にそれらのスキルが整っていることを保証することである。本プレゼンテーションでは、25万人以上の開発者から収集した社内データ、データに基づく顧客の洞察、公的研究など、複数の一次ソースから得られた無数の定性的・定量的データを紹介します。こうしたデータ・ポイントの集積を活用することで、複数の業種におけるセキュア・バイ・デザイン・イニシアチブの現状をお伝えすることを目的としています。本レポートでは、この領域が現在十分に活用されていない理由、スキルアッププログラムの成功がサイバーセキュリティのリスク軽減に与える大きな影響、コードベースから脆弱性のカテゴリーを排除できる可能性について詳述しています。
始めるためのリソース
明らかになった：サイバー業界はセキュア・バイ・デザインをどのように定義しているか
最新のホワイトペーパーでは、当社の共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士が、CISO、AppSecリーダー、セキュリティ専門家を含む20人以上の企業セキュリティリーダーと対談し、このパズルの重要なピースを見つけ出し、Secure by Design運動の背後にある現実を明らかにしました。セキュア・バイ・デザインは、セキュリティ・チーム全体で共有された野心ですが、共有されたプレイブックはありません。
