path: root/files/ja/archive/b2g_os/security/application_security/index.html

---
title: アプリケーションセキュリティ
slug: Archive/B2G_OS/Security/Application_security
tags:
  - Apps
  - Firefox OS
  - Guide
  - Mobile
  - Security
translation_of: Archive/B2G_OS/Security/Application_security
---
<div class="summary">
 <p>本記事では、Firefox OS のアプリケーションのセキュリティモデルについて、詳しく説明します。</p>
</div>
<p>Firefox OS に導入した主要な Web アプリのセキュリティ制御は以下のとおりです:</p>
<ul>
 <li>Web アプリはブラウザ内で不用意にナビゲートされるのではなく、明示的にインストールおよび起動されます。アプリは使用する前にインストールしなければならず、またセキュリティコントロールはユーザを保護するために、アプリの更新や削除を管理します。</li>
 <li>新たな Web API へのアクセスは許可設定システムによって制御され、アプリはインストール前に、そのシステムに対して使用するつもりである許可設定を宣言しなければなりません。より強力な API へのアクセスを得るためには、アプリが一定の要件を満たし、また Marketplace によってレビューを受け、承認され、さらに署名されなければなりません。</li>
 <li>Web アプリはサンドボックス化されますので、自身のリソース (Cookie、オフラインストレージ、IndexedDB データベースなど) だけを見ることができます。2 つのアプリが同一 URL のページを読み込んだとしても、それら 2 つのページは別々のアプリ内で実行しているため、同一生成元であるとは判断されません。</li>
</ul>
<h3 id="App_Types" name="App_Types">アプリの種類</h3>
<p>Firefox OS は 3 種類の Web アプリをサポートします: "<strong>web</strong>"、"<strong>特権 (<span style="color: green;">privileged</span>)</strong>"、<strong>内部 (<span style="color: green;">internal</span>)</strong> ("<strong>(認定 (<span style="color: green;">certified</span>))</strong>") です。アプリの種類は<a href="/ja/docs/Apps/Manifest" title="Apps/Manifest">マニフェスト</a>で宣言され、また要求してよい許可設定の一覧が決まります。</p>
<ul>
 <li><strong>Web アプリ:</strong> ほとんどのサードパーティーアプリは "web" アプリになるでしょう。これは既定の種類であり、すでに Web 向けに公開されているものを上回る許可設定は承諾されません。Web アプリはどの Web サイトからでも、付加的な検証なしにインストールできます。<a href="/ja/docs/Web/Apps/Packaged_apps" title="Web/Apps/Packaged_apps">パッケージ型</a>アプリにすることもできますが、追加の許可設定はまったく認められません。</li>
 <li><strong>特権アプリ</strong>: これらのアプリは高い許可設定を要求でき、また<em>特権</em>アプリとしての検証や署名を Marketplace から受けなければなりません。</li>
 <li><strong>内部/認定アプリ: </strong>認定アプリは現在、デバイスへのプリインストールのみ可能です。</li>
</ul>
<div class="note">
 <p><strong>注記</strong>: これら 3 種類について詳しくは、<a href="/ja/docs/Apps/Manifest#type" title="Apps/Manifest#type">アプリマニフェスト</a>のドキュメントをご覧ください。</p>
