作成日

3 March 2008

この記事では、AIRセキュリティモデルの概要を紹介するとともに、このモデルの基となる考え方について解説します。

メモ:ユーザとアプリケーションデベロッパーの保護を目的としたAdobe AIRのセキュリティ規則およびコントロール群について詳しくは、Adobe AIR 1.0 セキュリティホワイトペーパーを参照してください。

Adobe AIRとデスクトップ

Adobe AIRを利用すれば、すでにデベロッパーが身につけたHTML、Ajax、FlashまたはFlexのWeb開発スキルを生かしながら、デスクトップアプリケーションを開発・デプロイすることができます。ここでは、たとえWebテクノロジをベースにしているとはいえ、あくまでデスクトップアプリケーションの開発であるという点に注意が必要です。つまり、AIRの主なセキュリティモデルは、Webアプリケーションではなくデスクトップアプリケーションを前提としたものである必要があります。

デスクトップアプリケーションには、その独特の特徴がいくつかあります。たとえば、デスクトップアプリケーションはユーザによって特定のパソコンにインストールされるものであることから、不特定多数を対象とした、任意のWebコンテンツとは異なる次元の信頼性が暗黙に了解されています。このため、一般的には同様のWebアプリケーションより多くの権限が付与されます。しかしこの一方で、デスクトップアプリケーションが提供する各種権限を使用するにあたっては、一層入念な注意が必要となります。これは、Webアプリケーションでは一般的であっても、デスクトップアプリケーションでは考えられないようなコード記述テクニックやパターン仕様があるからです。

AIRのサンドボックス

AIRアプリケーションは、FlashおよびHTML/Ajaxの組み合わせを利用して開発できます。 また、ドキュメントのレンダリング時にはPDFを利用することも可能です(ただし、PDFファイルのみをAIRアプリケーションのベースにすることはできません)。

アプリケーションが主にFlash、HTMLのどちらをベースに開発されているかを問わず、AIRアプリケーションには、すべて共通の特徴があります。各AIRアプリケーションには、通常、ブラウザ内で実行されるWebアプリケーションからは利用できないAIR独自のAPI群が用意されており、これらを利用することでローカルシステムやネットワークリソースへのアクセスが可能になります。また、個々のAIRアプリケーションには、読み込まれるコンテンツの種類と用途に応じた複数のサンドボックスが含まれています。

  • アプリケーションサンドボックス:各AIRアプリケーションのルートにあたります。このサンドボックスでは、特権的なAIR独自のシステムAPIへのアクセスが許可されます。この強力なAPIへのアクセスが提供されるのと引き替えに、一般的ではあるものの、危険性の高いAPIや開発手法については、その利用が制限されます。たとえば、リモートコンテンツをダイナミックに読み込むことが一般的に禁止されているとともに、ダイナミックにコードを生成するテクニックの使用が厳しく制限されています。アプリケーションサンドボックスには、アプリケーションのホームディレクトリから(app:/ URIスキームを介して)ダイレクトに読み込まれたコンテンツのみを配置することができます。
  • 非アプリケーションサンドボックス:アプリケーションサンドボックスへダイレクトに読み込まれるコンテンツ以外は、すべて非アプリケーションサンドボックスに配置されます。この中には、ローカルコンテンツとリモートコンテンツの両方が含まれます。このサンドボックスに配置されたコンテンツには、AIR APIへのダイレクトなアクセスが提供されません。また、同様の場所からブラウザへと読み込ませる場合と同じ規則を遵守することが求められます。(つまり、ローカルのSWFファイルは、ブラウザでローカルSWFファイルを扱うのと同じように機能し、リモートドメインから取得したHTMLは、ブラウザでこのHTMLを扱うのと同じように機能します。)

AIRのサンドボックスについて詳しくは、HTMLおよびAjaxを使用したAdobe AIRアプリケーション開発のサンドボックスの節を参照してください。

