Flash Player 8 では、ローカル Flash コンテンツに適用されるセキュリティモデルが変更されました。HTTP 経由ではなく、ユーザーのローカルファイルシステムから直接、Flash アプリケーションを実行する場合、デフォルトでは、Flash Player 7 でよりも Flash Player 8 でのほうが、権限が厳しく制限されるようになりました。セキュリティモデルの今回の変更はすべてのバージョンの Flash コンテンツに適用されます。つまり、Flash Player 8 のリリース前にパブリッシュされたコンテンツは、この変更による影響を受ける場合があります。また、そのリリース後に作成された新しいコンテンツも、この変更による影響を受ける場合があります。この記事では、今回の変更から生じる問題を解決する方法について説明します。

セキュリティモデルが変更されたほか、Flash Player 8 では、制限と新しいセキュリティ機能がいくつか追加されています。この記事では、これらの新しい制限や機能についても説明しますが、Flash Player 8 では、ローカルセキュリティの変更のほうが、セキュリティ上はるかに重要なテーマです。

メモ : ローカルセキュリティの今回の変更は "HTTP 経由でサービスを提供される Flash コンテンツには影響を与えません。" ほとんどの Flash コンテンツは HTTP 経由でサービスを提供され、今回の変更による影響を受けることはありません。

新しい制限

ここでは、Flash コンテンツに適用される最新の制限を挙げます。

ローカルサンドボックス : デフォルトでは、ローカル SWF がインターネットへのアクセス、HTTP 経由の通信、ローカル HTML ファイルとの通信を行うことは許可されなくなりました。バージョン 7 以前の SWF がこれらのアクションのいずれかを実行しようとすると、警告ダイアログボックスが表示され、そのアクションを実行できないことが通知されます。このダイアログボックスが表示され、既存のコンテンツの処理が停止されたら、エンドユーザーまたは Flash 開発者は適切な許可を与えることによって、この状況を回避できます。
ロードに関する制限 : 非ローカル URL にある SWF および HTML コンテンツがローカルパスにあるコンテンツ (SWF、HTML、PNG など) をロードすることは許可されなくなりました。
サードパーティのストレージ : Flash Player ユーザーがサードパーティの SWF (ブラウザのアドレスバーに表示されるドメインとは異なるドメインにある SWF) による永続共有オブジェクトへの読み書きを禁止できるようになりました。この制限はデフォルトでは適用されません。適用されるように事前に設定しておく必要があります。
allowScriptAccess のデフォルト値 : バージョン 8 以降の SWF の場合、HTML allowScriptAccess パラメータのデフォルト値は「always」ではなく、「sameDomain」です。この制限はバージョン 7 以前の SWF には影響を与えません。allowScriptAccess パラメータは、SWF が HTML ページ内の JavaScript を呼び出すことを許可するかどうかを制御します。

新しいセキュリティ機能

ここでは、Flash コンテンツで使用できる新しいセキュリティ機能を挙げます (Flash Player 7 に関するセキュリティ情報については、Macromedia Flash Player 7 のセキュリティ機能の変更点に関する記事を参照)。

allowDomain でのワイルドカードの使用 : System.security.allowDomain() で、任意のドメインにある SWF によるアクセスを許可するワイルドカード「*」引数を使用できるようになりました。

許可の適用先の絞り込み : System.security.allowDomain() と System.exactSettings が呼び出し元の SWF のドメイン全体ではなく、呼び出し元の SWF にのみ適用されるようになりました。この機能は新しい (バージョン 8 以降の) コンテンツにのみ影響を与えるため、下位互換性は保持されます。

永続共有オブジェクトの保護 : HTTPS 経由でロードされる SWF は、同じく HTTPS 経由でロードされる SWF によってのみアクセスできる SharedObject オブジェクトを作成できるようになりました。この機能は、ブラウザの Cookie の機能を反映し、共有オブジェクトに格納されているデータをスヌーピングや改ざんの脅威から保護します。既存の共有オブジェクトは影響を受けません。

ローカルセキュリティが変更された理由

Flash Player 8 でローカルセキュリティが変更されたのには、大きな理由があります。ユーザーがコンピュータに SWF をダウンロードするとき、それらの SWF による有害なアクションの実行を Flash Player が常に許可しないことを信頼できる必要があるためです。セキュリティが配慮される場所で、ユーザーはコンピュータ上でダウンロードおよび実行する SWF ファイルに対して、コンピュータ上で格納している JPEG や TXT ファイルに対してと同じように安心感を持つ必要があります。実行可能なファイルに対してのように警戒感を持つ必要があるのでは困ります。

Flash Player 7 以前では、ローカル SWF をどう扱うかは、Flash コンテンツの作成者とってのローカル SWF の意味によって決まっていました。ローカル SWF は通常、Web 上でパブリッシュされることを最終目的とする一時的なローカルファイルにすぎません。この意味では、ローカル SWF が実行できるアクションを制限することは不要です。ただし、Flash コンテンツの作成者でないユーザーが SWF をダウンロードおよび実行するときは、SWF が悪意のないものと信頼できるだけの十分な情報が得られない場合があります。Flash Player 7 以前では、悪意のある SWF をユーザーが騙されてダウンロードおよび実行してしまった場合、ローカル SWF は 2 つの権限を組み合わて有害なアクションを実行できました。具体的には、ユーザーのファイルシステム内の既知の (または推測の) 場所からテキストファイルを読み取り (たとえば XML.load() を使用)、それらのファイルのコンテンツを攻撃者に返信できました。Flash Player 8 でのローカルセキュリティの変更で防止対象となるのは、このようなファイル・スヌーピングのパターンです。

Flash が長期にわたり普及してきた大きな要因は、Flash Player のすべての新しいリリースで、すべての既存の Flash コンテンツとの下位互換が保持されてきたことにあります。セキュリティの変更では、この原則が破られることがあり、Flash の開発者を含めたユーザーの苛立ちの原因になっています (多くのユーザーは Flash Player 7 のセキュリティ機能の変更点によって必要になるコンテンツの変更に不満を表すと予想されます)。Macromedia では、セキュリティの変更によるユーザーへの影響を認識しており、このような課題に誠意を持って取り組んでいます。セキュリティの変更により影響を受けたユーザーの皆様には心よりお詫びを申し上げます。

このような経緯はあるものの、セキュリティモデルの改良は Flash のようなプラットフォームテクノロジにとって必須のものです。Flash Player は、非常に高い普及率を誇り、この点はユーザーにとって Flash の重要な価値になっています。安全な動作が求められるのは、個人や企業のユーザーが Flash Player を引き続き使用するためにインストールやアップグレードを必要とする場合です。後になって考えても仕方のないことですが、Flash Player の普及前の早い段階でローカル Flash コンテンツ用にセキュリティ規則を強化していれば、事態はもっと単純だったと予想されます。ただし、ユーザーによる Flash の使用に合わせてセキュリティの脅威も巧妙になり、複数のリリースを経てようやく脅威が取り除かれる場合もあります。

良い知らせとしては、Flash Player 8 での変更ほうが Flash Player 7 での変更よりもコンテンツに与える影響が少ないことです。Flash Player 7 での変更は、Web 上で展開される一部のコンテンツに影響を与えましたが、Flash Player 8 での変更は、ローカルファイルとして展開される特殊なコンテンツにのみ影響を与えます。世界中で数百万の Flash コンテンツの展開事例がある状況で、ローカルに展開される Flash コンテンツの事例がまだ多数あります。ただし、このような事例は特殊なので、Flash Player 8 での変更による影響を受ける開発者の数は、Flash Player 7 での変更による影響を受けた開発者の数より、相当少なくなると予想されます。

ローカルセキュリティの基本

Flash Player 7 以前では、ローカル SWF (ローカルパスを使用してユーザーのファイルシステムからロードされる SWF) は、Flash Player のセキュリティ規則によって通常管理されるほとんどの操作の実行を自由に許可されていました。たとえば、HTTP 経由でロードされる SWF は XML.load() を使用して、自らのソースのドメインからのテキストのロードのみ (デフォルトで) 許可されていますが、Flash Player 7 で実行されるローカル SWF は XML.load() を使用して、任意の HTTP URL またはローカルファイルシステムのパスからのテキストのロードを許可されていました。

"local-read" という権限を使用してローカルパスからテキストファイルを読み取るとします。また、Flash Player 7 で、すべての SWF が "net-send" という追加の権限を持っているとします。この場合、たとえば LoadVars.send() による HTTP POST 操作によって、任意のデータをインターネット上の任意の場所に送信できまます。エンドユーザーが信頼されないソースからダウンロードしたローカル SWF は、local-read と net-send を組み合わせて使用して、ユーザーのコンピュータからテキストファイルを読み取り、それらのコンテンツをインターネット上の任意の場所に返信できます。この操作はユーザーの知らない間に不正に行われます。

Flash Player 8 で、ローカル SWF に適用される規則を要約すると次のようになります。デフォルトでは、ローカル SWF は local-read 権限を保持しますが、net-send 権限を失います。それらの SWF は、いかなる方法でもインターネット (または任意の HTTP サーバー) と通信することは許可されません。また、SWF ファイル内の設定を変更することによって、Flash 作成者は、SWF が local-read 権限を失う代わりに、net-send 権限を得るように選択することもできます。さらに、Flash 作成者とユーザーは、これら両方の権限を持つ "信頼される" ステータスに SWF を上げるように、Flash Player を構成できます。つまり、SWF は Flash Player 7 で持っていたものと同じ権限を持つことになります。

影響を受けるコンテンツ

Flash コンテンツは次の 2 つの要因によって影響を受ける場合があります。つまり、そのコンテンツがローカルコンテンツかどうか、どのタイプの Flash Player で実行されるかです。

影響を受ける SWF はローカルパスからロードされたものです。このような URL 形式の例を次に示します。

c:\temp\my.swf
file:///c|/temp/my.swf
/temp/my.swf
file:///temp/my.swf
\\server\share\my.swf
file:////server/share/my.swf
既にローカルにある SWF によってロードされた相対 URL

Flash Player にはいくつかの異なるタイプがあり、各タイプの Flash Player はそれぞれの環境で影響を受けます。

Web ブラウザプレーヤー (ActiveX コントロールおよびプラグインプレーヤー) は、Webブラウザで常に使用されるローカルセキュリティ規則に従います。
ブラウザアプリケーション以外で使用される Webブラウザプレーヤーは必ずしもローカルセキュリティ規則に従うとは限りません。このタイプのプレーヤーを埋め込んだアプリケーションを維持する場合は、Flash Player の埋め込みとローカルセキュリティに関するセクションを参照してください。
スタンドアロンプレーヤーはローカルセキュリティ規則に従います。
Macromedia Flash オーサリングアプリケーションやスタンドアロンプレーヤーから作成できる Flash プロジェクタはローカルセキュリティ規則に従いません。それらが実行可能なアプリケーションであるためです。ユーザーはこのようなアプリケーションを慎重に扱う必要があることを一般に知っています。
Flash オーサリングプレーヤーはローカルセキュリティ規則に従いません。それらが Web にあるコンテンツを再生するのではなく、開発中のコンテンツをテストするために使用されるためです。

