アプリケーションセキュリティ

Firefox OS に導入した主要な Web アプリのセキュリティ制御は以下のとおりです:

• Web アプリはブラウザ内で不用意にナビゲートされるのではなく、明示的にインストールおよび起動されます。アプリは使用する前にインストールしなければならず、またセキュリティコントロールはユーザを保護するために、アプリの更新や削除を管理します。
• 新たな Web API へのアクセスは許可設定システムによって制御され、アプリはインストール前に、そのシステムに対して使用するつもりである許可設定を宣言しなければなりません。より強力な API へのアクセスを得るためには、アプリが一定の要件を満たし、また Marketplace によってレビューを受け、承認され、さらに署名されなければなりません。
• Web アプリはサンドボックス化されますので、自身のリソース (Cookie、オフラインストレージ、IndexedDB データベースなど) だけを見ることができます。2 つのアプリが同一 URL のページを読み込んだとしても、それら 2 つのページは別々のアプリ内で実行しているため、同一生成元であるとは判断されません。

アプリの種類

Firefox OS は 3 種類の Web アプリをサポートします: "web"、"特権 (privileged)"、内部 (internal) ("(認定 (certified))") です。アプリの種類はマニフェストで宣言され、また要求してよい許可設定の一覧が決まります。

• Web アプリ: ほとんどのサードパーティーアプリは "web" アプリになるでしょう。これは既定の種類であり、すでに Web 向けに公開されているものを上回る許可設定は承諾されません。Web アプリはどの Web サイトからでも、付加的な検証なしにインストールできます。パッケージ型アプリにすることもできますが、追加の許可設定はまったく認められません。
• 特権アプリ: これらのアプリは高い許可設定を要求でき、また特権アプリとしての検証や署名を Marketplace から受けなければなりません。
• 内部/認定アプリ: 認定アプリは現在、デバイスへのプリインストールのみ可能です。

アプリの提供

Firefox OS で、アプリは 2 種類の仕組みで提供されます: ホスト型 または パッケージ型 です。通常の Web アプリはどちらの仕組みでも提供できるのに対して、特権アプリと認定アプリはパッケージ型であることが必要です。

ホスト型アプリ

ホスト型アプリは、開発者の Web サーバに置かれたアプリケーションマニフェストだけで構成されます。マニフェストには、アプリを起動したときにどのページを表示するかを示す launch_path が含まれています。セキュリティの視点から、ホスト型アプリは通常の Web サイトにとてもよく似た動作になります。ホスト型アプリで読み込まれたページの URL は、Web サーバ上にある当該ページ、あるいは以前に appcache へ保存されている場合はデバイスから読み込まれたページが持つ、通常の URL になります。

パッケージ型アプリ

パッケージ型アプリは Web サーバ上にリソースを持つ代わりに、すべてのリソース (HTML、CSS、JavaScript、アプリマニフェストなど) を zip ファイルに収めた Open Web App です。この形式について詳しくは、 パッケージ型アプリをご覧ください。

アプリの生成元

ホスト型アプリではアプリの生成元が、アプリケーションマニフェストを置いている場所の生成元になります。

パッケージ型アプリの生成元はインストール時に割り当てられ、アプリケーションごとに固有です。特権アプリと内部アプリはアプリケーションマニフェストの origin パラメータを指定することで、特定の生成元を要求できます。

アプリのインストール

アプリは Apps JavaScript API を通してインストールします:

• ホスト型アプリ: ホスト型アプリは navigator.mozApps.install(manifestURL) を呼び出してインストールします。ここで manifestURL は、アプリの場所を示す URL です。詳しくは Installing Apps をご覧ください。
• パッケージ型アプリ: パッケージ型アプリは navigator.mozApps.installPackage(packageURL) を呼び出してインストールします。パッケージ型アプリではメインのアプリケーションマニフェストがパッケージ自体の中に保管されていますので、それは署名されています。インストールプロセスを開始するために使用する、第 2 の "ミニマニフェスト (mini-manifest)" があります。詳しくは Installing Packaged Apps および パッケージ型アプリをご覧ください。

アプリが実際に Web アプリとしてインストールされるよう望んでいることを保証するため、Web サイトがアプリケーションマニフェストを偽ることができないようにしなければなりません。これは、マニフェストを特定の MIME タイプ application/x-web-app-manifest+json での提供するよう求めることで実現します。この制限はマニフェストが示すアプリとアプリのマニフェストが、アプリのインストールを要求したページと同一生成元であるときに緩和されます。

更新

アプリの更新プロセスは、アプリの更新で説明しています。

許可設定