セキュリティ面でのデスクトップアプリケーションとWebアプリケーションの違い

Webアプリケーションで一般化した設計・実装手法でも、AIRアプリケーションサンドボックスが許可するローカルシステムへのアクセスと組み合わせるには危険すぎるものがあります。デスクトップアプリケーションの場合、ユーザがアプリケーションをダウンロードし、インストール・実行する行為によって、ユーザは(明確に認識されていないケースがあるものの)当該アプリケーションにシステムへのアクセスを許可します。つまり理論上は、インストールおよび初めての起動に先だって、ユーザには当該アプリケーションを検証・承認する機会が与えられているのです。

また、仕組み上、リモートサーバから読み込んだコードを実行したり、黙示的かつダイナミックに追加コンポーネントをインストールして、アプリケーションの機能性を拡張することは制限されています。 たとえば、デスクトップ開発の基本事項として、インストール済みのアプリケーションにアップデートやプラグイン、他の拡張機能などをダウンロード・インストールする際には、ユーザにその旨を通知することが慣習化されています。このような処理が自動的に行われているかのように見えるアプリケーションでも、何らかの形でユーザへの通知が行われているとともに、自動アップデートを無効化するための設定オプションが用意されています。ユーザの同意を得ずに処理を行うアプリケーションは、プライバシーの侵害にとどまらず、セキュリティ上の脆弱性があるアプリケーションとも捉えられる恐れがあります。このような事情からも、アプリケーションサンドボックスでは、リモートコンテンツからの実行スクリプトの読み込みが禁じられています。

次のようなケースを考えてみてください。仮に、今日の株価チャートを表示するために、あるいは最新のアプリケーション機能を提供するために、デスクトップアプリケーションがその都度、Webサイトからスクリプトを自動的に読み込むとしたらどうなるのでしょうか。 この場合、サーバに不法なアクセスがあったり、コードの読み込みが毎回入念に処理されていない場合(つまり、当該スクリプトの証明書に署名し、その署名の有効性を検証するようにしていない場合)は、スクリプトがホスティングされたサーバに攻撃者が侵入するだけで、当該アプリケーションを実行するすべてのマシンが制御できるようになってしまいます。つまり、ユーザがアプリケーションをインストールすることによって、そのアプリケーションに追加コードのダウンロード・実行が自動的に許可されるのではありません。このようなケースでは、ユーザの意図的な同意を追加で得る必要があります。

もう1つの検討事項としては、アプリケーションが外部コードやスクリプトの読み込みを指示していないにもかかわらず、デベロッパーの意図に反して、リモートスクリプトの混入(クロスサイトスクリプティング脆弱性またはXSSとして知られています)を許してしまうケースが挙げられます。 この問題が生じる一般例としては、JavaScriptのeval()関数を使用するケースがあります。eval()関数はテンプレートと、リモートドメインから読み込まれ得るデータを組み合わせて、コードを生成するために用いられることがよくあります。あらゆる形のコード混入を想定して、デベロッパーが読み込まれたデータを非常に入念に除去しない限り、アプリケーションサンドボックス内でeval()が実行されると、悪質なコードを含むデータによってユーザシステムが攻撃対象となる恐れがあります。 このような理由からも、実行時のコード生成のためにアプリケーションサンドボックス内でeval()および同様のAPIを使用することは禁じられています。

最後の注意事項は、AIR独自のAPIにおいてリモートデータを使用するケースです。このケースでは、極度の注意が必要とされます。仮にリモートサーバが、アプリケーションによってダウンロードされるファイルのファイル名とその中身を提供できるのであれば、当該ファイルは、ファイルシステムの機密部分にも書き込めることとなり、この結果、悪質なルートキットがインストールされるような事態も否定できません。やや強引な結論だと感じられる読者もおられるかと思いますが、この誤りは、たとえデベロッパーが十分注意していたとしても陥りやすい、よくある問題の1つとして挙げられます。仮に、ユーザがリモートサーバ上の写真を閲覧・保存できるようなアプリケーションを開発したとしましょう。この場合、アプリケーションのどこかで、以下に示すような関数を使用することが想定されます。