サンドボックスのタイプ

Flash Player 8 では、すべての SWF (および SWF-HTML スクリプティング目的の HTML ファイル) は次の 4 タイプのサンドボックスのいずれかに置かれます。

remote : 非ローカル URL にあるファイルはすべてリモートのサンドボックスに置かれます。このようなサンドボックスは多数あり、ファイルのロード元の各インターネット (またはイントラネット) ドメイン用に使用されます。このタイプのサンドボックスは Flash Player 6 で導入されたものであり、Flash Player 8 でも変更されていません。
local-with-filesystem : これは Flash Player 8 でのローカルファイル用のデフォルトのサンドボックスです。このサンドボックス内の SWF は、いかなる方法でもインターネット (または任意の HTTP サーバー) と通信することは許可されません。たとえば、HTTP URL を loadMovie()、getURL()、または XML.load() に渡すことは許可されません。このような操作が Flash Player 7 では許可されていたため、エンドユーザーが Flash Player 7 から Flash Player 8 にアップグレードした後、バージョン 7 以前の SWF がインターネットと通信しようとすると、以前は機能していたコンテンツが意図どおりに機能しなくなる可能性があります。したがって、バージョン 7 以前の SWF がインターネットと通信しようとすると、Flash Player 8 では、警告ダイアログボックスが表示され、その SWF がインターネットと通信できなかったことが通知されます。警告ダイアログボックスには、ユーザーが設定マネージャにアクセスするためのボタンがあります。設定マネージャで、影響を受けるコンテンツを local-trusted ステータスに上げるように選択することもできます (以下を参照)。
local-with-networking : このサンドボックス内の SWF は HTTP 経由での通信は許可されますが、ローカルファイルシステムからの読み取りは許可されません。あらゆるバージョンの SWF は、SWF 自体に設定されたフラグを使用して、このサンドボックスに置かれるように設定されます。つまり、ユーザーの介在なしで、SWF はこのサンドボックスに置かれます。このフラグは、Flash 8 で publish オプションを使用して、または、Local Content Updater* (macromedia.com から無償で入手できる SWF 後処理ユーティリティ) を使用して設定できます。
local-trusted : このサンドボックスに制限はありません。Flash Player 7 ですべてのローカルファイルに与えられたものと同じ open 権限が与えられます。あらゆるローカルファイルは、エンドユーザーによって "信頼される" ファイルとして登録されている場合に、このサンドボックスに置かれることが許可されます。この登録は次の 2 つの形式で、つまり、設定マネージャを使用して対話式に、または、ユーザーのコンピュータ上に Flash Player 構成ファイルを作成する実行可能なインストーラを使用して非対話式に行うことができます。

この時点で、ローカルセキュリティについて説明する付録の図表を確認すると、理解を深めるために役立ちます (ローカルセキュリティの図表に関するセクションを参照)。

ローカル SWF がインターネット (またはイントラネット HTTP サーバー) へのアクセスを必要とする場合、そのようなアクセスを許可にする 2 つのローカルサンドボックスがあります。local-with-networking サンドボックスの実装はより容易であり、必要な構成情報はすべて SWF と同じ場所に置かれるため便利です。local-trusted サンドボックスはより強力であり、より大きな権限を SWF に与えます。ただし、その実装は一般により難しく、必要な構成情報はすべて SWF と離れた場所に置かれます。ローカルセキュリティ規則の詳細について説明した後、この記事では、これら 2 つのサンドボックスのいずれを使用するかを決定する方法について説明します。

グローバル許可

Flash Player 8 では、ローカルファイルには無制限の許可が与えられなくなったため、Flash の各許可がローカルファイルに与えられる状況があります。これらの状況については、次のセクションで説明します。

一般に、Flash Player はローカルファイルに許可を与えるために "グローバル許可の原則" に従います。たとえば、リモート SWF が local-with-networking SWF による自らのスクリプティングを許可する場合は、System.security.allowDomain("*") を呼び出し、ロードされる他の SWF すべてに自らのスクリプティングを許可します。Flash Player には、ローカルファイルにのみ許可を与える方法は用意されていません。ファイルに許可を与える当事者は、"すべての" ファイルに許可を与えるしか方法がありません。これは、Flash Player がどのローカルファイルのソースも特定できないためです。ファイルのソースは任意の場所であることが考えられます。したがって妥当なのは、ファイルに許可を与える当事者がファイルのソースを心配する場合は、ローカルファイルによるアクションの実行を許可しないことです。

呼び出し元の SWF が機密情報を含んでいる場合は、System.security.allowDomain("*") を呼び出さないでください。また、セキュリティ問題を解決するためだけに、System.security.allowDomain("*") を呼び出さないでください。呼び出した場合は、該当するコンテンツに必要な保護が失われます。グローバル許可を与えるときは毎回、ある程度の時間をかけて結果について検討してください。

ローカルサンドボックス

このセクションでは、SWF が置かれる各種のローカルサンドボックスについて説明します。

権限

Flash Player では、ローカルファイルに対して次の権限が定義されます。

local-read。この権限は、local-with-filesystem の SWF に適用されます。local-with-networking の SWF には適用されません。この権限には、外部ファイルのデータを ActionScript 変数にロードする操作が含まれます。外部ファイルからロードされるデータは、ローカルファイルシステムに置かれています。ローカル URL フォームの例は、「影響を受けるコンテンツ」に示されています。影響を受けるデータロード操作は次のとおりです。
- XML.load、XML.sendAndLoad
- LoadVars.load、LoadVars.sendAndLoad、loadVariables、loadVariablesNum、MovieClip.loadVariables
- 別の SWF ライブラリからのシンボルの読み込み
net-send。この権限は、local-with-networking の SWF に適用されます。local-with-filesystem の SWF には適用されません。この権限には、インターネット上の場所や HTTP サーバーにデータや要求を送信する操作が含まれます。非ローカル URL で使用する次の操作がすべて含まれます。
- XML.load、XML.send、XML.sendAndLoad
- LoadVars.load、LoadVars.send、LoadVars.sendAndLoad、loadVariables、loadVariablesNum、MovieClip.loadVariables
- XMLSocket.connect
- NetConnection.call (Flash Remoting)
- 別の SWF ライブラリからのシンボルの読み込み
- getURL、MovieClip.getURL
- loadMovie、loadMovieNum、MovieClip.loadMovie、MovieClipLoader.loadClip
- Sound.loadSound
net-read。Local-with-networking の SWF で net-send 操作が実行される場合があります。一部の net-send 操作は一方向の操作となり、データを送信しますが応答は返されません。その他の net-send 操作では、要求が送信され、応答を受け取ります。後者の操作は "net-read" 操作と呼ばれ、net-send 操作のスーパーセットとなります。local-with-networking の SWF では、net-read 操作が試みられる場合がありますが、対象となるデータが置かれているドメインから許可を受ける必要があります。具体的には、非ローカル URL を使用する次の各操作になります。
- XML.load、XML.sendAndLoad
- LoadVars.load、LoadVars.sendAndLoad、loadVariables、loadVariablesNum、MovieClip.loadVariables
- XMLSocket.connect
- NetConnection.call (Flash Remoting)
- 別の SWF ライブラリからのシンボルの読み込み
SWF-HTML。この権限には、SWF ファイルが HTML ファイルをスクリプティングする操作、およびその逆の操作が含まれます。3 つのローカルサンドボックスのうち、信頼できるローカルファイルのみが SWF-HTML 権限を与えられます。これは、Flash Player のセキュリティモデルと Web ブラウザのセキュリティモデルが一致しない可能性があるためです。具体的には、次の各操作が含まれます。
- SWF から HTML への操作:

        fscommand
getURL("javascript:...")
ExternalInterface.call
          
    

HTML から SWF への操作:
JavaScript API*(SetVariable、GotoFrame など)
ExternalInterface.addCallback で確立されたコールバックの呼び出し

local-with-networking サンドボックスに置かれる SWF の選択

このサンドボックスには、UseNetwork フラグが含まれているローカル SWF が置かれます。このフラグはすべてのバージョンの SWF に含めることができますが、このフラグが機能するのは Flash Palyer 8 以降のみです。このフラグは、次のいずれかの方法で確立されます。

Flash 8 からパブリッシュする場合は、[パブリッシュ設定] ダイアログボックスの [Flash] タブの下部にある [ローカルでの再生に関するセキュリティ] オプションで、[ネットワークにのみアクセスする] を選択します (図 1 を参照)。

図 1 ローカル再生のセキュリティを [ネットワークにのみアクセスする] に設定する

Flash 8 を持っていない場合や、再度 SWF をパブリッシュするのではなく、パブリッシュ後に SWF を操作する場合は、Flash Local Content Updater を使用します。これは、無料で利用できるコマンドラインユーティリティであり、Macromedia の Web サイトからダウンロード可能*です。Local Content Updater を使用すると、複数の SWF ファイルに対して、UseNetwork フラグを追加、削除、またはチェックできます。Local Content Updater は、Windows、Mac OS X、および Linux 環境用に用意されており、ソースコードとして使用することもできます。

UseNetwork フラグは、HTTP 経由でロードされた SWF には影響を与えません。これらの SWF は常にリモートサンドボックスに置かれます。また、信頼できる SWF としてユーザーが設定した SWF にも影響を与えません。信頼できる SWF は常に local-trusted サンドボックスに置かれます。UseNetwork フラグが影響を与えるのは、local-with-filesystem サンドボックスに置かれる SWF のみです。

local-trusted サンドボックスに置くファイルの設定

ユーザーのローカル設定で信頼できるとされているローカルパスに該当するローカル SWF (または HTML ファイル) は、このサンドボックスに置かれます。個々のファイルのパスが信頼性があるとして設定される場合も、ディレクトリが信頼性があるとして設定される場合もあります。後者の場合、選択されている各ディレクトリおよびそのサブディレクトリ内のすべてのファイルが信頼性のあるファイルとなります。信頼できるかどうかの指定は、次の 2 つの方法で行うことができます。

設定マネージャ。ユーザーは、設定マネージャの [グローバルセキュリティ設定] パネルを使用して、リスト内の信頼できるパスを手動で追加、編集、または削除できます (図 2 を参照)。

図 2 Flash Player 設定マネージャでのセキュリティ設定

