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 ブログをご覧ください。
XMLインジェクション攻撃は、XMLデータベースを搭載したシステムを危険にさらすために、ハッカーが考案したちょっとした悪意ある攻撃です。これには、従来のデータベースで思い浮かぶような、薬や映画などの詳細な情報が格納されているものが含まれます。
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 の共同設立者です。
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 ブログをご覧ください。
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 ブログをご覧ください。
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
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 ブログをご覧ください。
始めるためのリソース
セキュア・バイ・デザインベストプラクティスの定義、開発者の能力向上、予防的セキュリティ成果のベンチマーク
このリサーチペーパーでは、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運動の背後にある現実を明らかにしました。セキュア・バイ・デザインは、セキュリティ・チーム全体で共有された野心ですが、共有されたプレイブックはありません。