savePhoto(var filename, var content);

また、もう一歩踏み込んで(たとえば)ルートディレクトリの指定を行っていたともします。 C:\Photos— これをファイル名の変数の冒頭に付け加えていたとします。次のようなデータがリモートサーバによって提供されたケースを想像してみてください。

filename = "sailboat.jpg" content = <contents of an actual JPEG>

コードの冒頭には C:\Photosが追加され、この結果が次のようになります。

filename = "C:\Photos\sailboat.jpg"

一見、問題がないように見えますが、仮にリモートサーバが次のようなデータを提供するとしたら、どうでしょう。

filename = "..\Windows\notepad.exe" content = <contents of an EXE rootkit>

ファイル名にルートディレクトを付け加えると、次のような体裁になります。

Filename = "C:\Photos\..\Windows\notepad.exe"

In this case, the Notepad application of the Windows directory is overwritten, this result, when the user then you try to start Notepad, it will be root kit is executed. Here, we discussed taking a simple example, but such errors, or may commit matter how easy I think I was able to understand you.

 

HTML security considerations

AIR security model of HTML application sandbox is very different from that which is provided to the browser. The reason for this is that, in a generalized design and implementation techniques in the development of HTML Web applications, because there is too dangerous to combine with access to the local system to allow the application sandbox of AIR.

For example, read the script from the remote, eval()approach a dynamic script generation through, such as the code input to the innerHTML and outerHTML DOM element, even though its use is dangerous and has been widely adopted in the HTML application. However, just because already popular, does not mean these techniques are allowed in the application sandbox of AIR. Or read the script on the application sandbox, if you try to generate a dynamic to code, you will notice that there are a variety of constraints. If the implementation of these execution technique with the danger inevitable, you will need to use the (later of commentary) non-application sandbox.

The HTML security model, there are some amazing features. For example, as a wide most applicable range of security sandbox, there is a whole frame (frame, iframe and window). In other words, in this case, all of the code in the frame will belong to the same sandbox, regardless of whether the code has been read to how to frame, all will be the same privilege is granted. Browser (and AIR) is a code that is located from the original on the page, eval()is generated by the function, you will not be able to distinguish between code that is read from the page out. Therefore, to safely handle than a trusted content it how to place the content into separate frames or sandbox is the only action.

For more information, section of HTML security of AIR application development using HTML and Ajax, as well as HTML security FAQ Please refer to.

Exchanges between different sandboxes

Since the dynamic coding and scripting read is limited, the application sandbox typical browser sandbox significantly less risk of even codes mixed attack as compared to the most secure when commonly arranged application code it says that it is a sand box. However, in some cases, the developers application, there is also inevitable cases the use of these dangerous techniques. For example, a case that must communicate with a Web service that supports only JavaScript API for JSON non-compliant is around to this.

Recommended techniques in such a case, do with the danger to create a non-application sandbox, and is a technique to make this sandbox and interact through the SandboxBridge API. SandboxBridge is usually to enable communication between between the sandbox domain not to trust each other, is the serialization API of interactive.

Application extensions such as plug-ins, it is best to implement through this SandboxBridge. From the consent of the user, the plug-in position of the non-application ( app-storage:stored in, and so on), you can load it to the non-application sandbox. By exposing the plug-in API that appropriate definition has been carried out (as in the NPAPI features to the browser plug-in), without reading the plug-in to the application sandbox, plug-in itself was developed, of course, readers both plug-ins were developed by a third party for use of the application will be able to communicate securely. Plug-in API appropriate definition is made not only from the viewpoint of security, when future updates of the application, since there is also the effect of reducing the risk of plug is damaged, and solutions having more excellent stability Although you.