ユーザーは、このパネルの [常に確認]、[常に許可]、[常に拒否] オプションを使用して、Flash Player で古い SWF (バージョン 7 またはそれ以前の local-with-filesystem SWF) を処理する方法をグローバル設定することもできます。デフォルトの設定は [常に確認] で、許可されていない操作が行われると警告のダイアログボックスが表示されます。[常に許可] を選択すると、許可されない操作も実行されます。これは Flash Player 7 のデフォルト設定と同じです。ただし、この設定は、バージョン 8 以降の SWF に対しては機能しません。このオプションは、新しいローカルルールが作成される前に開発されたコンテンツのみを対象としたものです。[常に拒否] を選択すると、許可されていない操作はすべて失敗します。警告のダイアログボックスは表示されません。
メモ : [常に確認]、[常に許可]、[常に拒否] の各オプションの指定によって、ローカルセキュリティに関するプロンプト表示条件だけはでなく、Flash Player 7 から導入されたドメイン完全一致に関するプロンプト表示条件も決定されます。
FlashPlayerTrust 設定ファイル。信頼性のあるパスのリストが記載されたシンプルテキストファイルであり、実行可能なインストーラプログラムによって作成されることを前提とするファイルです。インストーラが SWF をユーザーのコンピュータにインストールするときには、それらの SWF が信頼性のある SWF であることを示す設定ファイルをインストールできます。この動作は、ユーザーがそれらの SWF を信頼できると明示的に決定することを表すものではありません。しかし、ユーザーは、インストーラプログラムを実行することによって、実行可能プログラムであるインストーラプログラムを暗黙的に信頼したことになります。Flash Player では、信頼設定ファイルが 2 つの場所で認識されます。1 つはそのコンピュータのすべてのユーザーに影響を与える場所であり、もう 1 つは現在のユーザーのみに影響を与える場所です。すべてのユーザーに影響を与える場所は、OS レベルで管理者権限が必要とされる次の場所になります。
- Windows のすべてのユーザー :
  <system>\Macromed\Flash\FlashPlayerTrust
  
  (例 : c:\WINNT\system32\Macromed\Flash\FlashPlayerTrust)