アプリは、通常の Web サイトに許可されているものより上位の追加権限を許可されることができます。デフォルトで、アプリは通常の Web ページと同じ許可設定を持ちます。追加の許可設定を得るための最初のステップは、アプリで希望する追加設定をアプリケーションマニフェストに列挙することです。

マニフェストでの宣言

アプリが必要とするそれぞれの追加許可設定のためマニフェスト内に許可設定を、なぜアプリがそれを必要かについて人間が読める説明を伴って列挙しなければなりません。例えばアプリが navigator.geolocation API を使用したい場合は、マニフェストに以下の内容を含めなければなりません:

"permissions": {
  "geolocation":{ 
    "description": "Required for autocompletion in the share screen",  
  }
},

これは Web ページが通常行うのと同じ方法で、アプリが geolocation について問い合わせることを可能にします。マニフェストについて詳しくは、アプリマニフェストをご覧ください。

許可設定の承諾

マニフェストで許可設定を要求しているとき、その許可設定は allow または prompt に設定されます。allow 型の許可設定はマニフェストで宣言されていることにより、さらなる同意なしに承諾されます。prompt 型の許可設定では、ユーザは関連する API へ最初にアクセスするときに問い合わせを受け、API が承諾を受ける前に選択しなければなりません。通常、Firefox OS はプライバシーへの影響がある許可設定についてユーザに問い合わせます。これはユーザが何を質問されているかを理解する上で合理的です。例えば連絡先へのアクセスは問い合わせされますが、生の TCP コネクション作成へのアクセスは暗黙的に許可されます。これはその許可設定を許可することについて、セキュリティ面で暗示することをユーザが理解することが合理的ではないためです。allow 型の許可設定の使用は Marketplace のセキュリティレビューのプロセスの一部として、ユーザの保護を確実にするためにレビューされます。

許可設定の取り消し

ユーザは prompt の許可設定について考えを変えることができ、また Firefox OS の設定アプリでそれらの許可設定を取り消すことが可能です。しかし、ユーザは allow 型の許可設定を変更できません。

Web アプリのサンドボックス

アプリごとのデータ保管

それぞれのアプリは分離されたサンドボックス内で実行します。これは、アプリによって保存されるすべてのデータが、他のアプリによって保存されるデータから分離されることを意味します。このデータには Cookie のデータ、localStorage のデータ、indexedDB のデータ、サイトの許可設定といったデータも含まれます。

これはユーザが 2 つのアプリ A と B をインストールしている場合に、それらのアプリは完全に別の Cookie、別のローカルデータ、別の許可設定を持つことを意味します。また、両方のアプリが同一の生成元を指す <iframe> を開いた場合でも適用されます。すなわち、アプリ A とアプリ B の両方が "https://www.mozilla.org" を指す <iframe> を開いた場合、両方のアプリが Web サイトを表示しますが、その Web サイトは 2 つのアプリで別々の Cookie を使用して読み込みおよび表示されます。

その結果、例えばユーザがアプリ A を使用して Facebook にログインしても、アプリ B がユーザの Facebook アカウントと対話できるように作用することはありません。ユーザがアプリ A でログインしたときに設定される Facebook のログイン Cookie は、アプリ A だけで使用可能です。アプリ B が Facebook を <iframe> で開いても Cookie がありませんので、ユーザのアカウントページではなく Facebook のログインページを受け取ります。

アプリはお互いを開くことができない

これは、アプリが iframe を使用して他のアプリを開くことができないという意味です。アプリ A が、アプリ B の URL を src に設定した <iframe> を作成した場合でも、実際はアプリ B を <iframe> で開いていません。単に、URL の場所にある Web サイトを開いているだけです。アプリ B の Cookie は使用しませんので、アプリ B がユーザのデバイスにインストールされていない場合と変わらない動作になります。

これはパッケージ型アプリにも適用します (詳しくは後述します)。アプリ A がパッケージ型アプリ B を、アプリ B の app:// URL を指す <iframe> を使用して開こうとしても、読み込みは失敗します。この結果が 404 あるいはまだ決まっていない他の種類のエラーになるとしても、読み込みは確実に失敗します。また、アプリ B がインストールされているかをアプリ A が判別できないようにするため、アプリ B がユーザのデバイスにインストールされていてもいなくても同じように失敗します。

アプリ A のトップレベルフレームでアプリ B の URL へナビゲートする場合も同じことが発生します。常にアプリを開いているフレームを把握するようにしていますので、アプリ A のフレームでアプリ B の URL を読み込もうとしたときに、これまで説明した 2 つの状況と同じ動作になります。つまり、Cookie や他のローカルデータなどアプリ B のリソースを使用する方法はありません。

動機