SandboxBridge, please so as to note that not prepared the function of "safety". The code in the application sandbox through the SandboxBridge, care must be taken to avoid such a situation that exposes the API is not safe call by any of the remote code. Therefore, the system API and critical application API, it is important that you do not publish directly through the SandboxBridge.

However, eval()it is possible to publish to the application sandbox functions from non-application sandbox. This was published eval()because code that is evaluated in the function is executed in the context of non-application sandbox. In this case, confidential specific API and access to application data is not allowed (if it is already published these for the non-application sandbox, this does not apply). As a general rule, while public functions and data from the non-application sandbox to the application sandbox is allowed, public functions and data from the application sandbox to a non-application sandbox, understanding and accompanied by danger can. Therefore, when using certain non-application sandbox, with avoid utilizing for what unreliable, possible not to provide confidential data and API for these dangerous techniques It is important.

For more information about the use of SandboxBridge, please refer to the safe handling section of the unreliable content of the Adobe AIR application development using HTML and Ajax.

Installing the AIR application

Normally, AIR applications are installed in the following two ways.

  • Using the seamless install badge function, installed via a Web browser.
  • Copy the installer file of the .air application to the local computer, install open this file.

In either case, the user experience is provided during the installation of the AIR application is almost the same. Speaking of the only differences worth noting, if the application is signed with generally accepted commercial code-signing certificate, only one of the differences have been signed with the free self-signed certificate.

In either case, the download of the .air file at the time of the installation procedure will occur. .air file can include HTML, SWF, JavaScript, and other types of files, not just a variant of the ZIP file. Therefore, it is possible to verify the files that most are extracted at the time of .air file itself or during the installation procedures and execution, of existing security tools.

For a practical example of the seamless install badge features, please refer to the AIR sample application of AIR Developer Center.

Signature of the AIR application

All AIR applications must be signed by a code-signing certificate. There are two types of certificates, one is what is called a self-signed certificate, and the other one is a commercial code-signing certificate that can be purchased from major certification authority (CA). In the case of a self-signed certificate, in the (user intentionally as long as you do not want to register as the certificate can be trusted) general users of the machine environment, not to be construed as those whose reliability was observed.

Here, it is recommended that you obtain a commercial code-signing certificate. Commercial code-signing certificates are recognized by the AIR installer on almost all of the user's machine. This method will be able to recognize the issuer name by taking, for the user, you will be able to provide a more smooth installation experience.

For more information about code signing AIR applications, of LiveDoc Adobe API application development using Flex 3 Adobe , and the separate articles of the Todd Prekaski Mr. writing, digital signature of the Adobe AIR application please refer to.

Summary

Precisely because a desktop application runtime, security model of AIR is very different from that of the Web browser. AIR application sandbox of while providing direct access to the system API, are some of the restrictions and prohibitions for the API has been provided. Among them, non-application-based content within the application sandbox ( app:/For reading and code of the dynamic generation of those that are not loaded via), has severe constraints are imposed.

In the majority of cases, you can use without editing the framework and existing code, or simply by editing some in the application sandbox. However, some of the developers, it might not be able to avoid the operation with at-risk (such as loading remote JavaScript). In this case, perform the operation in a non-application sandbox, then through the SandboxBridge API, so that you publish to the application sandbox with caution the results of the code and data.

Precisely because it pure desktop application, various privileges are given to developers. For this reason, it may be it is not impossible to find a workaround that was introduced restrictions in this article. However, if you implement the workaround that I found in this way, with respect to the application and the end-user, new, I would say that can not be avoided that would provide a significant security risk. For this reason, Adobe, for the developers, along with the highly recommended that you adhere to the restrictions provided in the security model of AIR, when the introduction of its own workaround, required to implement sufficient security measures for even such expense and effort, it is recommended that overlapping carefully studied. If the cost to develop these security measures, while protecting the security model of the provisions, from expensive to find other alternative solutions, most cases to be significantly more expensive.