- Windows シングルユーザー :
  <app data>\Macromedia\Flash Player\#Security\FlashPlayerTrust
  
  (例 : c:\Documents and Settings\fred\Application Data\Macromedia\Flash Player\#Security\FlashPlayerTrust)
- Macintosh のすべてのユーザー :
  <app support>/Macromedia/FlashPlayerTrust
  
  (例 : /Library/Application Support/Macromedia/FlashPlayerTrust)
- Macintosh シングルユーザー :
  <app data>/Macromedia/Flash Player/#Security/FlashPlayerTrust
  
  (例 : /Users/fred/Library/Preferences/Macromedia/Flash Player/#Security/FlashPlayerTrust)

上記の場所はすべてディレクトリであり、個々のファイルではありません。これらのディレクトリには複数の設定ファイルがインストールされている場合があります。Flash Player では、これらのディレクトリ内に見つかったすべてのファイルを読み取ります。設定ファイルは FlashPlayerTrust のサブディレクトリには置くことができません。FlashPlayerTrust ディレクトリの直下に置く必要があります。個々の設定ファイルには任意の名前を付けることができますが、名前の競合を防ぐため、インストーラでは、対応する製品に固有の名前となるような名前が付けられます。システムによっては FlashPlayerTrust ディレクトリが存在しない場合があります。この場合は、インストーラで FlashPlayerTrust ディレクトリを作成する必要があります。

これらのファイルの構文は単純で、任意の数のローカルパスが、1 行ごとに分かれて記述されます。空白や空白行も許可されます。コメントは、先頭に # 文字を付けて記述され、行の末尾に置かれます。空白を含むパスを引用符で囲むと問題が発生するため、引用符を使用する必要はありません。

これらのファイルに記述されるファイルシステムパスには、コンピュータによっては非 ASCII 文字が含まれる場合があります。このため、FlashPlayerTrust ファイルで使用されるテキストエンコーディングが重要な意味を持ちます。Flash Player は、これらのファイルの冒頭で Unicode のバイト順マーク文字を調べ、UTF-8 および UTF-16 バイト順マークを検出すると、ファイルの残りを UTF-8 または UTF-16 として処理します。たとえば、Windows のメモ帳や Macintosh の TextEdit では、これらのバイト順マーク文字を含む Unicode テキストファイルを記述できます。また、その他多くのテキストエディタでも、同様に記述できます。Flash Player が FlashPlayerTrust ファイルの冒頭でバイト順マーク文字を検出できなかった場合は、コンピュータの現在の "コードページ" (デフォルトのローカルエンコーディング) を使用してファイルを解釈します。

HTML サンドボックス

通常、サンドボックスに配置されるのは SWF ファイルですが、Flash Player では、SWF ファイルと HTML ファイルの相互作用を制御するため、HTML ファイルもサンドボックスに配置されます。ローカル HTML ファイルには、信頼性のあるファイル用のサンドボックスと、信頼性のないファイル用のサンドボックスの 2 つのサンドボックスがあります。ローカル HTML ファイルは、デフォルトでは信頼性のないファイルに分類されますが、SWF ファイルの場合と同様の方法で、信頼性のあるファイルに指定できます。ローカル HTML ファイルのサンドボックスが意味を持つのは、Flash Player JavaScript API など、HTML から SWF へのスクリプティングの場合のみです。

SWF のサンドボックスの判別

SWF がそのサンドボックスの種類を判別する際には、次の読み取り専用 ActionScript プロパティが使用されます。

System.security.sandboxType

このプロパティには、次の 4 つのストリング値のいずれかが指定されます。

"リモート"
"localWithFile"
"localWithNetwork"
"localTrusted"

local-with-filesystem サンドボックスの動作

local-with-filesystem サンドボックス内の SWF は、local-read 操作を行うことはありますが、net-send 操作や SWF-HTML 操作は行いません。

Flash Player のデバッグバージョンを使用し、Macromedia Flash のデバッガに接続している場合は、このサンドボックス内の SWF が許可されていない操作を試みるたびに、操作の失敗を通知する診断メッセージが [出力] パネルに表示されます。

このサンドボックス内にあるパブリッシュバージョン 7 またはそれ以前の SWF の再生中に、その SWF が許可されない操作を試みると、セキュリティ警告のダイアログボックスが表示され、Flash Player 8 のローカルセキュリティ規則の変更により、コンテンツの操作が停止されたことが通知されます。

図 3 操作が停止されたことを通知するセキュリティ警告のダイアログボックス

このダイアログボックスは、アプリケーションが実行されるたびに、1 回だけ表示されます。その後、許可されない操作が行われても、このダイアログボックスは表示されずに操作が失敗します。

このダイアログボックスでユーザーがどのような処理を行っても、試みられた操作は失敗します。だだし、ユーザーが [設定] ボタンをクリックすると、新しいウィンドウが開き、設定マネージャが表示されます。設定マネージャでは、許可されない操作を試みたローカルコンテンツを信頼性のあるコンテンツに指定することができます。図 2 の Flash Player 設定マネージャが表示されてから短時間のうちに [追加] コマンドを選択すると、許可されない操作を試みたローカル SWF のパスがヒントに表示されます (図 4 を参照)。

図 4 信頼される場所を "ヒント" プロンプトで指定

表示されたパスを [このサイトを信頼する] テキストボックスにコピーして、ダイアログボックスが表示されるきっかけとなった個々の SWF ファイルを信頼性のあるファイルに指定することができます。この処理で十分な場合もありますが、アプリケーションが複数のファイルで構成されているために、意図した操作を行うには複数のファイルを信頼性のあるファイルに指定することが必要な場合もあります。後述の連携するメディアに関するセクションを参照してください。このように、ユーザーは、複数のファイルを信頼性のあるファイルに指定するか、ダイアログボックスが表示されるきっかけとなった SWF ファイルが置かれているディレクトリ全体を信頼性のあるディレクトリに指定する必要があります。

設定マネージャで設定を変更した場合は、変更内容を有効にするために、元のアプリケーションを再起動する必要があります。通常は、ブラウザを最新表示にすることによってこれを行います。

設定マネージャの [グローバルセキュリティ設定] パネルの周囲に表示されるテキストで、上記のワークフローがエンドユーザー向けに説明されます。また、テクニカルノート「How Do I Let Local Flash Content Communicate with the Internet?*」で、ローカルコンテンツを信頼性のあるコンテンツに指定する手順を参照することもできます。

FlashAuthor.cfg

エンドユーザー向けにローカルセキュリティ警告のダイアログボックスが表示されるのは、バージョン 7 またはそれ以前の SWF についてのみです。このダイアログボックスは、新しいローカルセキュリティ規則によって影響を受ける、Flash 8 より前のコンテンツをユーザーが修正できるようにするためのものです。

しかし、Flash コンテンツの作成者は、このセキュリティ警告のダイアログボックスによって失敗の原因を知ることができます。ローカルセキュリティ規則で禁止されている操作を SWF が試みた場合は、SWF ファイルのバージョンに関わらずすぐに通知される方が便利な場合もあります。

このため、Macromedia Flash 8 をはじめとする各種の Macromedia オーサリングツールでは、"FlashAuthor.cfg" というファイルがインストールされます。このファイルは、すべてのバージョンの local-with-filesystem SWF によって試みられる許可されない操作に対して警告のダイアログボックスを表示するように、Flash Player に指示します。すべてのユーザーが、このファイルを自分で作成することができます。このファイルは、FlashPlayerTrust ディレクトリと同じ場所にある 2 つの場所のいずれかに置くことができます。

Windows のすべてのユーザー :
<system>\Macromed\Flash\FlashAuthor.cfg

(例 : c:\WINNT\system32\Macromed\Flash\FlashAuthor.cfg)
Windows シングルユーザー :
<app data>\Macromedia\Flash Player\#Security\FlashAuthor.cfg

(例 : c:\Documents and Settings\fred\Application Data\Macromedia\Flash Player\#Security\FlashAuthor.cfg)
Macintosh のすべてのユーザー :
<app support>/Macromedia/FlashAuthor.cfg

(例 : /Library/Application Support/Macromedia/FlashAuthor.cfg)
Macintosh シングルユーザー :
<app data>/Macromedia/Flash Player/#Security/FlashAuthor.cfg

(例 : /Users/fred/Library/Preferences/Macromedia/Flash Player/#Security/FlashAuthor.cfg)

このファイルで現在認識されるのは次つのディレクティブのみです。

LocalSecurityPrompt=Author

このディレクティブは、Flash Player が図 3 のダイアログボックスを表示するかどうかを判断する際に、SWF のバージョンを無視するように指示します。

"FlashAuthor.cfg" ファイルには、空白を含めたり、# 文字で始まるコメントを行の末尾に置いたりすることができます。

ローカルファイルとして再生する SWF コンテンツを作成する場合、LocalSecurityPrompt=Author ディレクティブを使用すると Flash Player でエンドユーザーの操作を完全にシミュレーションすることができないため、このディレクティブは使用しないでください。作成者指定の動作を無効にするには、"FlashAuthor.cfg" のコンテンツを上記の LocalSecurityPrompt=Author 以外に変更します。たとえば、上の行をコメントアウトするか、次に示すようにわかりやすいものに変更します。

LocalSecurityPrompt=User

Macromedia Flash 8 では、"FlashAuthor.cfg" をすべてのユーザー用とシングルユーザー用の両方の場所にインストールします。2 つの場所に "FlashAuthor.cfg" が存在する場合、Flash Player ではシングルユーザー用の場所にあるファイルが優先されます。このため、ファイルを編集する際には必ずシングルユーザーの場所にあるファイルを編集してください。

local-with-networking サンドボックスの動作

local-with-networking サンドボックス内の SWF は、net-send 操作を行うことはありますが、local-read 操作や SWF-HTML 操作を行うことはありません。

Flash Player のデバッグバージョンを使用し、Flash のデバッガに接続している場合は、このサンドボックス内の SWF が許可されていない操作を試みるたびに、操作の失敗を通知する診断メッセージが [出力] パネルに表示されます。

ローカルセキュリティ規則の変更前にコンテンツが作成され、Local with Networking サンドボックスに置かれたという状況はありえないため、このサンドボックス内の SWF によってセキュリティ警告のダイアログボックスが表示されることはありません。許可されない操作が失敗した場合、エンドユーザーに警告のダイアログボックスは表示されません。

local-with-networking の SWF で net-send 操作が実行される場合があります。一部の net-send 操作は一方向の操作となり、データを送信しますが応答は返されません。その他の net-send 操作では、要求が送信され、応答を受け取ります。後者の操作は "net-read" 操作と呼ばれ、net-send 操作のスーパーセットとなります。net-read 操作の例としては、XML.load("http://mysite.com/data/schedule.xml") があります。local-with-networking SWF は、net-read 操作を試みることができます。しかし、Flash Player のグローバル許可の原則に基づき、local-with-networking SWF が指定のドメインからデータをロードするには、すべてのドメインが関連データを読み取ることを許可する <allow-access-from domain="*" /> が記述されたポリシーファイルが、そのドメインに対して設定されていることが必要です。上記の例では、mysite.com でポリシーファイルがデフォルトの場所 (http://mysite.com/crossdomain.xml) または該当するデータの隣 (http://mysite.com/data/crossdomain.xml) に置かれている必要があります。後者の場合、デフォルトでない場所にポリシーファイルが置かれていることを Flash Player に伝えるために、SWF のロードで次の呼び出しが必要となります。

System.security.loadPolicyFile("http://mysite.com/data/crossdomain.xml")

連携するメディア用のローカルセキュリティ

これまでは、それ自体で動作する単一の SWF のローカルセキュリティについて説明してきました。ユーザーが許可しない限り、local-read と net-send の両方の権限を持つ個別の SWF はありません。しかし、複数の SWF が互いに連携するときには、Flash Player 8 で導入されたローカルセキュリティの拡張で Flash Player ユーザーを保護する必要もあります。連携する複数の SWF が、まとめて "1 セット" として local-read 権限と net-send 権限の両方を持つことはできません。

SWF 間の連携には 2 つの段階が必要です。まず、1 つの SWF が、通常は ActionScript loadMovie コマンドを使用して、もう 1 つの SWF をロードする必要があります。次に、ActionScript 変数、メソッド呼び出し、LocalConnection オブジェクトなどを使用して、2 つの SWF が互いに情報を交換します。この情報の交換は、"クロススクリプティング" と呼ばれることもあります。

Flash Player では、ローカルキュリティを維持するために SWF のロードが禁止される場合があります。また、SWF のロードは許可されるが、クロススクリプティングが制限される場合もあります。

同じサンドボックス内に置かれた SWF 間では、SWF のロードとクロススクリプティングが常に許可されます。たとえば、すべての local-with-filesystem SWF は他の local-with-filesystem SWF をロードおよびクロススクリプティングすることができ、すべての local-with-networking SWF は他の local-with-networking SWF をロードおよびクロススクリプティングすることができます。異なるサンドボックスに置かれた 2 つの SWF が連携を試みた場合には、前述の制限が適用されます。

表 1 は、サンドボックス間のロードおよびクロススクリプティングの制限をまとめたものです。個々の規則については後で説明します。SWF 間の連携には、必ず 2 つの SWF が関わっています。ここでは、連携操作を起こす loadMovie を呼び出す、またはクロススクリプティングを実行する SWF を "アクセスする SWF"、もう一方の SWF を "アクセスされる SWF" とします。表の上部のラベルはアクセスする SWF のサンドボックスを表し、表の左側のラベルはアクセスされる SWF のサンドボックスを表します。

表 1 は、サンドボックス間のロードおよびクロススクリプティングの制限をまとめたものです。個々の規則については後で説明します。SWF 間の連携には、必ず 2 つの SWF が関わっています。ここでは、連携操作を起こす (loadMovie を呼び出す、またはクロススクリプティングを実行する) SWF を "アクセスする SWF"、もう一方の SWF を "アクセスされる SWF" とします。表の上部のラベルはアクセスする SWF のサンドボックスを表し、表の左側のラベルはアクセスされる SWF のサンドボックスを表します。

表 1 サンドボックス間におけるロードおよびクロススクリプティングの制限
アクセスされる SWF のサンドボックス	local- with- filesystem	local- with- networking	local- trusted	リモート
	アクセスする SWF のサンドボックス
local- with- filesystem	ロード : 可クロススクリプティング : 可	ロード : 不可	ロード : 可クロススクリプティング : 可	ロード : 不可
local- with- networking	ロード : 不可	ロード : 可クロススクリプティング : 可	ロード : 可クロススクリプティング : 可	ロード : 不可
local- trusted	ロード : 可クロススクリプティング : 許可が必要	ロード : 可クロススクリプティング : 許可が必要	ロード : 可クロススクリプティング : 可	ロード : 不可
リモート	ロード : 不可	ロード : 可クロススクリプティング : 許可が必要	ロード : 可クロススクリプティング : 可	ロード : 可クロススクリプティング : 許可が必要 (ドメインが一致しない場合)

ロードの制限

表 1 の赤色のセルは、一部の SWF が loadMovie、loadMovieNum などを使用して他の SWF をロードできないことを示しています。

リモート SWF (HTTP などの非ローカルプロトコル経由で使用される SWF) は、ローカル SWF をロードできません。
local-with-networking SWF は local-with-filesystem SWF をロードできず、その逆の場合もロードできません。
local-with-filesystem SWF はリモート SWF をロードできません。これは、リモート SWF をロードするにはリモート URL を使用して loadMovie を呼び出す必要があるが、この操作は local-with-filesystem SWF には許可されない net-send 操作であるという、既に説明した規則によるものです。

local-with-filesystem SWF は local-with-networking SWF に簡単に変更できるため、後者の 2 つの規則は必要に応じて回避することができます。

しかし、"リモート SWF はローカル SWF をロードできない" という最初の規則は絶対的な規則であり、Flash Player の他の大部分の規則とは異なり、回避できません。この規則は、権限の低いゾーンにあるコンテンツ (リモート SWF) がより権限の高いゾーンにあるコンテンツ (ローカル SWF) をアクティブ化するという、"ゾーンエスカレーション" と呼ばれる状況が発生しないようにするためのものです。ユーザーが Web ページにアクセスしたときにローカルインストールされているコンテンツを起動する、ハイブリッド "リモート-ローカル" アプリケーションを管理している場合があります。このような場合は、エントリポイントを変更し、ユーザーがまずローカル SWF (またはローカルプロジェクタ、ローカル実行可能アプリケーションなど) を表示してからオンラインコンテンツをアクティブ化するように設定するのが最善の方法です。

Flash Player では、SWF ではなくブラウザページをロードする getURL 呼び出しについても、同様の規則があります。

リモート SWF はローカル URL を使用して getURL を呼び出すことができません。
local-with-filesystem SWF はローカル URL を使用して getURL 呼び出しを行うことができますが、これを実行した場合、クエリーパラメータやアンカー (URL で "?" または "#" の後に来る部分) が取り除かれてしまいます。

クロススクリプティングの制限

表 1 の黄色のセルは、アクセスされる SWF がその操作を明示的に許可する場合に限って、1 つの SWF がもう一方の SWF をスクリプティングできることを示しています。次の状況がこれに該当します。

non-trusted (信頼されない) ローカル SWF が local-trusted SWF をスクリプティングする場合は、local-trusted SWF がその操作を許可する必要があります
local-with-networking SWF がリモート SWF をスクリプティングする場合は、リモート SWF がその操作を許可する必要があります
リモート SWF が異なるドメインにある他のリモート SWF をスクリプティングする場合は、アクセスされる SWF がその操作を許可する必要があります (リモート SWF 間の規則は Flash Player 7 から変更されていません)。

Flash Player のグローバル許可の原則に基づき、最初の 2 つの場合には、アクセスされる SWF が他のすべてのサンドボックスにあるアクセスする SWF に許可を与える必要があります。この許可を与えるには、System.security.allowDomain("*") を呼び出します。また、LocalConnection オブジェクトに対する場合は、"localhost" を示すドメイン引数が渡されたときに値 true を返す LocalConnection.allowDomain ハンドラを指定します。

永続化された共有オブジェクト

Flash Player 6 以降では、SharedObject クラスを使用して、永続化された共有オブジェクトがサポートされます。永続化された共有オブジェクトには、ユーザーのコンピュータのデータが格納されます。通常は、SharedObject.getLocal で取得されたローカル共有オブジェクトになりますが、永続化されたリモート共有オブジェクトを作成することもできます。これを作成するには Flash Media Server (以前の Flash Communication Server) が必要であり、この製品でリモート共有オブジェクトについてドキュメント化されています。

各リモートサンドボックスには、永続化された共有オブジェクトの格納場所が関連付けられています。たとえば、domain1.com の SWF が永続化された共有オブジェクトを読み込むか、永続化された共有オブジェクトに書き込む場合、Flash Player ではそのオブジェクトに対して domain1.com オブジェクトの格納場所で読み取りまたは書き込みを行います。同様に、domain2.com の SWF 場合は、domain2.com の格納場所が使用されます。名前の競合を避けるため、永続化された共有オブジェクトを識別するときにはパスも使用されます。このパスは、デフォルトでは作成元 SWF の URL のフルパスになりますが、localPath パラメータを使用して SharedObject.getLocal に短縮することもできます。このように短縮すると、同じドメインにある他の SWF が、作成された共有オブジェクトにアクセスできるようになります。

Flash Player 7 以前では、すべてのローカル SWF が 1 つの永続化された共有オブジェクトストア (共有オブジェクトの格納場所) を共有していました。Flash Player 8 以降には、ローカル共有オブジェクトストアが 2 つあります。Flash Player では、個別の共有オブジェクトストアを 2 つのローカルサンドボックスのそれぞれに割り当てることによって、local-with-filesystem SWF が local-with-networking SWF と通信できないようにしています。

Flash Player は、local-trusted SWF を local-with-filesystem SWF と同じ共有オブジェクトストアに割り当てます。これにより、local-with-filesystem ステータス (デフォルト) と local-trusted ステータスとの間の移行が簡単に行えるようになります。この移行操作は、意図したとおりに動作しなくなった既存のローカルコンテンツを修復する手段として、エンドユーザーが行うことができます。SWF のステータスがこのように移行されたときには、SWF によって作成されたすべての共有オブジェクトが保持されます。

ローカルセキュリティのシナリオ

次の各シナリオは、Flash Player 8 の新しいローカルセキュリティ規則の影響を示すものです。

ユーザーのシナリオ: Flash の作成者とその同僚

Flash Player 8 のローカルセキュリティ規則は、エンドユーザーを保護するように設計されています。エンドユーザーにとってのローカル SWF は通常、インターネット上のソースからダウンロードしたか、アプリケーションの一部としてインストールした、最終的なコンテンツです。しかし、Flash 作成者にとってのローカル SWF は、通常、最終的には HTTP サーバーに配置される開発中のコンテンツの一時的なコピーであることがほとんどです。ローカルファイルの状態にある SWF をプレビューしているため、セキュリティ上の制約によってコンテンツが期待したように動作しないことがあります。

開発中の Flash コンテンツをテストする 3 つの方法を次に示します。最初に挙げた方法が最も単純な方法で、その後に挙げた方法の方が複雑になります。

Flash オーサリングアプリケーションの [ムービープレビュー] を使用する方法。 [ムービープレビュー] プレイヤーでは新しいローカルセキュリティ規則がまったく適用されないため、このモードでは問題が発生しません。
スタンドアローンプレーヤーまたはブラウザプレイヤーを使用してローカル SWF を表示する方法。 この方法では、たとえば SWF が HTTP URL を使用して getURL を呼び出した場合など、新しい規則の適用によって発生する問題を確認できます。
HTTP テストサーバーに SWF を置き、ブラウザで表示する方法。 HTTP 経由で表示される SWF はローカル SWF ではなく、Flash Player 8 でも変更されていないリモートセキュリティ規則の適用対象となります。このため、このテスト方法でも、ローカルセキュリティ規則の適用による問題は発生しません。

ブラウザでプレビューする際に、望ましくないセキュリティ制限が適用されることを防ぐには、開発中の Flash コンテンツと、インターネット上のソースからダウンロードした "信頼されない" SWF とを区別することができると便利です。残念ながら、自動化された確実な方法でこの処理を行う機能は、Flash Player には備わっていません。

その代わりに、ローカルファイルシステムの特定の領域に置かれている SWF をすべて "信頼される" SWF と認識するように、Flash Player を設定することができます。たとえば、開発中の Flash コンテンツをすべて C:\FlashSites に格納し、設定マネージャを使用して C:\FlashSites ディレクトリを "信頼される" パスのリストに追加することができます。この設定を行った後は、C:\FlashSites またはそのサブディレクトリ内にある SWF を表示するたびに、それらの SWF が Local-trusted サンドボックスに置かれるため、セキュリティ規則の適用による操作の失敗を回避できます。この処理を行った場合は、信頼されないソースの SWF を信頼される領域に置かないように注意する必要があります。自分で作成したローカル SWF を、他の人が作成した信頼されない SWF から分離しておくことによって、Flash Player のすべてのエンドユーザーに提供されるのと同じレベルの保護を得ることができます。

設定マネージャを使用して "信頼される" ディレクトリを設定すると、セキュリティ規則の適用による問題に邪魔されることなく、作業を続けることができます。しかし、開発作業の間には、HTML 作成者、Flex 開発者、ビットマップ作成者など、さまざまな人と SWF を共有する必要があります。また、作成中の SWF を上司やクライアントに見せることが必要な場合もあります。SWF を共有する人の中には、コンピュータに "信頼される" ディレクトリを設定していない人がいる可能性があります。その人がローカルファイルとして SWF を開き、SWF が (たとえば getURL 呼び出しによって) インターネットとの通信を試みたり、HTML ページとの通信を試みた場合、ローカルセキュリティ規則の適用によって、ローカルでプレビューされているコンテンツが意図したとおりに動作しないことがあります。また、これらの人の中に、FlashAuthor.cfg をコンピュータにインストールしていない人がいる可能性もあります。SWF のバージョンが 8 以降であった場合、FlashAuthor.cfg をインストールしていないと、操作の失敗の原因を通知するダイアログボックスも表示されません。

残念ながら、これらの問題を一挙に解決する方法はありません。根本的な問題は、Flash Player が同僚のコンピュータで実行されたときに、開発中の (一時的な) ローカル SWF と、インターネットから入手した信頼できない SWF とを区別する方法がないという点です。

問題を解決する最も確実な方法は、開発中の SWF をファイルとして送信せずに、HTTP テストサーバーにポストしてからそのリンクを送信する方法です。しかし、この方法を使用できない場合もあります。たとえば、プライベート HTTP サーバーを持っていない場合や、同じネットワークに属さない人と SWF を共有する必要があるが、SWF をパブリックサーバーにポストすることは避けたい場合には、この方法を使用できません。このような場合のために、他の解決方法を考える必要があります。

SWF プロジェクターを作成する
Local with Filesystem ではなく Local with Networking として SWF をパブリッシュする
SWF プロジェクト用に、FlashPlayerTrust ファイルを設定するインストーラを作成する
設定マネージャの構成方法を同僚に送る
同僚のサーバーに SWF をポストするように依頼する

状況に応じて最善の方法を選択してください。

ユーザーのシナリオ: Flash Player のエンドユーザー

ほとんどの場合、新しいローカルセキュリティ規則は、エンドユーザーには通知されずに適用されます。しかし、既に述べたように、インターネットとやり取りするように記述されたローカル Flash アプリケーションを使用しているユーザーもいます。こうしたユーザーが Flash Player 8 にアップグレードした場合、安全でない可能性のある操作を試みたときにそれを警告するダイアログボックスが表示されるようになります。

この警告ダイアログボックスが表示されたときには、そこに示された問題を無視するか、アプリケーションベンダーに解決方法を問い合わせるか、自分自身で問題を解決することができます。

自分自身で問題を解決する場合は、警告ダイアログボックスの [設定] ボタンをクリックし、設定マネージャにアクセスします。設定マネージャでは、ローカルセキュリティ規則を確認し、[場所の編集]-[場所の追加] を選択して、信頼するローカルパスを指定できます。ただし、信頼する必要のあるパスを判断するのが難しいことがあります。警告ダイアログボックスに表示されたパスを指定するだけで十分な場合もありますが、1 つのアプリケーションに複数の SWF が関わっている場合もあります。このような場合、関係する SWF が置かれているディレクトリ全体を指定することが必要になります。信頼するパスに指定する必要がありそうなすべてのパスを試した後で、元のアプリケーションに戻り、(たとえばブラウザを最新表示することによって) アプリケーションを再起動する必要があります。

設定マネージャにアクセスしたユーザーは、[常に許可] を選択してバージョン 7 以前のすべての SWF を "信頼する" SWF に指定するかどうかを決める必要もあります。この操作は、信頼するパスを判断するより簡単ですが、便利さと引き換えにユーザーのセキュリティレベルが低くなります。

アプリケーションのシナリオ:ハイブリッドヘルプシステムの問題の解決

ローカル SWF を使用するアプリケーションを管理していて、ユーザーから、そのアプリケーションの一部を表示するときに Flash Player のセキュリティ警告のダイアログボックスが表示される理由を尋ねられた場合について考えてみます。このアプリケーションはハイブリッドヘルプシステムで、通常の形式のローカル SWF アプリケーション (getURL や fscommand を使用して互いに通信する HTML ファイルと SWF ファイルのコレクション) であるとします。

まず最初に、問題の深刻度を判断する必要があります。重要なアプリケーションの重要なコンポーネントに大きな問題があるのか、それほど重要でないプロジェクトの一部の機能に欠陥があるのか、修正したファイルをすべてのユーザーに再配布する必要があるのかなどを判断します。修正作業に入る前に、その修正が必要であるかどうかを必ず検証してください。

1 つの方法として、設定マネージャにアクセスしてヘルプシステムのパスを "信頼する" パスに指定するように、ユーザーに指示することができます。しかし、ユーザーによっては、多くの手順を実行してこの設定を行う必要があります。また、セキュリティ設定の影響をよく理解できないユーザーは、不安を感じる可能性があります。

上記の方法以外に、SWF を Local with Networking SWF として再パブリッシュしたり、Local Content Updater* を使用して SWF を後処理したりすることもできます。コンテンツが getURL を呼び出すことによってのみセキュリティ違反が発生する場合は、この方法で十分です。しかし、SWF ファイルと HTML が fscommand、getURL("javascript:...")、またはその他のハイブリッドスクリプティング操作を使用して互いにスクリプティングする場合、Local with Networking サンドボックスを指定するだけでは、アプリケーションを元の状態に戻すことができません。SWF を Local-trusted サンドボックスに置く必要があります。

ユーザーが技術的な内容をよく理解している場合は、FlashPlayerTrust ファイルと、その置き場所についての指示を提供するだけで済みます。また、適切な場所に FlashPlayerTrust ファイルを自動的に作成するスクリプトやプログラムを作成することもできます。SWF がインストールされている場所がわかっている場合は、それらの SWF が置かれるディレクトリを "信頼する" ディレクトリに指定するだけで済みます。しかし、ユーザーがデフォルト以外の場所にインストールしている場合は、SWF をインストールした場所を知らせるようにユーザーに求めるか、ユーザーのファイルシステムを検索して SWF が置かれている場所を確認する必要があります。

アプリケーションのシナリオ:時々接続する連絡先マネージャ

最後に、定期的にデータを HTTP サーバーと同期し、通常はそのデータのローカルリポジトリとして機能する、ローカル SWF アプリケーションを構築する場合について考えてみます。対象となるデータはアドレス帳であり、アプリケーションは "時々接続する連絡先マネージャ" であるとします。

ここで、Net-send 権限は必要であるが、Local-read 権限は不要であると仮定します。たとえば、設定を行うためにローカル XML ファイルを読み取る必要はありません。この場合、SWF のパブリッシュ時には、Flash パブリッシュオプションの [ローカルでの再生に関するセキュリティ] で [ネットワークにのみアクセスする] を選択します。これにより、SWF は、getURL、XML.load、およびその他の HTTP 操作を自由に行うことができるようになります。

次に、アプリケーションを HTTP データソースに接続して同期を行います。XML.sendAndLoad() を使用して単純な XML データを交換するとします。XML.sendAndLoad は Net-read 操作であるため、同期先の HTTP サーバーにポリシーファイルが必要です。ポリシーファイルで HTTP サーバー全体ではなく関連データのみを制御するように、ポリシーファイルを XML データソースの隣に置き、クライアント SWF でポリシーファイルの場所を指定して System.security.loadPolicyFile を呼び出します。ポリシーファイルは次のようになります。

        <cross-domain-policy>
  <allow-access-from domain="*" />
 </cross-domain-policy> 

    

グローバルアクセス許可の原則に基づき、Local with Networking SWF がサーバーからデータをロードできるように、ポリシーファイルではすべての場所 ("*") を信頼する必要があります。

これで、ローカルセキュリティ規則の適用による問題を回避することができます。

ローカルセキュリティの図表

次の図表は、前の各セクションで説明したローカルセキュリティ権限をまとめたものです。

SWF のソースとサンドボックス

すべての SWF は、Flash Player にロードされるとサンドボックスに置かれます。図 5 は、SWF がそのロード元に応じてサンドボックスに割り当てられるしくみを示しています。a.com や b.com などのネットワークからロードされた SWF は常に、その元のドメインに対応するサンドボックスに置かれます。

図 5 SWF のソースに基づいたサンドボックスの割り当て

ローカルソース (ローカルファイルシステムや UNC ネットワークパス) からロードされた SWF は、3 つのサンドボックスのいずれかに置かれます。デフォルトでは、ローカル SWF は local-with-filesystem サンドボックスに置かれます。ネットワークへのアクセス権を必要とすることを宣言したローカルファイルは、local-with-networking サンドボックスに置かれます。設定マネージャまたは設定ファイルによって信頼性のあるファイルとして登録されたローカルファイルは、local-trusted サンドボックスに置かれます (Flash Player 7 以前は、すべてのローカルファイルが local-trusted サンドボックスに置かれていました)。

2 つの SWF が同じサンドボックス内にある場合、両者は自由にやり取りできます。以降の各図表では、異なるサンドボックス、ファイルシステム、およびサーバーに置かれている SWF 同士がやり取りするしくみについて説明します。

デフォルトの権限

図 5 の矢印は、SWF のソースを表しています。以降の各図表では、矢印がアクセスの関係を表します。破線の矢印はデータのロードを表し、輪郭で示される矢印はクロススクリプティングを表します。図 6 は、デフォルトのサンドボックスに置かれる SWF の権限を示しています。

図 6 デフォルトのサンドボックス割り当てと、これらのサンドボックス内でデフォルトで適用される権限

デフォルトでは、ローカル SWF は local-with-filesystem サンドボックスに置かれます。このサンドボックス内の SWF は、たとえば XML.load() を使用して、ローカルファイルシステムや UNC ネットワークパスにあるファイルを読み取ることができますが、インターネットと通信することはできません。

リモート SWF に適用される権限は Flash Player 7 の場合と同じですが、リモート SWF がローカルコンテンツをロードできなくなった点が異なります。リモート SWF は常に、その元のドメインに対応するサンドボックスに置かれます。a.com サンドボックス内の SWF は、たとえば XML.load() を使用して、a.com サーバーからデータを読み取ったり、XML.send() などを使用してインターネット上のあらゆる場所にデータを送信したりすることができます。

リモート SWF に与えられるアクセス許可

図 7 は、リモート SWF にデフォルトでは適用されないが、アクセス許可を使用して与えられる権限を示しています。

図 7 アクセス許可によってリモート SWF に与えられる権限

a.com の SWF は、b.com のポリシーファイルが a.com またはすべてのドメインからのアクセスを許可している場合、XML.load などを使用して b.com サーバーのデータを読み取ることができます。a.com の SWF は、b.com の SWF が System.security.allowDomain("a.com") を呼び出した場合、b.com の SWF の ActionScript メソッドなどを呼び出して、b.com の SWF をクロススプリクティングすることができます。これらのアクセス許可は Flash Player 7 で可能であったもので、Flash Player 8 でも変更されていません。

デフォルトでは、リモート SWF はローカル SWF をクロススクリプティングできません。しかし、local-with-networking SWF および local-trusted SWF は、System.security.allowDomain() を使用して、リモート SWF によるクロススクリプティングを許可することができます。local-with-filesystem SWF は、このような許可を与えることができません。これは、この許可が可能な場合、local-with-filesystem SWF とリモート SWF が連携して、ローカルファイルシステムのデータを読み取り、そのデータを Web サーバーに送ることができてしまうためです。

信頼性のあるローカル SWF に与えられる権限

図 8 は、local-trusted SWF に無制限で与えられる権限を示しています。local-trusted SWF は、ローカルファイルを読み取ったり、あらゆるサーバーとやり取りを行ったり、他のすべての SWF をスクリプティングしたりすることができます。

図 8 local-trusted SWF に与えられる権限

local-with-filesystem SWF に与えられるアクセス許可

図 9 は、local-with-filesystem SWF にデフォルトでは適用されないが、アクセス許可を使用して与えられる権限を示しています。local-trusted SWF は、System.security.allowDomain("*") を使用して、local-with-filesystem SWF によるスクリプティングを許可することができます。

図 9 アクセス許可によって local-with-filesystem SWF に与えられる権限

すべてのドメインにアクセスを許可することによってのみ、local-with-filesystem SWF にアクセスを許可することができます。Flash Player ではローカル SWF のソースを判断することができないため、local-with-filesystem SWF にアクセスを許可すると、すべての SWF に許可を与えることになります。すべてのドメインにアクセスを許可する必要があるのはこのためです。

リモート SWF や local-with-networking SWF が local-with-filesystem SWF にアクセス許可を与えることはできません。これば、この許可が可能な場合、local-with-filesystem SWF とリモート SWF または local-with-networking SWF が連携して、ローカルファイルシステムのデータを読み取り、そのデータを Web サーバーに送ることができてしまうためです。

アクセス許可が与えられない場合、local-with-filesystem SWF ができるのは、ローカルファイルシステムのデータを、XML.load() などを使用してロードすることだけです。

local-with-networking SWF に与えられる権限

図 10 は、local-with-filesystem ではなく local-with-networking であると宣言したローカル SWF にデフォルトで与えられる権限を示しています。アクセス許可が与えられない場合、local-with-networking SWF ができるのは、他の local-with-networking SWF と通信し、XML.send() などを使用してデータをサーバーに送ることだけです。

図 10 デフォルトで local-with-networking SWF に与えられる権限

local-with-networking SWF に与えられるアクセス許可

図 11 は、local-with-networking SWF にデフォルトでは適用されないが、アクセス許可を使用して与えられる権限を示しています。

図 11 アクセス許可によって local-with-networking SWF に与えられる権限

local-with-networking SWF は、a.com のポリシーファイルがすべてのドメインからのアクセスを許可している場合に、XML.load() などを使用して a.com サーバーのデータを読み取ることができます。

local-with-networking SWF は、a.com の SWF が System.security.allowDomain("*") を呼び出した場合に、a.com SWF の ActionScript メソッドなどを呼び出して a.com の SWF をクロススクリプティングすることができます。同様に、local-with-networking SWF は、local-trusted SWF が allowDomain("*") を呼び出した場合、local-trusted SWF をクロススクリプティングすることができます。

すべてのドメインにアクセスを許可することによってのみ、local-with-networking SWF にアクセスを許可することができます。Flash Player ではローカル SWF のソースを判断することができないため、local-with-networking SWF にアクセスを許可すると、すべての SWF に許可を与えることになります。すべてのドメインにアクセスを許可する必要があるのはこのためです。

local-with-networking SWF がローカルファイルからデータを読み取ることを許可されることはありません。

データフローの概要

図 12 は、最大限のアクセス許可のセットが与えられた場合に考えられるデータフローをまとめたものです。

図 12 データフローの概要

アクセス許可を使用すると、local-with-networking SWF がリモート SWF やサーバーと完全に相互操作できるようにすることができます。また、アクセス許可を使用して、local-trusted SWF とネットワークリソースが自由に通信できるようにすることもできます。

ただし、最大限のアクセス許可のセットを使用しても、ローカルファイルシステムのデータをインターネットに送るには、local-trusted SWF を経由することが必要です。

Flash Player の埋め込みとローカルセキュリティ

Flash Player がカスタム GUI の 1 コンポーネントとして埋め込まれているローカルアプリケーションを作成することができます。これは、実行可能プログラムとして作成されるネイティブローカルアプリケーションの場合のみ可能です。

Flash Player のこのような使用について、Macromedia は現時点ではサポートしていませんが、禁止もしていません。作成したアプリケーションで Flash Player を再配布することはできず、ユーザーのコンピュータにインストールされている Flash Player のバージョンによってアプリケーションの動作が左右されてしまうため、Flash Player を埋め込んだアプリケーションを作成することにはリスクが伴います。ユーザーは Flash Player をいつでもアップグレードできるため、作成したアプリケーションで予期しない動作が発生する可能性があります。

Macromedia では、Flash Palyer が埋め込まれたアプリケーションに過度の問題が発生しないように努力しています。

Flash Player 8 以降では、Flash Player が埋め込まれている場合に次のローカルセキュリティ機能が適用されます。

ブラウザ以外のコンテナ内でホストされていることを Flash Player ActiveX コントロールが検知すると、新しいローカルセキュリティ規則が無効化され、すべてのローカル SWF が local-trusted サンドボックスに置かれます。Flash Player ActiveX コントロールが、ブラウザ以外のコンテナ内でホストされている Internet Explorer ActiveX コントロールのインスタンス内でインスタンス化されている場合でも、この処理が行われます。ただし、これが該当するのは、"最終的な" コンテナアプリケーションのみです。Flash Player ActiveX コントロールを埋め込む ActiveX コントロールを保持し、その ActiveX コントロールが Internet Explorer 内に埋め込まれている場合、Flash Player はブラウザ内で実行されていることを検知し、ローカルセキュリティ規則が有効になります。
Flash Player のプラグインプレーヤーは、そのコンテナがブラウザであるかどうかを検知せず、新しいローカルセキュリティ規則を常に有効化します。ただし、エンドユーザーが設定マネージャを使用して、またはインストーラが FlashPlayerTrust 設定ファイルを使用して、Flash Player プラグインが埋め込まれている実行可能アプリケーションのパスを信頼性のあるパスに指定した場合、プラグインは新しいローカルセキュリティ規則を無効化します。
ActiveX とプラグインプレーヤーには、新しいローカルセキュリティルールを有効にするかどうかをホストアプリケーションが選択することを許可する、書き出された API があります。これらの API は、Flash Player のライフサイクルのごく初期の段階で、コンテンツがロードされる前に呼び出される必要があります。呼び出しは次のようになります。

        ActiveX (IDispatch APIs):
HRESULT IShockWaveFlash::EnforceLocalSecurity() 
HRESULT IShockWaveFlash::DisableLocalSecurity()

    

        Plugins (DLL exports):
NPError Flash_EnforceLocalSecurity() 
NPError Flash_DisableLocalSecurity()

    

Flash Player が埋め込まれたローカルアプリケーションを作成する場合には、ローカルセキュリティ規則を有効にするかどうかについて、および適切な API を呼び出すことについて、明示的に決定する必要があります。一般的に、インターネットなど、コントロール下にないソースから SWF コンテンツを再生するためにも Flash Player を使用する場合は、ローカルセキュリティ規則を有効にします。それに対して、コントロール下にある特定の SWF のみを再生し、作成したアプリケーションに組み込む場合は、ローカルセキュリティを無効にして最大限の柔軟性を持たせる方が便利です。

サードパーティの記憶領域

Flash Player 8 以降を使用するユーザーには、多くのブラウザでサードパーティの Cookie に用意されているのと同様のオプションがあります。ユーザーは、クライアントサイドで永続化されている共有オブジェクトに対してサードパーティドメインの SWF が読み取りや書き込みを行うことをできないようにすることができます。デフォルトではサードパーティの記憶領域が有効になっていますが、Flash Player 設定マネージャで [サードパーティ製 Flash コンテンツにログイン情報およびコンピュータ上のその他のデータを格納することを許可します] をオフにすることによって、サードパーティの記憶領域を無効にすることができます。サードパーティ SWF とは、その元のドメインが、ユーザーがアクセスしているプライマリドメイン (ブラウザのアドレスバーに表示されているドメイン) と一致しないすべての SWF のことです。

サードパーティの記憶領域のオプションは、ローカル共有オブジェクトと、(そのよく知られていない同類である) 永続化されたリモート共有オブジェクトの両方に適用されます。永続化されたリモート共有オブジェクトは、Flash Media Server (以前の Flash Communication Server) と連動する場合にのみ使用されます。

サードパーティ記憶領域が無効になっているときに、SWF が SharedObject.getLocal() または SharedObject.getRemote() を使用して共有オブジェクトの取得を試みた場合、Flash Player は呼び出し元の SWF がサードパーティであるかどうかを判断します。Flash Player は、その SWF の元のドメインとブラウザのアドレスバーに表示されているドメインとを比較し、両者のドメインが正確に一致しない場合は、その SWF をサードパーティであると判断します。その SWF がサードパーティであった場合は、getLocal() または getRemote() の呼び出しで null が返されます。

サードパーティ記憶領域に関する制限事項は、ローカル SWF (ユーザーのファイルシステムからロードされた SWF) には適用されません。リモート SWF のみに適用されます。サードパーティ SWF であるかどうかを判断するにはブラウザの URL との比較が必要となるため、Flash Player でサードパーティ記憶領域の制限事項が監視されるのは、Web ブラウザ内で再生されている場合のみです。スタンドアローンプレーヤー、プロジェクタ、および Flash オーサリングプレーヤーの場合は監視されません。

制限事項が適用される場合

SWF が純粋にサードパーティファイルである場合、つまり他の人のサイトに組み込まれている SWF である場合、特定のユーザーによっては、その SWF が共有オブジェクトに対して読み取りや書き込み操作を行うことが許可されません。その理由については、次のセクションの説明を参照してください。

サードパーティであるとして処理されている SWF が、自分の管理下にあるサイト内でのみ使用される場合は、永続共有オブジェクトに対して読み取りまたは書き込み操作を行う必要のある SWF がすべて、ユーザーがアクセスしているプライマリドメインから処理されるように、サイトを再編成する必要があります。

サードパーティの記憶領域が制限される理由

インターネットにアクセスしてさまざまな情報を閲覧すると、便利さと引き換えにプライバシー上のリスクを負うことになります。通常、使用する IP アドレス、オペレーティングシステム、ブラウザなど、自分に関する情報をある程度公開することは避けられませんが、既知の信頼できる相手以外には、ほとんどの個人情報を非公開にすることが望まれます。近年論議の的となっている個人情報の 1 つに、Web コンテンツに格納されるトラック情報によって明らかにされる閲覧履歴があります。ある特定のユーザーのアクセス情報が多くの異なるサイトで同様の方法で記録され、後でそれらのサイトや他のサイトが記録されたアクセス情報をすべて読み取って、ユーザーの閲覧習慣に関する情報を構築できる場合、一部のユーザー (およびユーザープライバシーの保護を提唱する人たち) はこれをプライバシーの侵害と感じます。

こうしたトラック情報は、通常、Web サーバーまたはユーザー自身のコンピュータに格納されます。Web ブラウザや Flash Player などのクライアントテクノロジーでは、Web サーバーに格納される情報を管理できません。このため、ユーザーの閲覧履歴は上記の方法で収集できることになります。しかし、閲覧記録をサーバー上に保存しておくと、サーバーの記憶領域が消費され、またサーバー間の通信も必要となるため、コストがかかってしまいます。また、IP アドレスなどの特性の識別は時間の経過と共に変化する可能性があり、また多数のユーザーによって共有される場合もあるため、複数のアクセス情報から 1 人のユーザーを識別するのが困難な場合もあります。このため、履歴情報の入手を望む側にとっては、可能な場合、閲覧履歴をユーザー自身のコンピュータに記録し、そのコンピュータを使用してアクセスされたサイトの記録を蓄積する方法の方が便利です。

この方法で情報を保存するテクノロジーには、ブラウザの Cookie と、Flash の永続共有オブジェクトがあります。各種ブラウザと Flash Player には、他のサイトが作成した Cookie や共有オブジェクトを読み取ることを禁止する、起源が同じセキュリティポリシーが実装されています。この制限があるため、関係する各サイトが閲覧記録を独自のデータストアに格納するだけでは、他のサイトがこの情報を読み取って履歴情報を構築することができません。このため、一般的には、すべての履歴情報を記録する 1 つのドメインを指定し、履歴を記述する文書を各サイトがそのドメインから参照し、そのドキュメントの取得に使用した URL でサイトを特定する情報を渡す方法が使用されます。以降のアクセスでは、共有のドメインから履歴を読み取るドキュメントが、Cookie を記述するドキュメントによって記述されたすべての記録にアクセスすることができ、ユーザーの閲覧履歴の一部が明らかにされます。

各種 Web ブラウザと Flash Player で、この方法による履歴情報の取得を制御できるようになりました。各種ブラウザと Flash Player のユーザーは、サードパーティの永続化されたデータに対する読み取りおよび書き込み操作を無効にすることができます。ここでのサードパーティとは、ユーザーがアクセスしているプライマリドメイン (ブラウザのアドレスバーに表示されているドメイン) とは一致しないドメインのことです。たとえば、サードパーティの記憶領域を無効にしているユーザーが http://site1.com/index.html にアクセスし、index.html に http://common.com/writeHistory.html?domain=site1.com が含まれ、writeHistory.html が永続化されたデータに対する読み取りまたは書き込み操作を試みた場合、ブラウザまたは Flash Player はその操作を許可しません。これは、ユーザーがブラウザで閲覧しているのは common.com ではなく site1.com であり、common.com はサードパーティドメインであるためです。

allowScriptAccess のデフォルト値

Flash Player 6 以降では、HTML パラメータ allowScriptAccess がサポートされています。このパラメータは、SWF 内の ActionScript が、そのコンテナである HTML ページ内の JavaScript を呼び出すことができるかどうかを制御します。この逆に、JavaScript が ActionScript を呼び出す場合は、System.security.allowDomain で制御されます。

allowScriptAccess で指定できる値は次のとおりです。

always: ActionScript による JavaScript の呼び出しを常に許可します。
sameDomain: SWF と HTML ページのドメインが一致する場合にのみ、ActionScript による JavaScript の呼び出しを許可します。
never: ActionScript による JavaScript の呼び出しを常に許可しません。

Flash Player 6 および 7 では、allowScriptAccess のデフォルト値 (HTML ページで指定されない場合) は "always" でした。これとは別に、Flash HTML パブリッシュテンプレートでの allowScriptAccess のデフォルト値は、常に "sameDomain" でした。Flash HTML のパブリッシュ処理による出力を変更しない場合、HTML ページが "sameDomain" を指定するため、"sameDomain" の動作になります。

Flash Player 8 でも、Flash Player のメインの SWF がバージョン 7 以前である場合は、未指定の allowScriptAccess のデフォルト値は "always" になります。しかし、メインの SWF がバージョン 8 以降である場合は、このデフォルト値が "sameDomain" に変わります。

allowScriptAccess パラメータは、HTML が Flash コンテンツを含むことは許可しますが、HTML ページでスクリプトを実行することは許可しません。HTML ページのソースである Flash コンテンツが信頼性のないコンテンツである場合は、これが役に立ちます。たとえば、ユーザーが独自に作成する SWF 署名を含める可能性のあるフォーラムを管理しているときに、生成された HTML がこれらの SWF を直接ソースとして使用する場合は、これらの SWF が HTML ページでスクリプトを実行できないようにする方が安全です。

allowScriptAccess の指定方法の例を次に示します。

        <object
     classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000"
     codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0"
     width="375" height="300">
   <param name="movie" value="hello.swf">
   <param name="allowScriptAccess" value="sameDomain">
   <embed
       pluginspage="http://www.macromedia.com/go/getflashplayer"
       type="application/x-shockwave-flash"
       src="hello.swf"
       width="375" height="300"
       allowScriptAccess="sameDomain">
 </object>
          
    

allowDomain のワイルドカードのサポート

メモ : ここで説明する変更事項は、System.security.allowDomain() と System.security.allowInsecureDomain() の両方に適用されるものです。内容を明確にするために System.security.allowDomain についてのみ説明していますが、System.security.allowInsecureDomain() にも同じ変更事項が適用されます。System.security.allowInsecureDomain() を呼び出すと SSL (HTTPS) で提供されるセキュリティ機能が損なわれるため、Macromedia では、System.security.allowInsecureDomain() の呼び出しを推奨していません。

Flash Player 8 からは、System.security.allowDomain() に 1 つのアスタリスク "*" をワイルドカードとして使用できるようになりました。System.security.allowDomain("*") を呼び出すことによって、特定のドメインの SWF ではなく、すべてのドメインの SWF によるスクリプティングが許可されます。

保護しなければならない機密データがなく、他のドメインとデータを共有する必要がある場合は、このワイルドカードを使用すると便利です。ただし、System.security.allowDomain("*") を呼び出す前に、呼び出し元の SWF に、プライベートまたはセミプライベートに保つべき情報や ActionScript コードが含まれていないことを確認する必要があります。いったん System.security.allowDomain("*") を呼び出すと、悪意のある作成者が記述した SWF を含め、インターネット上のあらゆる場所にあるすべての SWF が、呼び出し元の SWF をロードしてスクリプティングすることができるようになります。

ただし、連携する SWF がどのドメインから提供されるのかが実行時までわからないとき (連携する SWF が負荷分散クラスタから提供される場合や、呼び出し元 SWF が多くの異なるドメインで使用される場合など) には、System.security.allowDomain() を呼び出すことが必要となります。このようなときに System.security.allowDomain("*") を呼び出すかどうかについては、よく注意して判断してください。前述のように、この呼び出しによって、インターネット上のすべての SWF が、呼び出し元の SWF をスクリプティングできるようになります。System.security.allowDomain("*") をすぐに呼び出すのではなく、連携する SWF がロードされるまで待ち、ActionScript プロパティ MovieClip._url を使用して、その SWF のドメインを判断するようにします。_url プロパティの値を System.security.allowDomain() に渡すと、参照先ムービークリップ内の SWF が、System.security.allowDomain() を呼び出した SWF をスクリプティングできるようになります。

Flash Player 8 では、すべてのバージョンの SWF が値 "*" を System.security.allowDomain() に渡すことができます。しかし、バージョン 8 より前の SWF で System.security.allowDomain("*") を呼び出す場合は、呼び出しを行う前に、プレイヤーのバージョン (System.capabilities.version) が 8 以上であることをテストで確認してください。バージョン 8 より前の Flash Player では、"*" が System.security.allowDomain の引数として認識されません。

より明確なアクセス許可

System.security.allowDomain() の呼び出しで確立されるアクセス許可には、2 つのパーティが関わってきます。System.security.allowDomain() を呼び出す SWF が "許可を与える側" のパーティであり、System.security.allowDomain() に渡される引数で指定されるドメインが "使用する側" のパーティです。このアクセス許可が確立されると、使用する側のドメインにあるすべての SWF が、許可を与える側の SWF をスクリプティングできるようになります。

Flash Player 6 および 7 では、使用する側のドメインにあるすべての SWF が、許可を与える側の SWF 自体だけではなく、許可を与える側の SWF のドメインにあるすべての SWF もスクリプティングすることができました。許可を与える側のパーティは、許可を与える側の SWF ではなく、許可を与える側のドメインであると解釈されました。たとえば、http://site1.com/app1.swf にある SWF が System.security.allowDomain("site2.com") を呼び出した場合、http://site2.com/another.swf にある SWF は、http://site1.com/app1.swf にある許可を与える側の SWF だけではなく、http://site1.com/different.swf など、site1.com からロードされる他のすべての SWF もスクリプティングすることができました。

これによって、予期しない結果が引き起こされる場合がありました。たとえば、site1.com の管理者が、互いに関係のない多くの異なる Flash アプリケーションを管理しており、一部のアプリケーションについては外部ドメインからのアクセスを許可する必要があるが、site1.com のすべてのアプリケーションについては外部ドメインからのアクセスを許可したくなかったとします。このような状況で、app1.swf の作成者が、System.security.allowDomain("site2.com") を呼び出すことによって app1.swf だけではなく different.swf にもアクセスを許可することになると気が付かなかった可能性があります。

バージョン 8 以降の SWF が System.security.allowDomain() を呼び出すときには、呼び出し元の SWF のみが許可を与える側の SWF になります。同じドメインにある 2 つの SWF の両方が外部ドメインからのアクセスを許可する場合は、それぞれの SWF が System.security.allowDomain() を呼び出す必要があります。

この処理が適用されるのは、バージョン 8 以降の SWF のみです。後方互換性を維持するため、バージョン 6 または 7 の SWF が System.security.allowDomain() を呼び出した場合、その SWF が Flash Player 8 で再生されている場合でも、それ自体のドメイン内にあるすべてのバージョン 6 または 7 の SWF にアクセスが許可されます。しかし、System.security.allowDomain() を呼び出したバージョン 6 または 7 の SWF によって、それ自体のドメイン内にあるバージョン 8 以降の SWF にアクセスが許可されることはありません。

System.exactSettings についても、同じ変更が加えられました。System.exactSettings は、SWF がカメラ/マイクのアクセス権や永続共有オブジェクトの基準として、Flash 6 形式のスーパードメイン (たとえば、mysite.com は www.mysite.com のスーパードメインになります) を使用するか Flash 7 形式の完全一致ドメイン (たとえば、www.mysite.com) を使用するかを判断します。Flash Player 7 では、1 つのドメイン内の 1 つの SWF が System.exactSettings の値を変更すると、同じドメイン内のすべての SWF にその変更が適用されました。バージョン 8 以降の SWF の場合、System.exactSettings の設定は、呼び出し元 SWF のみに適用されます。

永続共有オブジェクトの保護

Flash Player 8 以降では、永続共有オブジェクトに対して HTTPS URL の SWF が読み取りまたは書き込み操作を行うときに、HTTPS 経由で使用される SWF のみがアクセスできる、共有オブジェクトの別個の保存場所を使用するように指定できます。このような共有オブジェクトは、以下に仮定に基づいて説明する攻撃から保護されます。この HTTPS の要件を除き、保護された保存場所にある共有オブジェクトへのアクセスに適用される規則は、保護されない共有オブジェクトの場合と同じです。デフォルトでは、作成元と同じ URL を持つ SWF のみが共有オブジェクトにアクセスできますが、作成元が指定した localPath オプションが完全な URL よりも短い場合、同じ接頭辞ではじまる URL を持つ他の SWF も、同じ localPath を指定することによって共有オブジェクトにアクセスできます。

保護された共有オブジェクトの取得

保護された共有オブジェクトを取得するには、新しいオプションのパラメータ secure に true を指定して、SharedObject.getLocal() または SharedObject.getRemote() に渡します。

        static function getLocal(name:String, localPath:String, secure:Boolean) : SharedObject;
static function getRemote(name:String, remotePath:String, persistence:Object, secure:Boolean) : SharedObject;

リモートの共有オブジェクトの場合は Flash Media Server が必要です。リモートの共有オブジェクトは、Flash Media Server でのみドキュメント化されます。

たとえば、保護されたローカル共有オブジェクトを取得するには、次のように指定します。

var mySO = SharedObject.getLocal("userInfo", null, true);

localPath に null 値を指定すると、localPath をまったく指定しない場合と同じ結果になります。このため、デフォルトの localPath で保護された共有オブジェクトを取得する場合に、localPath に null 値を指定してください。

secure フラグのデフォルト値は false であり、バージョン 8 より前の Flash Player で作成された SWF にはこの新しい機能が適用されません。保護された共有オブジェクトを明確に要求する SWF のみが、新しい、保護された別個の保存場所を使用します。以前のバージョンの SWF で作成された共有オブジェクトはすべて、HTTPS であるかどうかに関係なく、元の保護されない保存場所に置かれます。

HTTPS 以外の URL の SWF が secure パラメータに true を指定した場合は、getLocal() または getRemote() 呼び出しで null が返されます。

保護された共有オブジェクトと保護されない共有オブジェクトは、それぞれ異なる保存場所に置かれています。このため、同じ名前、localPath、およびドメインを持つ 2 つの永続共有オブジェクト (1 つは保護された共有オブジェクトでもう 1 つは保護されない共有オブジェクト) を取得することが可能です。たとえば、HTTPS SWF が "userInfo" という名前で localPath が "/" である保護された共有オブジェクトを作成し、後で HTTP SWF が "userInfo" という名前で localPath が "/" である保護されない共有オブジェクトを取得した場合、これら 2 つの共有オブジェクトはそれぞれ異なる保存場所に置かれているため、後者の共有オブジェクトは前者の共有オブジェクトとは異なります。

保護された共有オブジェクトを使用する理由

保護された永続共有オブジェクトは、権限のないパーティによる仮想上の攻撃から保護されます。

HTTPS プロトコルによって、いくつかの重要な保護機能が提供されます。最もよく知られているのは、ネットワーク上のサードパーティがネットワーク通信の内容を見ることができないようにする "暗号化" 機能です。暗号化以外の重要な機能としては、"整合性" があります。この機能では、1 つのパーティが他のパーティにデータを送信するときに、そのデータが修正されることなく到着するか、修正された場合にはその修正を検知し、無効データとして拒否されるようにします。この機能は、インターネットの分散型性質を悪用する "介入者攻撃" と呼ばれる脅威から、データを保護するのに役立ちます。ネットワーク通信に関わるパーティ (インターネットサービスプロバイダの社員、ネットワークオペレータ、プロキシサーバー、ファイアウォールなど) は、ネットワーク通信を盗聴することだけではなく、ネットワーク通信でやり取りされるデータを修正し、送信元のパーティになり代わってアクションを起こす独自のドキュメントをデータに挿入することができます。たとえば、ユーザーが example.com にアクセスし、ログイン情報を求める SWF を表示した場合、介入者攻撃を行う攻撃者がほぼ同一の独自の SWF を使って、ユーザーのログイン情報を本来の受信者に送るだけではなく、攻撃者自身にも送るケースが考えられます。しかし、接続が HTTPS で保護されている場合は、介入者攻撃で修正された SWF をクライアントが受け取ったときにその SWF が拒否され、攻撃が失敗します。

他に考えられる同様の攻撃として、サーバーの識別に使用される DNS などのシステムの脆弱性を利用し、SWF を提供するサイトになりすまして行う攻撃があります。"認証" と呼ばれる HTTPS のもう 1 つの機能では、サーバーの識別検証に SSL 証明書を使用して、このような攻撃を阻止します。ここでは、介入者攻撃についてのみ説明しますが、この説明は介入者攻撃となりすまし攻撃の両方に当てはまります。

HTTPS 経由で SWF を提供し、永続共有オブジェクトをその SWF から記述する場合、記述した共有オブジェクト内のデータには、元の SWF と基本的にはユーザーだけがアクセスできるようにすることが望まれます。たとえば、口座情報や金融データなどの機密情報を、永続共有オブジェクトに記録する場合があります。このような状況で、たとえばユーザーの 1 人が介入者攻撃を受けた場合に、攻撃者がその共有オブジェクト内のデータにアクセスできないようにすることが求められます。

Flash Player 7 では、HTTPS SWF が共有オブジェクトを記述した後にあるユーザーが介入者攻撃を受けて、その共有オブジェクトへのアクセスが可能なサイトの URL (SWF が提供されるその URL など) にアクセスした場合、HTTPS ではなく HTTP を使用してアクセスしているという重大な相違があっても、攻撃者は独自の SWF を送ることができ、Flash Player ではその SWF が本来のサイトから送られたものであると認識してしまいました。攻撃者が送った SWF は、共有オブジェクトを読み取って、その内容を攻撃者に送り返すことができました。

当然、こうした攻撃を行うのは簡単ではありません。既に作成した HTTPS SWF が、永続共有オブジェクトに機密情報を書き込んでいた場合でも、何者かがこうした攻撃でその情報へのアクセスを試みた可能性は非常に低いと考えられます。しかし、永続共有オブジェクトに機密データを格納する場合、今後このような攻撃を受ける可能性をできる限り排除するには、保護された共有オブジェクトの使用を検討してください。

次の段階

世界で最も広く普及しているソフトウェアの 1 つである Flash Player は、その豊富なメディア機能、安定性、および信頼性によって、非常に多くのコンピュータやデバイスに導入されています。Flash Player 8 では、表現力に富む新機能や向上したパフォーマンスに加え、何億ものユーザーが Web サーフィンを行う際の保護機能も強化されています。これは非常に重要なことです。Flash Player は、ユーザーが個人情報を管理するのに役立つ信頼性の高いソフトウェアとして、セキュリティ専門家から高い支持を獲得し続けるでしょう。

ここで紹介したセキュリティ機能の強化には、リスクがまったくないわけではありません。世界中でやり取りされる何百万もの SWF のごく一部が、作成者が予測しなかった形で、まったく意図せずに、これらの新しいユーザー保護機能の影響を受ける可能性があります。Macromedia では、このような可能性を軽視せず、セキュリティ機能の変更による利益と損失の比較に多大な時間を費やしました。Flash は、"いったん導入したらその後は安心して使用できる" という、高い評価を確立することができました。Flash Player の新規リリースでは、最も古いバージョンの Flash コンテンツでも、最初にパブリッシュされたときと同じように再生できます。それでもなお、Macromedia では、Flash Player ユーザーに対する責任をまっとうします。ユーザーの信頼に値する製品でありつづけるために、今後も長期間にわたって Flash Player を機能豊富な安定したメディアとして提供できるように努力していきます。

Flash Player 8 のセキュリティ機能の変更点

著者 Deneb Meketa

Content

作成日

ページ ツール

タグ

必要条件

ユーザーレベル