</div>
<h3 id="App_Delivery" name="App_Delivery">アプリの提供</h3>
<p>Firefox OS で、アプリは 2 種類の仕組みで提供されます: ホスト型 または パッケージ型 です。通常の Web アプリはどちらの仕組みでも提供できるのに対して、特権アプリと認定アプリはパッケージ型であることが必要です。</p>
<h4 id="Hosted_apps_2" name="Hosted_apps_2"><span class="mw-headline" id="Hosted_apps">ホスト型アプリ</span></h4>
<p>ホスト型アプリは、開発者の Web サーバに置かれた<a class="external text" href="/ja/docs/Apps/Manifest" rel="nofollow">アプリケーションマニフェスト</a>だけで構成されます。マニフェストには、アプリを起動したときにどのページを表示するかを示す <a href="/ja/Apps/Manifest#launch_path">launch_path</a> が含まれています。セキュリティの視点から、ホスト型アプリは通常の Web サイトにとてもよく似た動作になります。ホスト型アプリで読み込まれたページの URL は、Web サーバ上にある当該ページ、あるいは以前に appcache へ保存されている場合はデバイスから読み込まれたページが持つ、通常の URL になります。</p>
<h4 id="Packaged_apps_2" name="Packaged_apps_2"><span class="mw-headline" id="Packaged_apps">パッケージ型アプリ</span></h4>
<p><strong>パッケージ型アプリ</strong>は Web サーバ上にリソースを持つ代わりに、すべてのリソース (HTML、CSS、JavaScript、アプリマニフェストなど) を zip ファイルに収めた Open Web App です。この形式について詳しくは、<a href="/ja/docs/Apps/Packaged_apps" title="Apps/Packaged_apps"> パッケージ型アプリ</a>をご覧ください。</p>
<h3 id="App_Origin" name="App_Origin">アプリの生成元</h3>
<p>ホスト型アプリではアプリの生成元が、<a class="external text" href="/ja/docs/Apps/Manifest" rel="nofollow">アプリケーションマニフェスト</a>を置いている場所の生成元になります。</p>
<p>パッケージ型アプリの生成元はインストール時に割り当てられ、アプリケーションごとに固有です。<a href="/ja/Apps/Publishing/Packaged_Apps#Types_of_packaged_apps">特権アプリと内部アプリ</a>はアプリケーションマニフェストの <a href="/ja/Apps/Manifest#origin">origin</a> パラメータを指定することで、特定の生成元を要求できます。</p>
<h3 id="App_Installation" name="App_Installation"><strong>アプリのインストール</strong></h3>
<p>アプリは <a href="/ja/docs/JavaScript_API" title="JavaScript_API">Apps JavaScript API</a> を通してインストールします:</p>
<ul>
 <li>ホスト型アプリ: ホスト型アプリは <code>navigator.mozApps.<a href="/ja/docs/Web/API/Apps.install" title="Web/API/Apps.install">install</a>(manifestURL)</code> を呼び出してインストールします。ここで manifestURL は、アプリの場所を示す URL です。詳しくは <a href="/ja/docs/DOM/Apps.install">Installing Apps</a> をご覧ください。</li>
 <li>パッケージ型アプリ: パッケージ型アプリは <code>navigator.mozApps.<a href="/ja/docs/Web/API/Apps.installPackage" title="Web/API/Apps.installPackage">installPackage</a>(packageURL)</code> を呼び出してインストールします。パッケージ型アプリではメインのアプリケーションマニフェストがパッケージ自体の中に保管されていますので、それは署名されています。インストールプロセスを開始するために使用する、第 2 の "ミニマニフェスト (<span style="color: green;">mini-manifest</span>)" があります。詳しくは <a href="/ja/docs/DOM/Apps.installPackage">Installing Packaged Apps</a> および <a href="/ja/docs/Apps/Packaged_apps" title="Apps/Packaged_apps">パッケージ型アプリ</a>をご覧ください。</li>
</ul>
<p>アプリが実際に Web アプリとしてインストールされるよう望んでいることを保証するため、Web サイトがアプリケーションマニフェストを偽ることができないようにしなければなりません。これは、マニフェストを特定の MIME タイプ <code>application/x-web-app-manifest+json</code> での提供するよう求めることで実現します。この制限はマニフェストが示すアプリとアプリのマニフェストが、アプリのインストールを要求したページと同一生成元であるときに緩和されます。</p>
<h3 id="Updates_2" name="Updates_2"><span class="mw-headline" id="Updates">更新</span></h3>
<p>アプリの更新プロセスは、<a href="/ja/docs/Apps/Updating_apps" title="Apps/Updating_apps">アプリの更新</a>で説明しています。</p>
<h2 id="Permissions" name="Permissions">許可設定</h2>
<p>アプリは、通常の Web サイトに許可されているものより上位の追加権限を許可されることができます。デフォルトで、アプリは通常の Web ページと同じ許可設定を持ちます。追加の許可設定を得るための最初のステップは、アプリで希望する追加設定をアプリケーションマニフェストに列挙することです。</p>
<h3 id="Manifest_Declaration" name="Manifest_Declaration">マニフェストでの宣言</h3>
<p>アプリが必要とするそれぞれの追加許可設定のためマニフェスト内に許可設定を、なぜアプリがそれを必要かについて人間が読める説明を伴って列挙しなければなりません。例えばアプリが <a href="/ja/docs/Web/API/window.navigator.geolocation" title="Web/API/window.navigator.geolocation">navigator.geolocation</a> API を使用したい場合は、マニフェストに以下の内容を含めなければなりません:</p>
<pre class="brush: html">"permissions": {
  "geolocation":{
<code class="language-js"><span class="token string">    "description"</span><span class="token punctuation">:</span> <span class="token string">"Required for autocompletion in the share screen"</span><span class="token punctuation">,</span></code>
  }
},
</pre>
<p>これは Web ページが通常行うのと同じ方法で、アプリが geolocation について問い合わせることを可能にします。マニフェストについて詳しくは、<a href="/ja/docs/Apps/Manifest" title="Apps/Manifest">アプリマニフェスト</a>をご覧ください。</p>
<div class="note">
 <p><strong>注記</strong>: 現在、許可設定を使用する意図はユーザに公開されません。<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=823385" title="https://bugzilla.mozilla.org/show_bug.cgi?id=823385">バグ 823385</a> をご覧ください。</p>
