Coders Conquer Security:シェア＆ラーンシリーズ - XXEインジェクション
XML External Entity Injection攻撃（XXE injectionと略されることもある）は、発生から数年経っても話題になっている古典的な脆弱性に比べると、比較的新しい攻撃です。しかし、現在、ハッキングコミュニティの間では非常に人気があり、成功例を重ねることでさらに人気が高まっています。
実際、OWASPは、XXEインジェクションを、サイトが注意し、積極的に防御する必要があるトップ10の脆弱性の1つとして挙げています。しかし、心配する必要はありません。XXEインジェクションは、サイバー攻撃で使用されている他のエクスプロイトよりも強力なものではありません。ただ、少しだけ新しく、少しだけ理解されていないだけです。防ぐことができますし、実際に完全に止めることもできます。
このエピソードでは、以下のことを学びます。
- 攻撃者がXXEインジェクションを使用する方法
- XXE注入が危険な理由
- この脆弱性を防ぐことができる技術
攻撃者はどのようにXXEインジェクションを引き起こすのか？
XXEインジェクションの脆弱性は、悪意のあるユーザーがXMLコードを送信する機能を与えられた場合に発生する可能性があります。悪意のあるユーザは、この機能を使って、外部のエンティティへの参照を作成します。この外部参照とコードは、デフォルト設定のXMLパーサーや、脆弱な設定のXMLパーサーをすり抜けるように設計されています。
この攻撃者は、XML規格がエンティティの概念をある種の記憶装置として定義しているが、その記憶装置は外部にも内部にもあるという事実を利用しています。適切に使用すれば、XMLプロセッサがリモートリソースにアクセスできるようになります。多くの場合、攻撃者はこの機能を利用して、Webサイトの内部構造を探ったり、リモートリソースにアクセスしようとする大規模なシステムプロセスを起動してサービス拒否攻撃を行ったり、さらにはローカルホストから自分がコントロールするリモートホストにデータをダンプしたりするなど、XMLデータベースに含まれるパスワードや個人情報などの重要なデータを流出させるのに適した手法となっています。
攻撃に使われる実際のコードは、実体のある機能を利用するだけの非常に単純なものであることが多い。例えば、ハッカーがマスターパスワードファイルにアクセスすることができるようなものです。
<!ENTITY hackwithxxe SYSTEM file:///etc/password>
なぜXXEインジェクションは危険なのか？
XXEインジェクション攻撃が非常に危険であり、また蔓延している理由はいくつかあります。1つは、現在あまり理解されていない脆弱性であること。そして、この脆弱性を悪用することで攻撃者が得られる利益は相当なものです。1つは、持続的な攻撃者が内部ネットワークのすべてのパスをゆっくりとマッピングしたり、ポートをスキャンしたりできることです。これにはかなりの時間がかかるかもしれませんが、ハッカーは信頼されたXMLパーサーによってクリアされたXMLコードをサーバーに送信しているだけなので、ターゲットネットワーク上のアクティブな防御によってハッカーの活動が発見される可能性はほとんどありません。
いったんマップが作成されると、攻撃者は同じXXEインジェクション技術を使用して、必要なファイルを取得し、直接情報を盗んだり、有効なユーザー認証情報を侵害して二次攻撃に利用したりすることができます。最後に、ただ騒ぎ立てて悪意を持ちたい攻撃者は、サービス拒否攻撃を誘発し、システムを停滞させるように設計された遠隔地のリソースにアクセスするようにアプリケーションに命令するといったことができます。
XXEインジェクション脆弱性の解消
XXEインジェクション攻撃が急増しているため、多くのXMLパーサーは外部エンティティ（DTDと呼ばれることもある）をデフォルトで完全に無効にし始めています。このような場合、重要なのは、その機能を有効にしないことです。
しかし、DTDを許可しているパーサーでも、その機能を無効にすることができます。一般的には、完全にブロックするためには以下のような記述が必要になりますが、必要なコードを正確に把握するためには、ローカルフレームワークのドキュメントを確認してください。
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)。
セキュリティの原則に従って、すべてのユーザーの入力をサニタイズし、アプリケーション全体のフィルタを使用して検証する必要があります。GET や POST のパラメータ、HTTP ヘッダー、Cookie も忘れずに入れてください。また、パーサーに処理させたい特定の DTD やコマンドのホワイトリストを作成し、それ以外のものを禁止することもできます。
ホワイトリストやフィルタリングは有効ですが、XXEインジェクション攻撃が増加しているため、機能が必要でない場合はDTDサポートを完全に無効にすることをお勧めします。
XXE Injectionsの詳細情報
さらに、OWASPがXXEインジェクション攻撃についてどのように述べているかを読んでみてください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策については、Secure Code Warrior ブログをご覧ください。
XML External Entity Injection攻撃は、比較的新しい攻撃ですが、現在、ハッキング・コミュニティの間で非常に人気があり、成功例を重ねることでさらに人気が高まっています。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
XML External Entity Injection攻撃（XXE injectionと略されることもある）は、発生から数年経っても話題になっている古典的な脆弱性に比べると、比較的新しい攻撃です。しかし、現在、ハッキングコミュニティの間では非常に人気があり、成功例を重ねることでさらに人気が高まっています。
実際、OWASPは、XXEインジェクションを、サイトが注意し、積極的に防御する必要があるトップ10の脆弱性の1つとして挙げています。しかし、心配する必要はありません。XXEインジェクションは、サイバー攻撃で使用されている他のエクスプロイトよりも強力なものではありません。ただ、少しだけ新しく、少しだけ理解されていないだけです。防ぐことができますし、実際に完全に止めることもできます。
このエピソードでは、以下のことを学びます。
- 攻撃者がXXEインジェクションを使用する方法
- XXE注入が危険な理由
- この脆弱性を防ぐことができる技術
攻撃者はどのようにXXEインジェクションを引き起こすのか？
XXEインジェクションの脆弱性は、悪意のあるユーザーがXMLコードを送信する機能を与えられた場合に発生する可能性があります。悪意のあるユーザは、この機能を使って、外部のエンティティへの参照を作成します。この外部参照とコードは、デフォルト設定のXMLパーサーや、脆弱な設定のXMLパーサーをすり抜けるように設計されています。
この攻撃者は、XML規格がエンティティの概念をある種の記憶装置として定義しているが、その記憶装置は外部にも内部にもあるという事実を利用しています。適切に使用すれば、XMLプロセッサがリモートリソースにアクセスできるようになります。多くの場合、攻撃者はこの機能を利用して、Webサイトの内部構造を探ったり、リモートリソースにアクセスしようとする大規模なシステムプロセスを起動してサービス拒否攻撃を行ったり、さらにはローカルホストから自分がコントロールするリモートホストにデータをダンプしたりするなど、XMLデータベースに含まれるパスワードや個人情報などの重要なデータを流出させるのに適した手法となっています。
攻撃に使われる実際のコードは、実体のある機能を利用するだけの非常に単純なものであることが多い。例えば、ハッカーがマスターパスワードファイルにアクセスすることができるようなものです。
<!ENTITY hackwithxxe SYSTEM file:///etc/password>
なぜXXEインジェクションは危険なのか？
XXEインジェクション攻撃が非常に危険であり、また蔓延している理由はいくつかあります。1つは、現在あまり理解されていない脆弱性であること。そして、この脆弱性を悪用することで攻撃者が得られる利益は相当なものです。1つは、持続的な攻撃者が内部ネットワークのすべてのパスをゆっくりとマッピングしたり、ポートをスキャンしたりできることです。これにはかなりの時間がかかるかもしれませんが、ハッカーは信頼されたXMLパーサーによってクリアされたXMLコードをサーバーに送信しているだけなので、ターゲットネットワーク上のアクティブな防御によってハッカーの活動が発見される可能性はほとんどありません。
いったんマップが作成されると、攻撃者は同じXXEインジェクション技術を使用して、必要なファイルを取得し、直接情報を盗んだり、有効なユーザー認証情報を侵害して二次攻撃に利用したりすることができます。最後に、ただ騒ぎ立てて悪意を持ちたい攻撃者は、サービス拒否攻撃を誘発し、システムを停滞させるように設計された遠隔地のリソースにアクセスするようにアプリケーションに命令するといったことができます。
XXEインジェクション脆弱性の解消
XXEインジェクション攻撃が急増しているため、多くのXMLパーサーは外部エンティティ（DTDと呼ばれることもある）をデフォルトで完全に無効にし始めています。このような場合、重要なのは、その機能を有効にしないことです。
しかし、DTDを許可しているパーサーでも、その機能を無効にすることができます。一般的には、完全にブロックするためには以下のような記述が必要になりますが、必要なコードを正確に把握するためには、ローカルフレームワークのドキュメントを確認してください。
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)。
セキュリティの原則に従って、すべてのユーザーの入力をサニタイズし、アプリケーション全体のフィルタを使用して検証する必要があります。GET や POST のパラメータ、HTTP ヘッダー、Cookie も忘れずに入れてください。また、パーサーに処理させたい特定の DTD やコマンドのホワイトリストを作成し、それ以外のものを禁止することもできます。
ホワイトリストやフィルタリングは有効ですが、XXEインジェクション攻撃が増加しているため、機能が必要でない場合はDTDサポートを完全に無効にすることをお勧めします。
XXE Injectionsの詳細情報
さらに、OWASPがXXEインジェクション攻撃についてどのように述べているかを読んでみてください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策については、Secure Code Warrior ブログをご覧ください。
XML External Entity Injection攻撃（XXE injectionと略されることもある）は、発生から数年経っても話題になっている古典的な脆弱性に比べると、比較的新しい攻撃です。しかし、現在、ハッキングコミュニティの間では非常に人気があり、成功例を重ねることでさらに人気が高まっています。
実際、OWASPは、XXEインジェクションを、サイトが注意し、積極的に防御する必要があるトップ10の脆弱性の1つとして挙げています。しかし、心配する必要はありません。XXEインジェクションは、サイバー攻撃で使用されている他のエクスプロイトよりも強力なものではありません。ただ、少しだけ新しく、少しだけ理解されていないだけです。防ぐことができますし、実際に完全に止めることもできます。
このエピソードでは、以下のことを学びます。
- 攻撃者がXXEインジェクションを使用する方法
- XXE注入が危険な理由
- この脆弱性を防ぐことができる技術
攻撃者はどのようにXXEインジェクションを引き起こすのか？
XXEインジェクションの脆弱性は、悪意のあるユーザーがXMLコードを送信する機能を与えられた場合に発生する可能性があります。悪意のあるユーザは、この機能を使って、外部のエンティティへの参照を作成します。この外部参照とコードは、デフォルト設定のXMLパーサーや、脆弱な設定のXMLパーサーをすり抜けるように設計されています。
この攻撃者は、XML規格がエンティティの概念をある種の記憶装置として定義しているが、その記憶装置は外部にも内部にもあるという事実を利用しています。適切に使用すれば、XMLプロセッサがリモートリソースにアクセスできるようになります。多くの場合、攻撃者はこの機能を利用して、Webサイトの内部構造を探ったり、リモートリソースにアクセスしようとする大規模なシステムプロセスを起動してサービス拒否攻撃を行ったり、さらにはローカルホストから自分がコントロールするリモートホストにデータをダンプしたりするなど、XMLデータベースに含まれるパスワードや個人情報などの重要なデータを流出させるのに適した手法となっています。
攻撃に使われる実際のコードは、実体のある機能を利用するだけの非常に単純なものであることが多い。例えば、ハッカーがマスターパスワードファイルにアクセスすることができるようなものです。
<!ENTITY hackwithxxe SYSTEM file:///etc/password>
なぜXXEインジェクションは危険なのか？
XXEインジェクション攻撃が非常に危険であり、また蔓延している理由はいくつかあります。1つは、現在あまり理解されていない脆弱性であること。そして、この脆弱性を悪用することで攻撃者が得られる利益は相当なものです。1つは、持続的な攻撃者が内部ネットワークのすべてのパスをゆっくりとマッピングしたり、ポートをスキャンしたりできることです。これにはかなりの時間がかかるかもしれませんが、ハッカーは信頼されたXMLパーサーによってクリアされたXMLコードをサーバーに送信しているだけなので、ターゲットネットワーク上のアクティブな防御によってハッカーの活動が発見される可能性はほとんどありません。
いったんマップが作成されると、攻撃者は同じXXEインジェクション技術を使用して、必要なファイルを取得し、直接情報を盗んだり、有効なユーザー認証情報を侵害して二次攻撃に利用したりすることができます。最後に、ただ騒ぎ立てて悪意を持ちたい攻撃者は、サービス拒否攻撃を誘発し、システムを停滞させるように設計された遠隔地のリソースにアクセスするようにアプリケーションに命令するといったことができます。
XXEインジェクション脆弱性の解消
XXEインジェクション攻撃が急増しているため、多くのXMLパーサーは外部エンティティ（DTDと呼ばれることもある）をデフォルトで完全に無効にし始めています。このような場合、重要なのは、その機能を有効にしないことです。
しかし、DTDを許可しているパーサーでも、その機能を無効にすることができます。一般的には、完全にブロックするためには以下のような記述が必要になりますが、必要なコードを正確に把握するためには、ローカルフレームワークのドキュメントを確認してください。
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)。
セキュリティの原則に従って、すべてのユーザーの入力をサニタイズし、アプリケーション全体のフィルタを使用して検証する必要があります。GET や POST のパラメータ、HTTP ヘッダー、Cookie も忘れずに入れてください。また、パーサーに処理させたい特定の DTD やコマンドのホワイトリストを作成し、それ以外のものを禁止することもできます。
ホワイトリストやフィルタリングは有効ですが、XXEインジェクション攻撃が増加しているため、機能が必要でない場合はDTDサポートを完全に無効にすることをお勧めします。
XXE Injectionsの詳細情報
さらに、OWASPがXXEインジェクション攻撃についてどのように述べているかを読んでみてください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策については、Secure Code Warrior ブログをご覧ください。
XML External Entity Injection攻撃（XXE injectionと略されることもある）は、発生から数年経っても話題になっている古典的な脆弱性に比べると、比較的新しい攻撃です。しかし、現在、ハッキングコミュニティの間では非常に人気があり、成功例を重ねることでさらに人気が高まっています。
実際、OWASPは、XXEインジェクションを、サイトが注意し、積極的に防御する必要があるトップ10の脆弱性の1つとして挙げています。しかし、心配する必要はありません。XXEインジェクションは、サイバー攻撃で使用されている他のエクスプロイトよりも強力なものではありません。ただ、少しだけ新しく、少しだけ理解されていないだけです。防ぐことができますし、実際に完全に止めることもできます。
このエピソードでは、以下のことを学びます。
- 攻撃者がXXEインジェクションを使用する方法
- XXE注入が危険な理由
- この脆弱性を防ぐことができる技術
攻撃者はどのようにXXEインジェクションを引き起こすのか？
XXEインジェクションの脆弱性は、悪意のあるユーザーがXMLコードを送信する機能を与えられた場合に発生する可能性があります。悪意のあるユーザは、この機能を使って、外部のエンティティへの参照を作成します。この外部参照とコードは、デフォルト設定のXMLパーサーや、脆弱な設定のXMLパーサーをすり抜けるように設計されています。
この攻撃者は、XML規格がエンティティの概念をある種の記憶装置として定義しているが、その記憶装置は外部にも内部にもあるという事実を利用しています。適切に使用すれば、XMLプロセッサがリモートリソースにアクセスできるようになります。多くの場合、攻撃者はこの機能を利用して、Webサイトの内部構造を探ったり、リモートリソースにアクセスしようとする大規模なシステムプロセスを起動してサービス拒否攻撃を行ったり、さらにはローカルホストから自分がコントロールするリモートホストにデータをダンプしたりするなど、XMLデータベースに含まれるパスワードや個人情報などの重要なデータを流出させるのに適した手法となっています。
攻撃に使われる実際のコードは、実体のある機能を利用するだけの非常に単純なものであることが多い。例えば、ハッカーがマスターパスワードファイルにアクセスすることができるようなものです。
<!ENTITY hackwithxxe SYSTEM file:///etc/password>
なぜXXEインジェクションは危険なのか？
XXEインジェクション攻撃が非常に危険であり、また蔓延している理由はいくつかあります。1つは、現在あまり理解されていない脆弱性であること。そして、この脆弱性を悪用することで攻撃者が得られる利益は相当なものです。1つは、持続的な攻撃者が内部ネットワークのすべてのパスをゆっくりとマッピングしたり、ポートをスキャンしたりできることです。これにはかなりの時間がかかるかもしれませんが、ハッカーは信頼されたXMLパーサーによってクリアされたXMLコードをサーバーに送信しているだけなので、ターゲットネットワーク上のアクティブな防御によってハッカーの活動が発見される可能性はほとんどありません。
いったんマップが作成されると、攻撃者は同じXXEインジェクション技術を使用して、必要なファイルを取得し、直接情報を盗んだり、有効なユーザー認証情報を侵害して二次攻撃に利用したりすることができます。最後に、ただ騒ぎ立てて悪意を持ちたい攻撃者は、サービス拒否攻撃を誘発し、システムを停滞させるように設計された遠隔地のリソースにアクセスするようにアプリケーションに命令するといったことができます。
XXEインジェクション脆弱性の解消
XXEインジェクション攻撃が急増しているため、多くのXMLパーサーは外部エンティティ（DTDと呼ばれることもある）をデフォルトで完全に無効にし始めています。このような場合、重要なのは、その機能を有効にしないことです。
しかし、DTDを許可しているパーサーでも、その機能を無効にすることができます。一般的には、完全にブロックするためには以下のような記述が必要になりますが、必要なコードを正確に把握するためには、ローカルフレームワークのドキュメントを確認してください。
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)。
セキュリティの原則に従って、すべてのユーザーの入力をサニタイズし、アプリケーション全体のフィルタを使用して検証する必要があります。GET や POST のパラメータ、HTTP ヘッダー、Cookie も忘れずに入れてください。また、パーサーに処理させたい特定の DTD やコマンドのホワイトリストを作成し、それ以外のものを禁止することもできます。
ホワイトリストやフィルタリングは有効ですが、XXEインジェクション攻撃が増加しているため、機能が必要でない場合はDTDサポートを完全に無効にすることをお勧めします。
XXE Injectionsの詳細情報
さらに、OWASPがXXEインジェクション攻撃についてどのように述べているかを読んでみてください。また、サイバーセキュリティチームを究極のサイバー戦士に育成する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運動の背後にある現実を明らかにしました。セキュア・バイ・デザインは、セキュリティ・チーム全体で共有された野心ですが、共有されたプレイブックはありません。
