サンドボックスによるセキュリティの保護

アプリケーションサンドボックスの主な機能は、AIR API と信頼されたディレクトリ内のファイルとの間でのやり取りを有効にすることです。 非アプリケーションサンドボックス内のコードからの分離は、最初のページの読み込みの後で JavaScript パーサを無効にして eval() などのコードが例外をスローするようにすることで維持されます。 innerHTML の設定は許可されていますが、これに含まれるスクリプトはすべて無視されます。これによって、外部で読み込まれたデータに AIR API を直接公開することなく、幅広い機能を提供します。

開発者は、 app:/ URL スキームを使用して、アプリケーションサンドボックス内の信頼されるディレクトリを参照します。 frame や iframe の場合、アプリケーションディレクトリ内のファイルでも、AIR の sandboxRoot および documentRoot 属性を使用して frame や iframe に読み込まれると、非アプリケーションサンドボックスに配置されることがあります。AIR インストーラーに含まれるすべてのファイルは自動的に app:/ にインストールされるので、アプリケーションサンドボックスの一部になります。 アプリケーションを実行すると、これらのファイルには、ローカルファイルシステムの操作を含め、AIR アプリケーションのすべての権限のセットが付与されます。 app:/ の外部のコンテンツはアプリケーションサンドボックスの一部にはならず、ブラウザー環境で処理する場合と同様に処理されます。

AIR API は、進化したブラウザーのセキュリティモデルと、デスクトップと同様のセキュリティモデルとを安全に橋渡しするために、セキュリティで保護された手段を提供します。 AIR サンドボックスブリッジモデルによって、標準的なブラウザーベースのアプリケーションに比べて、幅広い機能を、低いリスクで有効にすることができます。

非アプリケーションサンドボックスの主な機能は、開発者によって許可されている場合を除き、ローカルファイルおよび AIR API へのアクセスを制限することです。ネットワークやインターネットから読み込まれたコンテンツは、自動的にこのサンドボックスに割り当てられます。 非アプリケーションサンドボックスでは、 eval() 関数を使用したり、 innerHTML の割り当てによってコードを実行したりすることができます。非アプリケーションサンドボックス内のコードには同一生成元ポリシーが適用されるので、デフォルトでは、 XMLHTTPRequest を通じてクロスドメインデータを読み込むことはできません。ただし、非アプリケーションサンドボックス内のコードは、直接 AIR API を実行できません。

このサンドボックスのいくつかの制限によって、ブラウザーモデルとは若干動作が異なりますが、開発者はアプリケーションサンドボックスで実行されるコードを作成することをお勧めします。

最も単純な場合、ネットワークコンテンツを使用する HTML ベースの AIR アプリケーションは、ルートユーザーインターフェイス（UI）ファイル、ダウンロードしたデータやファイル、および（アプリケーションサンドボックス内の）アプリケーションファイルで構成されます。 ただし、外部コンテンツや一部のユーザーインターフェイスファイルが非アプリケーションサンドボックスで動作し、アプリケーションファイルがアプリケーションサンドボックスで動作する場合、非アプリケーションサンドボックスのコンテンツと、アプリケーションサンドボックスのコンテンツの相互作用は以下のようになります。

AIR ソリューションは サンドボックスブリッジ API であり、これによって異なるサンドボックス間での間接的な通信が有効になります。開発者は AIR API を呼び出す関数を作成し、サンドボックスブリッジでその「仲介」関数を公開できます。これらのブリッジ関数は、基本的にブリッジ上に配置され、非アプリケーションサンドボックスから呼び出されるまで待機します。

このアーキテクチャによって、2 つのゴールが達成されます。 1 つは、非アプリケーションサンドボックスのコンテンツが AIR API に直接アクセスしないので、アプリケーションコンテンツが未知数の潜在的に悪意のある外部データから保護されることです。 もう 1 つは、開発者がブリッジメカニズムを通じて公開することを明示的に選択した API のみが公開されることです。

サンドボックスブリッジはセキュリティを保証しませんが、開発者は AIR API を信頼されないコンテンツに公開する際のリスクを軽減するための鍵を握っています。 クライアントサーバーモデルと同様に、サーバーはクライアントを信頼するべきではなく、クライアントはサードパーティから読み込まれたデータを信頼するべきではありません。 同様に、開発者は、サーバーを危険にさらす可能性があり、オペレーティングシステムへのアクセスを可能にするので、サーバーでのコードの読み込みを使用したり、信頼したりしないようにする必要があります。 したがって、ブラウザーと AIR サンドボックスブリッジのいずれのクライアントサーバーモデルの場合も、 writeFile() や readFile() などの基本的なシステム API を常に攻撃から保護する必要があります。

Adobe AIR セキュリティは、Web アプリケーション開発コミュニティを念頭に置いて設計されています。 アドビ システムズ社では、セキュリティのリスクを軽減するための標準および手法をサポートしています。 さらに、OpenAjax Alliance などの組織が、次のようなベストプラクティスの公開を支援しています。

• 信頼されないコンテンツをフレームまたは iframe に分離します。同一生成元ポリシーを利用することによって、攻撃者は DOM ツリー全体にアクセスすることが困難になります。

• 異なるドメインからフレームに読み込まれたデータには、固有の JavaScript 実行コンテキストと DOM ツリーを指定します。

• コードを動的に生成および実行しないでください。

• 信頼されるソースからのものではない HTML コンテンツを挿入しないようにします。

• セキュリティで保護された JSON を使用します。

  AIR には、開発者がこれらのベストプラクティスに従い、HTML ベースのアプリケーションのセキュリティを強化できるようにするメカニズムが用意されています。 詳しくは、OpenAjax Alliance の「 Ajax and Mashup Security 」を参照してください。

  開発者は、明示的にサンドボックスの橋渡しをする必要があります。