</div>
<h3 id="Granting_Permissions" name="Granting_Permissions">許可設定の承諾</h3>
<p>マニフェストで許可設定を要求しているとき、その許可設定は <em>allow</em> または <em>prompt</em> に設定されます。allow 型の許可設定はマニフェストで宣言されていることにより、さらなる同意なしに承諾されます。prompt 型の許可設定では、ユーザは関連する API へ最初にアクセスするときに問い合わせを受け、API が承諾を受ける前に選択しなければなりません。通常、Firefox OS はプライバシーへの影響がある許可設定についてユーザに問い合わせます。これはユーザが何を質問されているかを理解する上で合理的です。例えば連絡先へのアクセスは問い合わせされますが、生の TCP コネクション作成へのアクセスは暗黙的に許可されます。これはその許可設定を許可することについて、セキュリティ面で暗示することをユーザが理解することが合理的ではないためです。allow 型の許可設定の使用は Marketplace のセキュリティレビューのプロセスの一部として、ユーザの保護を確実にするためにレビューされます。</p>
<h3 id="Revoking_Permissions" name="Revoking_Permissions">許可設定の取り消し</h3>
<p>ユーザは prompt の許可設定について考えを変えることができ、また Firefox OS の設定アプリでそれらの許可設定を取り消すことが可能です。しかし、ユーザは allow 型の許可設定を変更できません。</p>
<h2 id="Web_App_Sandbox" name="Web_App_Sandbox">Web アプリのサンドボックス</h2>
<h3 id="Data_stored_per_app_2" name="Data_stored_per_app_2"><span class="mw-headline" id="Data_stored_per_app">アプリごとのデータ保管</span></h3>
<p>それぞれのアプリは分離されたサンドボックス内で実行します。これは、アプリによって保存されるすべてのデータが、他のアプリによって保存されるデータから分離されることを意味します。このデータには Cookie のデータ、localStorage のデータ、indexedDB のデータ、サイトの許可設定といったデータも含まれます。</p>
<p><img alt="A diagram showing three Firefox OS apps all open is separate sandboxes, so none of them can affect each other." src="https://mdn.mozillademos.org/files/7091/sandbox.png" style="width: 1040px; height: 437px; display: block; margin: 0px auto;"></p>
<p>これはユーザが 2 つのアプリ A と B をインストールしている場合に、それらのアプリは完全に別の Cookie、別のローカルデータ、別の許可設定を持つことを意味します。また、両方のアプリが同一の生成元を指す <a href="/ja/docs/Web/HTML/Element/iframe" title="HTML の &lt;iframe> 要素は、ブラウジングコンテキスト (browsing context) の入れ子を表現し、事実上現在のページに他の HTML ページを埋め込むことができます。HTML 4.01 では、文書は head および body、または head および frameset を持つことができ、body と frameset の両方は持ちません。しかし、&lt;iframe> は通常の文書 body 内で使用できます。ブラウジングコンテキストはそれぞれ、セッション履歴とアクティブな文書を持ちます。埋め込みコンテンツを含む側のブラウジングコンテキストを、親ブラウジングコンテキストと呼びます。トップレベルのブラウジングコンテキスト (親を持ちません) は通常ブラウザーウィンドウです。"><code>&lt;iframe&gt;</code></a> を開いた場合でも適用されます。すなわち、アプリ A とアプリ B の両方が "<a class="external free" href="http://www.mozilla.org" rel="nofollow">http://www.mozilla.org</a>" を指す <code>&lt;iframe&gt;</code> を開いた場合、両方のアプリが Web サイトを表示しますが、その Web サイトは 2 つのアプリで別々の Cookie を使用して読み込みおよび表示されます。</p>
<p>その結果、例えばユーザがアプリ A を使用して Facebook にログインしても、アプリ B がユーザの Facebook アカウントと対話できるように作用することはありません。ユーザがアプリ A でログインしたときに設定される Facebook のログイン Cookie は、アプリ A だけで使用可能です。アプリ B が Facebook を <code>&lt;iframe&gt;</code> で開いても Cookie がありませんので、ユーザのアカウントページではなく Facebook のログインページを受け取ります。</p>
<h3 id="Apps_can't_open_each_other" name="Apps_can't_open_each_other"><span class="mw-headline" id="Apps_can.27t_open_each_other">アプリはお互いを開くことができない</span></h3>
<p>これは、アプリが iframe を使用して他のアプリを開くことができないという意味です。アプリ A が、アプリ B の URL を src に設定した <code>&lt;iframe&gt;</code> を作成した場合でも、実際はアプリ B を <code>&lt;iframe&gt;</code> で開いていません。単に、URL の場所にある Web サイトを開いているだけです。アプリ B の Cookie は使用しませんので、アプリ B がユーザのデバイスにインストールされていない場合と変わらない動作になります。</p>
<p>これはパッケージ型アプリにも適用します (詳しくは後述します)。アプリ A がパッケージ型アプリ B を、アプリ B の <code>app://</code> URL を指す <code>&lt;iframe&gt;</code> を使用して開こうとしても、読み込みは失敗します。この結果が 404 あるいはまだ決まっていない他の種類のエラーになるとしても、読み込みは確実に失敗します。また、アプリ B がインストールされているかをアプリ A が判別できないようにするため、アプリ B がユーザのデバイスにインストールされていてもいなくても同じように失敗します。</p>
<p>アプリ A のトップレベルフレームでアプリ B の URL へナビゲートする場合も同じことが発生します。常にアプリを開いているフレームを把握するようにしていますので、アプリ A のフレームでアプリ B の URL を読み込もうとしたときに、これまで説明した 2 つの状況と同じ動作になります。つまり、Cookie や他のローカルデータなどアプリ B のリソースを使用する方法はありません。</p>
<h3 id="Motivation_2" name="Motivation_2"><span class="mw-headline" id="Motivation">動機</span></h3>
<p>サンドボックスの手法には、利点と欠点の両方があります。欠点は、ユーザが複数のアプリで同じ Web サイトと対話する場合に、すべてのアプリでログインを行わなければならないことです。同様に、ローカルへのデータ保管を希望する Web サイトとユーザが複数のアプリで対話する場合に、それぞれのアプリでデータが重複することになり、データが大量である場合に問題が発生する可能性があります。</p>
<p>サンドボックスの手法の主な利点は、より安定的なモデルであるということです。アプリをインストールすることで別のアプリが動作しなくなるといった、複数のアプリが第三者の Web サイトを通して予期せぬ方法で互いに対話できる方法はありません。またアプリをアンインストールするときに、別のアプリ用のデータを削除できる方法や、アンインストールするアプリへの機能的な依存により別のアプリが動作しなくなることもありません。</p>
<p>セキュリティの大きな利点もあります。ユーザは、SketchGame アプリが Facebook の Web サイトにあるバグや問題点を悪用してユーザの Facebook データを狙う攻撃を始めるかもしれないと悩む必要なしに、Facebook へログインする AwesomeSocial アプリを安全に使用できます。</p>
<p>また、プライバシーについても利点があります。ユーザは PoliticalPartyPlus アプリを、MegaCorpEmployeeApp アプリがそのアプリがインストールされたことやどのようなデータが作成されたかを検出できるのではと悩む必要なしに、安全にインストールできます。</p>
<h3 id="Sandboxed_Permissions_2" name="Sandboxed_Permissions_2"><span class="mw-headline" id="Sandboxed_Permissions">許可設定のサンドボックス化</span></h3>
<p>Web サイトのデータがアプリごとにサンドボックス化されるのと同様に、許可設定の承諾もサンドボックス化されます。アプリ A が <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a> からページを読み込んで、そのページが Geolocation の使用を求めたとします。ユーザが "はい、また常時この決定を記憶してください" とした場合、<a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a> はアプリ A で Geolocation にアクセスできることだけを意味します。次にアプリ B が <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a> を開いても、そのページはユーザが再び許可設定を承諾しない限り Geolocation にアクセスできません。</p>
<p>また通常のブラウザと同様に、許可設定は生成元ごとに分けられます。アプリ A が Geolocation 使用の許可設定を承諾された場合、これはアプリ A で実行するすべての生成元が Geolocation 使用の許可を得たということではありません。アプリ A が <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a> を指す <code>&lt;iframe&gt;</code> を開いていても、<a href="http://docs.google.com"><span class="external free">http://docs.google.com</span></a> は Geolocation へのアクセスを承諾される前に、ユーザへ許可設定について問い合わせなければなりません。</p>
<h3 id="Browser_API_Sandbox" name="Browser_API_Sandbox">ブラウザ API サンドボックス</h3>
<p>ブラウザのように多数の URL を開くアプリケーションをより安全にするため、<em>browserContent フラグ</em>を追加しました。browserContent フラグは各アプリにサンドボックスを 1 つではなく 2 つ設けることを可能にします。ひとつはアプリ自身用、もうひとつはアプリが開く "web コンテンツ" 用です。例えば:</p>
<p>MyBrowser アプリが <a class="external free" href="https://mybrowser.com" rel="nofollow">https://mybrowser.com</a> ドメインから読み込まれるとします。このドメインは、内部でスクリプトやリソースを読み込みます。スクリプトやリソースはこのドメインに<em>属して</em>います。</p>
<p>ここでアプリ内のページが <code>&lt;iframe mozbrowser&gt;</code> を作成すると、その <code>&lt;iframe&gt;</code> で使用する別のサンドボックスが作成されます。このサンドボックスは、アプリで使用するサンドボックスとは異なります。すなわち、その <code>&lt;iframe&gt;</code> が <a class="external free" href="https://mybrowser.com" rel="nofollow">https://mybrowser.com</a> にナビゲートした場合、<code>&lt;iframe mozbrowser&gt;</code> 内では別の Cookie を使用することになります。同様に、<code>&lt;iframe mozbrowser&gt;</code> 内部のコンテンツはアプリが開いたものとは別の IndexedDB や localStorage のデータベースを参照します。</p>
<p>またこれは、MyBrowser アプリが位置に基づいたブラウジングを実装するために、例えば Google マップと連携したい場合にも適用されます。アプリが <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a> を指す <code>&lt;iframe&gt;</code> を開いた場合、そこでは <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a> の Web サイト向けの Cookie のセットを受け取ります。そしてユーザが Web コンテンツ領域内、つまり <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a> を指す <code>&lt;iframe mozbrowser&gt;</code> 内で操作したときは、トップレベルのアプリとは別の Cookie や許可設定を使用します。</p>
<p>この仕組みが有用な別の例として、Yelp のようなアプリがあります。Yelp は、アプリ内で直接レストランの Web サイトを訪問できます。レストランの Web サイトを開くために <code>&lt;iframe mozbrowser&gt;</code> を使用することで、Yelp のアプリは、レストランの Web サイトが逆に Yelp のアプリを指す (<a class="external free" href="http://yelp.com" rel="nofollow">http://yelp.com</a> を指す) <code>&lt;iframe&gt;</code> を含むことができないことが保証されます。それを行うと、Web サイトでは Yelp のアプリではなく Yelp の Web サイトだけを受け取るでしょう。よって、iframe 内にある Yelp の Web サイトは Yelp アプリの許可設定やデータを共有しませんので、レストランの Web サイトはアプリに対して攻撃を行える手段がありません。</p>
<h2 id="App_Security_Summary" name="App_Security_Summary">アプリセキュリティのまとめ</h2>
<p>以下の表は、さまざまな種類の Firefox OS アプリのまとめと、Firefox OS で実行する Open Web Apps の形式、インストール、更新プロセスの説明を掲載したものです。</p>
<table>
 <caption>
  Web アプリの種類</caption>
 <thead>
  <tr>
   <th scope="col">型</th>
   <th scope="col">提供方式</th>
   <th scope="col">許可設定モデル</th>
   <th scope="col">インストール</th>
   <th scope="col">更新</th>
  </tr>
 </thead>
 <tbody>
  <tr>
   <td>Web</td>
   <td>ホスト型またはパッケージ型</td>
   <td>未検証の Web コンテンツをさらしても危険ではない、注意の必要性が低い許可設定</td>
   <td>どこからでもインストールできる</td>
   <td>アプリのインストール元や提供方法に応じて、ユーザから透過的に、または Marketplace で明示的に更新できます。</td>
  </tr>
  <tr>
   <td>Privileged</td>
   <td>パッケージ型および署名付き</td>
   <td>アプリの検証や認証を必要とする、特権 API</td>
   <td>信頼された Marketplace からインストールする</td>
   <td>信頼された Marketplace で更新を行います。ユーザは更新のダウンロードやインストールを認めるかを問われます。</td>
  </tr>
  <tr>
   <td>Internal</td>
   <td>パッケージ型</td>
   <td>サードパーティのアプリが使用できない、強力かつ危険な API</td>
   <td>デバイスへのプリインストール</td>
   <td>システムレベルの更新の一部としてのみ更新されます。</td>
  </tr>
 </tbody>
</table>
<div class="note">
 <p><strong>注記</strong>: Firefox OS バージョン 1.0 では、Web アプリは Web サイトと Marketplace のどちらからでもインストールできますが、Privileged アプリは Mozilla Marketplace からしかインストールできず、複数の信頼された Marketplace はまだ完全にはサポートしていません。</p>
</div>
<p> </p>