サンドボックスの手法には、利点と欠点の両方があります。欠点は、ユーザが複数のアプリで同じ Web サイトと対話する場合に、すべてのアプリでログインを行わなければならないことです。同様に、ローカルへのデータ保管を希望する Web サイトとユーザが複数のアプリで対話する場合に、それぞれのアプリでデータが重複することになり、データが大量である場合に問題が発生する可能性があります。

サンドボックスの手法の主な利点は、より安定的なモデルであるということです。アプリをインストールすることで別のアプリが動作しなくなるといった、複数のアプリが第三者の Web サイトを通して予期せぬ方法で互いに対話できる方法はありません。またアプリをアンインストールするときに、別のアプリ用のデータを削除できる方法や、アンインストールするアプリへの機能的な依存により別のアプリが動作しなくなることもありません。

セキュリティの大きな利点もあります。ユーザは、SketchGame アプリが Facebook の Web サイトにあるバグや問題点を悪用してユーザの Facebook データを狙う攻撃を始めるかもしれないと悩む必要なしに、Facebook へログインする AwesomeSocial アプリを安全に使用できます。

また、プライバシーについても利点があります。ユーザは PoliticalPartyPlus アプリを、MegaCorpEmployeeApp アプリがそのアプリがインストールされたことやどのようなデータが作成されたかを検出できるのではと悩む必要なしに、安全にインストールできます。

許可設定のサンドボックス化

Web サイトのデータがアプリごとにサンドボックス化されるのと同様に、許可設定の承諾もサンドボックス化されます。アプリ A が https://maps.google.com からページを読み込んで、そのページが Geolocation の使用を求めたとします。ユーザが "はい、また常時この決定を記憶してください" とした場合、https://maps.google.com はアプリ A で Geolocation にアクセスできることだけを意味します。次にアプリ B が https://maps.google.com を開いても、そのページはユーザが再び許可設定を承諾しない限り Geolocation にアクセスできません。

また通常のブラウザと同様に、許可設定は生成元ごとに分けられます。アプリ A が Geolocation 使用の許可設定を承諾された場合、これはアプリ A で実行するすべての生成元が Geolocation 使用の許可を得たということではありません。アプリ A が https://maps.google.com を指す <iframe> を開いていても、https://docs.google.com は Geolocation へのアクセスを承諾される前に、ユーザへ許可設定について問い合わせなければなりません。

ブラウザ API サンドボックス

ブラウザのように多数の URL を開くアプリケーションをより安全にするため、browserContent フラグを追加しました。browserContent フラグは各アプリにサンドボックスを 1 つではなく 2 つ設けることを可能にします。ひとつはアプリ自身用、もうひとつはアプリが開く "web コンテンツ" 用です。例えば:

MyBrowser アプリが https://mybrowser.com ドメインから読み込まれるとします。このドメインは、内部でスクリプトやリソースを読み込みます。スクリプトやリソースはこのドメインに属しています。

ここでアプリ内のページが <iframe mozbrowser> を作成すると、その <iframe> で使用する別のサンドボックスが作成されます。このサンドボックスは、アプリで使用するサンドボックスとは異なります。すなわち、その <iframe> が https://mybrowser.com にナビゲートした場合、<iframe mozbrowser> 内では別の Cookie を使用することになります。同様に、<iframe mozbrowser> 内部のコンテンツはアプリが開いたものとは別の IndexedDB や localStorage のデータベースを参照します。

またこれは、MyBrowser アプリが位置に基づいたブラウジングを実装するために、例えば Google マップと連携したい場合にも適用されます。アプリが https://maps.google.com を指す <iframe> を開いた場合、そこでは https://maps.google.com の Web サイト向けの Cookie のセットを受け取ります。そしてユーザが Web コンテンツ領域内、つまり https://maps.google.com を指す <iframe mozbrowser> 内で操作したときは、トップレベルのアプリとは別の Cookie や許可設定を使用します。

この仕組みが有用な別の例として、Yelp のようなアプリがあります。Yelp は、アプリ内で直接レストランの Web サイトを訪問できます。レストランの Web サイトを開くために <iframe mozbrowser> を使用することで、Yelp のアプリは、レストランの Web サイトが逆に Yelp のアプリを指す (https://yelp.com を指す) <iframe> を含むことができないことが保証されます。それを行うと、Web サイトでは Yelp のアプリではなく Yelp の Web サイトだけを受け取るでしょう。よって、iframe 内にある Yelp の Web サイトは Yelp アプリの許可設定やデータを共有しませんので、レストランの Web サイトはアプリに対して攻撃を行える手段がありません。

アプリセキュリティのまとめ

以下の表は、さまざまな種類の Firefox OS アプリのまとめと、Firefox OS で実行する Open Web Apps の形式、インストール、更新プロセスの説明を掲載したものです。