Coders Conquer Security:シェアして学ぼうシリーズ - リモートファイルインクルージョン
このブログシリーズをご覧になっている方は、今回のリモートファイル取り込みの脆弱性と、前回ご紹介したローカルファイル取り込みおよびパストラバーサルの脆弱性の間に、多くの類似点があることにお気づきになるかもしれません。これらの脆弱性の根本的な原因は、推奨される修正方法と同様に類似しています。
多くの点で、リモート・ファイル・インクルージョンの脆弱性は、ローカル・ファイル・インクルージョンの脆弱性よりもはるかに危険であり、また悪用されやすいものです。そのため、できるだけ早く発見し、対策を講じる必要があります。あるいは、より良い方法として、ウェブアプリケーションは、そもそもこの脆弱性が発生しないように設計されるべきです。
このエピソードでは、以下のことを学びます。
- リモートファイルインクルージョンの脆弱性を利用したハッカーの手口
- リモートファイルインクルードの許可が危険な理由
- この問題を解決するためのテクニック。
攻撃者はどのようにしてリモートファイルインクルージョンを利用するのか？
リモートファイルインクルードの脆弱性は、ほとんどのプログラミングフレームワークに存在する「ダイナミックファイルインクルード」コマンドまたはメカニズムを利用しています。この機能は、開発者がセカンダリ・サーバ上にあるファイルを使用して、アプリケーション・サーバ上でアクティビティを実行できるようにすることを目的としています。明らかに、これは悪用されると危険です。
攻撃者がこの機能を利用するには、HTTPヘッダーや対話型フォームの入力エリアなど、ユーザーの無制限な入力を許可しているウェブサイトやアプリケーションを見つけることが必要です。これは、HTTPヘッダーや対話型フォームの入力エリアなどで、ファイルインクルードコマンドを生成するための出発点として使用されます。
例えば、サイトがページの読み込みに GET 関数を使用している場合、page = request.getParameter("page"); include page; のように、攻撃者は page コマンドを使用して、自分がコントロールするサイトの URL と実行したいファイルのファイルパスを指定して、クエリを送信することができます。このクエリがサーバーに渡され、リモートファイルがホスト上で実行されます。この活動は、信頼されたアプリの一部であるため、許可されます。
リモートファイルインクルージョンはなぜ危険なのか？
リモートファイルインクルードの危険度は極めて高い。ローカルファイルインクルードの脆弱性では、攻撃者が実行するファイルがホスト上に存在し、かつ攻撃者が試行錯誤して見つけなければなりませんが、リモートファイルインクルードではそのような制限はありません。明らかに、攻撃者は悪用したいファイルの場所を知っています。なぜなら、それらは自分のマシンや自分が管理するサイトに存在する可能性が高いからです。また、ファイルは攻撃者が手動で選択することができ、悪用する前にターゲットマシン上に存在する必要はありません。このファイルは、リモートホストを悪用するために特別に書かれたスクリプトで構成されていることもあります。
要するに、ひとたび攻撃者がリモート・ファイル・インクルージョンの脆弱性を発見し、それを利用することができれば、アプリケーションやサイト全体を完全にコントロールすることが可能になります。確かに、そこに保存されているデータは、彼らの侵入から安全ではありません。
リモートファイルインクルージョンの脆弱性の除去
ユーザーの入力をファイル取り込みコマンドに直接渡して実行させてはいけません。代わりに、コマンドの間接参照マップを使用し、そこからのみコマンドを実行します。間接参照マップは、信頼できないユーザーの入力を、サーバー上でハードコードされた信頼できる値のセットにマッピングします。ユーザーがデータを入力できる場所は必ずホワイトリストに登録し、HTTPヘッダー、フォームパラメーター、さらにはクッキーもリストに含めることを忘れないでください。そうすることで、ファイルインクルードコマンドを作成しようとする攻撃者が利用できるウィンドウを閉じることができます。
さらに、ユーザーが作成したコンテンツを適切にサニタイズおよび検証し、参照マップを使用してコマンドを実行することで、リモートファイルインクルードの脆弱性だけでなく、このバグの危険な従兄弟であるローカルファイルインクルードおよびパストラバーサルのエクスプロイトを含む、その他の多くの脆弱性を潰すことができます。
リモートファイルインクルージョンの詳細情報
さらに詳しく知りたい方は、OWASPreference guidefor remote file inclusion exploitsをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威への対策について詳しくは、Secure Code Warrior ブログをご覧ください。
多くの点で、リモート・ファイル・インクルージョンの脆弱性は、ローカル・ファイル・インクルージョンの脆弱性よりもはるかに危険であり、また悪用されやすいものです。そのため、できるだけ早く発見し、対策を講じる必要があります。
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 の共同設立者です。
このブログシリーズをご覧になっている方は、今回のリモートファイル取り込みの脆弱性と、前回ご紹介したローカルファイル取り込みおよびパストラバーサルの脆弱性の間に、多くの類似点があることにお気づきになるかもしれません。これらの脆弱性の根本的な原因は、推奨される修正方法と同様に類似しています。
多くの点で、リモート・ファイル・インクルージョンの脆弱性は、ローカル・ファイル・インクルージョンの脆弱性よりもはるかに危険であり、また悪用されやすいものです。そのため、できるだけ早く発見し、対策を講じる必要があります。あるいは、より良い方法として、ウェブアプリケーションは、そもそもこの脆弱性が発生しないように設計されるべきです。
このエピソードでは、以下のことを学びます。
- リモートファイルインクルージョンの脆弱性を利用したハッカーの手口
- リモートファイルインクルードの許可が危険な理由
- この問題を解決するためのテクニック。
攻撃者はどのようにしてリモートファイルインクルージョンを利用するのか？
リモートファイルインクルードの脆弱性は、ほとんどのプログラミングフレームワークに存在する「ダイナミックファイルインクルード」コマンドまたはメカニズムを利用しています。この機能は、開発者がセカンダリ・サーバ上にあるファイルを使用して、アプリケーション・サーバ上でアクティビティを実行できるようにすることを目的としています。明らかに、これは悪用されると危険です。
攻撃者がこの機能を利用するには、HTTPヘッダーや対話型フォームの入力エリアなど、ユーザーの無制限な入力を許可しているウェブサイトやアプリケーションを見つけることが必要です。これは、HTTPヘッダーや対話型フォームの入力エリアなどで、ファイルインクルードコマンドを生成するための出発点として使用されます。
例えば、サイトがページの読み込みに GET 関数を使用している場合、page = request.getParameter("page"); include page; のように、攻撃者は page コマンドを使用して、自分がコントロールするサイトの URL と実行したいファイルのファイルパスを指定して、クエリを送信することができます。このクエリがサーバーに渡され、リモートファイルがホスト上で実行されます。この活動は、信頼されたアプリの一部であるため、許可されます。
リモートファイルインクルージョンはなぜ危険なのか？
リモートファイルインクルードの危険度は極めて高い。ローカルファイルインクルードの脆弱性では、攻撃者が実行するファイルがホスト上に存在し、かつ攻撃者が試行錯誤して見つけなければなりませんが、リモートファイルインクルードではそのような制限はありません。明らかに、攻撃者は悪用したいファイルの場所を知っています。なぜなら、それらは自分のマシンや自分が管理するサイトに存在する可能性が高いからです。また、ファイルは攻撃者が手動で選択することができ、悪用する前にターゲットマシン上に存在する必要はありません。このファイルは、リモートホストを悪用するために特別に書かれたスクリプトで構成されていることもあります。
要するに、ひとたび攻撃者がリモート・ファイル・インクルージョンの脆弱性を発見し、それを利用することができれば、アプリケーションやサイト全体を完全にコントロールすることが可能になります。確かに、そこに保存されているデータは、彼らの侵入から安全ではありません。
リモートファイルインクルージョンの脆弱性の除去
ユーザーの入力をファイル取り込みコマンドに直接渡して実行させてはいけません。代わりに、コマンドの間接参照マップを使用し、そこからのみコマンドを実行します。間接参照マップは、信頼できないユーザーの入力を、サーバー上でハードコードされた信頼できる値のセットにマッピングします。ユーザーがデータを入力できる場所は必ずホワイトリストに登録し、HTTPヘッダー、フォームパラメーター、さらにはクッキーもリストに含めることを忘れないでください。そうすることで、ファイルインクルードコマンドを作成しようとする攻撃者が利用できるウィンドウを閉じることができます。
さらに、ユーザーが作成したコンテンツを適切にサニタイズおよび検証し、参照マップを使用してコマンドを実行することで、リモートファイルインクルードの脆弱性だけでなく、このバグの危険な従兄弟であるローカルファイルインクルードおよびパストラバーサルのエクスプロイトを含む、その他の多くの脆弱性を潰すことができます。
リモートファイルインクルージョンの詳細情報
さらに詳しく知りたい方は、OWASPreference guidefor remote file inclusion exploitsをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威への対策について詳しくは、Secure Code Warrior ブログをご覧ください。
このブログシリーズをご覧になっている方は、今回のリモートファイル取り込みの脆弱性と、前回ご紹介したローカルファイル取り込みおよびパストラバーサルの脆弱性の間に、多くの類似点があることにお気づきになるかもしれません。これらの脆弱性の根本的な原因は、推奨される修正方法と同様に類似しています。
多くの点で、リモート・ファイル・インクルージョンの脆弱性は、ローカル・ファイル・インクルージョンの脆弱性よりもはるかに危険であり、また悪用されやすいものです。そのため、できるだけ早く発見し、対策を講じる必要があります。あるいは、より良い方法として、ウェブアプリケーションは、そもそもこの脆弱性が発生しないように設計されるべきです。
このエピソードでは、以下のことを学びます。
- リモートファイルインクルージョンの脆弱性を利用したハッカーの手口
- リモートファイルインクルードの許可が危険な理由
- この問題を解決するためのテクニック。
攻撃者はどのようにしてリモートファイルインクルージョンを利用するのか？
リモートファイルインクルードの脆弱性は、ほとんどのプログラミングフレームワークに存在する「ダイナミックファイルインクルード」コマンドまたはメカニズムを利用しています。この機能は、開発者がセカンダリ・サーバ上にあるファイルを使用して、アプリケーション・サーバ上でアクティビティを実行できるようにすることを目的としています。明らかに、これは悪用されると危険です。
攻撃者がこの機能を利用するには、HTTPヘッダーや対話型フォームの入力エリアなど、ユーザーの無制限な入力を許可しているウェブサイトやアプリケーションを見つけることが必要です。これは、HTTPヘッダーや対話型フォームの入力エリアなどで、ファイルインクルードコマンドを生成するための出発点として使用されます。
例えば、サイトがページの読み込みに GET 関数を使用している場合、page = request.getParameter("page"); include page; のように、攻撃者は page コマンドを使用して、自分がコントロールするサイトの URL と実行したいファイルのファイルパスを指定して、クエリを送信することができます。このクエリがサーバーに渡され、リモートファイルがホスト上で実行されます。この活動は、信頼されたアプリの一部であるため、許可されます。
リモートファイルインクルージョンはなぜ危険なのか？
リモートファイルインクルードの危険度は極めて高い。ローカルファイルインクルードの脆弱性では、攻撃者が実行するファイルがホスト上に存在し、かつ攻撃者が試行錯誤して見つけなければなりませんが、リモートファイルインクルードではそのような制限はありません。明らかに、攻撃者は悪用したいファイルの場所を知っています。なぜなら、それらは自分のマシンや自分が管理するサイトに存在する可能性が高いからです。また、ファイルは攻撃者が手動で選択することができ、悪用する前にターゲットマシン上に存在する必要はありません。このファイルは、リモートホストを悪用するために特別に書かれたスクリプトで構成されていることもあります。
要するに、ひとたび攻撃者がリモート・ファイル・インクルージョンの脆弱性を発見し、それを利用することができれば、アプリケーションやサイト全体を完全にコントロールすることが可能になります。確かに、そこに保存されているデータは、彼らの侵入から安全ではありません。
リモートファイルインクルージョンの脆弱性の除去
ユーザーの入力をファイル取り込みコマンドに直接渡して実行させてはいけません。代わりに、コマンドの間接参照マップを使用し、そこからのみコマンドを実行します。間接参照マップは、信頼できないユーザーの入力を、サーバー上でハードコードされた信頼できる値のセットにマッピングします。ユーザーがデータを入力できる場所は必ずホワイトリストに登録し、HTTPヘッダー、フォームパラメーター、さらにはクッキーもリストに含めることを忘れないでください。そうすることで、ファイルインクルードコマンドを作成しようとする攻撃者が利用できるウィンドウを閉じることができます。
さらに、ユーザーが作成したコンテンツを適切にサニタイズおよび検証し、参照マップを使用してコマンドを実行することで、リモートファイルインクルードの脆弱性だけでなく、このバグの危険な従兄弟であるローカルファイルインクルードおよびパストラバーサルのエクスプロイトを含む、その他の多くの脆弱性を潰すことができます。
リモートファイルインクルージョンの詳細情報
さらに詳しく知りたい方は、OWASPreference guidefor remote file inclusion exploitsをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威への対策について詳しくは、Secure Code Warrior ブログをご覧ください。
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
このブログシリーズをご覧になっている方は、今回のリモートファイル取り込みの脆弱性と、前回ご紹介したローカルファイル取り込みおよびパストラバーサルの脆弱性の間に、多くの類似点があることにお気づきになるかもしれません。これらの脆弱性の根本的な原因は、推奨される修正方法と同様に類似しています。
多くの点で、リモート・ファイル・インクルージョンの脆弱性は、ローカル・ファイル・インクルージョンの脆弱性よりもはるかに危険であり、また悪用されやすいものです。そのため、できるだけ早く発見し、対策を講じる必要があります。あるいは、より良い方法として、ウェブアプリケーションは、そもそもこの脆弱性が発生しないように設計されるべきです。
このエピソードでは、以下のことを学びます。
- リモートファイルインクルージョンの脆弱性を利用したハッカーの手口
- リモートファイルインクルードの許可が危険な理由
- この問題を解決するためのテクニック。
攻撃者はどのようにしてリモートファイルインクルージョンを利用するのか？
リモートファイルインクルードの脆弱性は、ほとんどのプログラミングフレームワークに存在する「ダイナミックファイルインクルード」コマンドまたはメカニズムを利用しています。この機能は、開発者がセカンダリ・サーバ上にあるファイルを使用して、アプリケーション・サーバ上でアクティビティを実行できるようにすることを目的としています。明らかに、これは悪用されると危険です。
攻撃者がこの機能を利用するには、HTTPヘッダーや対話型フォームの入力エリアなど、ユーザーの無制限な入力を許可しているウェブサイトやアプリケーションを見つけることが必要です。これは、HTTPヘッダーや対話型フォームの入力エリアなどで、ファイルインクルードコマンドを生成するための出発点として使用されます。
例えば、サイトがページの読み込みに GET 関数を使用している場合、page = request.getParameter("page"); include page; のように、攻撃者は page コマンドを使用して、自分がコントロールするサイトの URL と実行したいファイルのファイルパスを指定して、クエリを送信することができます。このクエリがサーバーに渡され、リモートファイルがホスト上で実行されます。この活動は、信頼されたアプリの一部であるため、許可されます。
リモートファイルインクルージョンはなぜ危険なのか？
リモートファイルインクルードの危険度は極めて高い。ローカルファイルインクルードの脆弱性では、攻撃者が実行するファイルがホスト上に存在し、かつ攻撃者が試行錯誤して見つけなければなりませんが、リモートファイルインクルードではそのような制限はありません。明らかに、攻撃者は悪用したいファイルの場所を知っています。なぜなら、それらは自分のマシンや自分が管理するサイトに存在する可能性が高いからです。また、ファイルは攻撃者が手動で選択することができ、悪用する前にターゲットマシン上に存在する必要はありません。このファイルは、リモートホストを悪用するために特別に書かれたスクリプトで構成されていることもあります。
要するに、ひとたび攻撃者がリモート・ファイル・インクルージョンの脆弱性を発見し、それを利用することができれば、アプリケーションやサイト全体を完全にコントロールすることが可能になります。確かに、そこに保存されているデータは、彼らの侵入から安全ではありません。
リモートファイルインクルージョンの脆弱性の除去
ユーザーの入力をファイル取り込みコマンドに直接渡して実行させてはいけません。代わりに、コマンドの間接参照マップを使用し、そこからのみコマンドを実行します。間接参照マップは、信頼できないユーザーの入力を、サーバー上でハードコードされた信頼できる値のセットにマッピングします。ユーザーがデータを入力できる場所は必ずホワイトリストに登録し、HTTPヘッダー、フォームパラメーター、さらにはクッキーもリストに含めることを忘れないでください。そうすることで、ファイルインクルードコマンドを作成しようとする攻撃者が利用できるウィンドウを閉じることができます。
さらに、ユーザーが作成したコンテンツを適切にサニタイズおよび検証し、参照マップを使用してコマンドを実行することで、リモートファイルインクルードの脆弱性だけでなく、このバグの危険な従兄弟であるローカルファイルインクルードおよびパストラバーサルのエクスプロイトを含む、その他の多くの脆弱性を潰すことができます。
リモートファイルインクルージョンの詳細情報
さらに詳しく知りたい方は、OWASPreference guidefor remote file inclusion exploitsをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成する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運動の背後にある現実を明らかにしました。セキュア・バイ・デザインは、セキュリティ・チーム全体で共有された野心ですが、共有されたプレイブックはありません。
