Security  - AS3

特定の コンテンツ設定に使用するドメインを Flash Player または AIR がどのように選択するかを指定します。設定には、カメラとマイクの許可、記憶領域の割り当て、永続共有オブジェクトの記憶領域などがあります。Flash Player 6 で使用されていた設定と同じ設定を SWF ファイルで使用するには、exactSettings を false に設定します。

Flash Player 6 では、これらのプレーヤー設定に使用されていたドメインは、SWF ファイルのドメインの最後の部分に基づいていました。www.example.com のように SWF ファイルのドメインに 3 つ以上のセグメントが含まれている場合、ドメインの最初のセグメント（"www"）は削除され、ドメインの残りの部分 example.com が使用されます。したがって、Flash Player 6 における www.example.com と store.example.com では、どちらも example.com がこれらの設定のドメインとして使用されます。同様に、www.example.co.uk と store.example.co.uk はどちらも example.co.uk をこれらの設定のドメインとして使用します。Flash Player 7 以降では、プレーヤー設定はデフォルトで SWF ファイルの正確なドメインに従って選択されます。例えば、www.example.com の SWF ファイルは www.example.com のプレーヤー設定を使用し、store.example.com の SWF ファイルはそれとは別の store.example.com のプレーヤー設定を使用します。

Security.exactSettings が true に設定された場合、Flash Player または AIR は、プレーヤー設定に対して正確なドメインを使用します。exactSettings のデフォルト値は true です。exactSettings をデフォルト値から変更する場合は、Flash Player または AIR でプレーヤー設定を選択する必要があるイベントが発生する前に、その変更を行う必要があります。例えば、カメラまたはマイクの使用や永続共有オブジェクトの取得などのイベントの前です。

バージョン 6 の SWF ファイルをパブリッシュし、そのファイルから永続共有オブジェクトを作成しているときに、バージョン 7 以降にその SWF ファイルを移植した後で SWF ファイルからその永続共有オブジェクトを取得するか、バージョン 7 以降の別の SWF ファイルからその永続共有オブジェクトを取得する必要がある場合は、Security.exactSettings を false に設定してから SharedObject.getLocal() を呼び出します。

この swf を含む HTML ページのドメイン部です。

セキュリティ上の理由から、このメソッドは完全な URL を返さず、ページのドメインのみ（http://www.example.com など）を返します。この SWF が HTML ページに含まれていない場合、またはセキュリティ上の理由からページのドメインにアクセスできない場合、このプロパティは undefined という文字列を返します。

呼び出し元のファイルが動作しているセキュリティサンドボックスのタイプを示します。

Security.sandboxType は、次のいずれかの値になります。

• remote (Security.REMOTE) — この ファイルはインターネット URL からのものであり、ドメインベースのサンドボックス規則に従って機能します。
• localWithFile (Security.LOCAL_WITH_FILE) - このファイルはローカルファイルであり、信頼性はなく、ネットワークを指定してパブリッシュされた SWF ファイルではありません。ファイルは、ローカルのデータソースから読み取ることはできますが、インターネットでのやり取りはできません。
• localWithNetwork (Security.LOCAL_WITH_NETWORK) - この SWF ファイルはローカルファイルであり、信頼性はありませんが、ネットワークを指定してパブリッシュされています。この SWF ファイルはインターネットとのやり取りはできますが、ローカルデータソースからの読み取りはできません。
• localTrusted（Security.LOCAL_TRUSTED）- この ファイルはローカルファイルであり、信頼性があります。このファイルは Flash Player 設定マネージャーまたは FlashPlayerTrust 構成ファイルを使用します。 このファイルは、ローカルのデータソースから読み取ることも、インターネットでやり取りすることもできます。
• application（Security.APPLICATION）- このファイルは AIR アプリケーションで実行され、そのアプリケーションのパッケージ（AIR ファイル）と共にインストールされます。デフォルトでは、AIR アプリケーションサンドボックスのファイルは、任意のドメインの任意のファイルをクロススクリプトできます（ただし、AIR アプリケーションサンドボックス外のファイルでは、AIR ファイルをクロススクリプトできない場合があります）。デフォルトでは、AIR アプリケーションサンドボックスのファイルは、任意のドメインからコンテンツおよびデータを読み込むことができます。

セキュリティについて詳しくは、Flash Player デベロッパーセンターのトピック：セキュリティを参照してください。

関連する API エレメント

指定したドメインの SWF ファイルから、allowDomain() 呼び出しを含む SWF ファイルのオブジェクトと変数にアクセスできるようにします。

注意：AIR アプリケーションサンドボックスのコードからこのメソッドを呼び出すと、SecurityError 例外がスローされます。アプリケーションセキュリティドメイン外のコンテンツは、アプリケーションサンドボックスのコンテンツを直接クロススクリプトできません。ただし、アプリケーションサンドボックス外のコンテンツは、サンドボックスブリッジを使用してアプリケーションセキュリティサンドボックス内のコンテンツと通信できます。

2 つの SWF ファイルが同じドメインに所属している場合（例えば、http://mysite.com/swfA.swf および http://mysite.com/swfB.swf）、swfA.swf で swfB.swf 内の変数、オブジェクト、プロパティ、メソッドなどを調査、変更でき、swfB.swf でも swfA.swf に対して同様のことを実行できます。これは、クロスムービースクリプトまたはクロススクリプトと呼ばれます。

2 つの SWF ファイルが異なるドメインに所属している場合（例えば http://siteA.com/swfA.swf および http://siteB.com/swfB.swf）、デフォルトでは、swfA.swf で swfB.swf をスクリプトすることも、swfB.swf で swfA.swf をスクリプトすることも許可されません。SWF ファイルは、Security.allowDomain() を呼び出すことで他のドメインの SWF ファイルに許可を付与します。これをクロスドメインスクリプトと呼びます。Security.allowDomain("siteA.com") を呼び出すことで、siteB.swf によって siteA.swf に siteB.swf をスクリプトする許可が付与されます。

クロスドメインの場合は、関与する 2 つのドメインを明確にすることが重要です。説明のため、ここでは、クロススクリプトを実行する側をアクセス元（通常、アクセスする SWF）と呼び、他をアクセス先（通常、アクセスされる SWF ファイル）と呼びます。siteA.swf が siteB.swf をスクリプトする場合、siteA.swf がアクセス元で、siteB.swf がアクセス先となります。

allowDomain() を使用して確立されるクロスドメイン許可は、非対称です。前の例では、siteA.swf は siteB.swf をスクリプトできますが、siteB.swf は siteA.swf をスクリプトできません。siteA.swf で、siteA.swf をスクリプトする許可を siteB.com の SWF ファイルに付与するための allowDomain() を呼び出していないためです。対称的な許可を設定するには、両方の SWF ファイルで allowDomain() を呼び出すようにする必要があります。

Flash Player では、SWF ファイルを他の SWF ファイルによるクロスドメインスクリプトから保護するだけでなく、HTML ファイル によるクロスドメインスクリプトからも保護します。HTML から SWF へのスクリプトは、SetVariable などの古いブラウザーの関数を使用するか、ExternalInterface.addCallback() で確立したコールバックを使用することで実行できます。HTML から SWF へのスクリプトがドメインを横切る場合、アクセス先 SWF ファイルは、アクセス元が SWF ファイルの場合と同様に、allowDomain() を呼び出す必要があります。それ以外の場合、操作は失敗します。

allowDomain() にパラメーターとして IP アドレスを指定しても、指定された IP アドレスに存在するすべてのアクセス元からのアクセスが許可されるわけではありません。許可されるのは、その IP アドレスにマッピングされるドメイン名ではなく、指定された IP アドレスが URL に含まれるアクセス元からのアクセスだけです。

バージョン固有の相違点

Flash Player のクロスドメインセキュリティ規則は、バージョンを追うごとに発展してきました。次の表は、相違点をまとめたものです。

Flash Player の動作を制御するバージョンは、Flash Player 自身のバージョンでなく、SWF バージョン（SWF ファイルのパブリッシュバージョン）です。例えば、Flash Player 8 でバージョン 7 用にパブリッシュされた SWF ファイルを再生する場合、バージョン 7 と一貫した動作が適用されます。これによって、アップグレードしても、デプロイされた SWF ファイル内の Security.allowDomain() の動作は変更されなくなります。

前の表のバージョン列は、クロススクリプト操作に関係する最新の SWF のバージョンを示しています。Flash Player の動作は、アクセス元 SWF ファイルまたはアクセス先 SWF ファイルのバージョンのいずれか新しい方のバージョンによって決まります。

次の段落では、Security.allowDomain() に関係する Flash Player のセキュリティ機能の変更について詳細に説明します。

バージョン 5 : クロスドメインスクリプトの制限はありません。

バージョン 6 : クロスドメインスクリプトのセキュリティが導入されました。デフォルトでは、クロスドメインスクリプトは禁止されています。Security.allowDomain() で許可できます。2 つのファイルが同じドメインに属しているかどうかを判別するため、各ファイルのスーパードメインが使用されます。このスーパードメインは、ファイルの URL の完全なホスト名から最初のセグメントを除き、最低 2 セグメントにまでしたものです。例えば、www.mysite.com のスーパードメインは、mysite.com となります。www.mysite.com の SWF ファイルと store.mysite.com の SWF ファイルは、Security.allowDomain() を呼び出さずに、お互いをスクリプトします。

バージョン 7 : スーパードメイン一致が、完全なドメイン一致に変更されました。2 つのファイルでお互いにスクリプトの実行が許可されるのは、それらの URL のホスト名が同じ場合だけです。それ以外の場合は、Security.allowDomain() を呼び出す必要があります。デフォルトでは、HTTPS 以外の URL からロードしたファイルは、まったく同じドメインからファイルをロードしたとしても、HTTPS の URL からロードしたファイルをスクリプトできません。この制限は HTTPS ファイルの保護に役立ちます。HTTPS 以外のファイルは、ダウンロード中に変更されやすく、HTTPS 以外のファイルが悪意を持って変更されると、このような不正操作を受けにくい HTTPS ファイルを破損させる可能性があります。アクセス先の HTTPS SWF ファイルが自発的にこの制限を無効にできるように、Security.allowInsecureDomain() を導入しましたが、Security.allowInsecureDomain() を使用しないことをお勧めします。

バージョン 8 : 2 つの主要な変更点は次のとおりです。

• Security.allowDomain() を呼び出した場合、アクセス先 SWF ファイルが Security.allowDomain() を呼び出した SWF ファイルであるときにのみ、クロススクリプト操作が許可されるようになりました。つまり、Security.allowDomain() を呼び出した SWF ファイルのみが、自身へのアクセスを許可できるようになりました。前のバージョンでは、Security.allowDomain() を呼び出した場合に、アクセス先 SWF ファイルが Security.allowDomain() を呼び出した SWF ファイルと同じドメインにある SWF ファイルであれば、クロススクリプト操作が許可されていました。前のバージョンでは、Security.allowDomain() を呼び出すと、呼び出し元 SWF ファイルのドメイン全体が開きました。
• Security.allowDomain("*") および Security.allowInsecureDomain("*") では、ワイルドカード値のサポートが追加されました。ワイルドカード（*）値を使用すると、アクセス元ファイルがどこからロードされたかを問わず、任意のファイルでクロススクリプト操作を許可できます。ワイルドカードは、グローバル許可と考えてください。ワイルドカード許可は、ローカルファイルセキュリティ規則の下で特定の操作を有効にする場合に必要となります。具体的には、ローカル SWF ファイルで、その SWF ファイルにインターネット上の SWF ファイルをスクリプトするネットワークアクセス許可がある場合、アクセス先のインターネット SWF ファイルは、ローカル SWF ファイルの出所が不明であることを反映して、Security.allowDomain("*") を呼び出す必要があります。インターネット SWF ファイルが HTTPS URL からロードされる場合は、インターネット SWF ファイルでは、代わりに Security.allowInsecureDomain("*") を呼び出す必要があります。

場合によっては、他のドメインから子 SWF ファイルをロードし、その子 SWF ファイルで親 SWF ファイルをスクリプトしたいが、子 SWF ファイルの最終的なドメインがわからないという状況になることがあります。例えば、ロードバランシングリダイレクトやサードパーティー製サーバーを使用する場合などです。

この状況では、Loader.load() に渡す URLRequest オブジェクトの url プロパティを使用できます。例えば、子 SWF ファイルを 親 SWF にロードする場合、親 SWF の Loader オブジェクトの contentLoaderInfo プロパティに次のようにアクセスできます。

Security.allowDomain(loader.contentLoaderInfo.url)

url プロパティの正しい値を取得するために、子 SWF ファイルのロードが開始されるまで待つようにしてください。子 SWF のロードがいつ開始されたかを確認するには、progress イベントを使用します。

この反対の状況が発生する場合もあります。つまり、親 SWF ファイルで子 SWF ファイルをスクリプトしたいが、親 SWF ファイルのドメインがわからない場合です。この状況では、SWF のルートオブジェクトである表示オブジェクトの loaderInfo プロパティにアクセスできます。子 SWF で、Security.allowDomain( this.root.loaderInfo.loaderURL) を呼び出します。親 SWF ファイルがロードされるまで待つ必要はありません。親 SWF ファイルは子 SWF ファイルがロードされた時点で既にロードされています。

Flash Player 8 以降用にパブリッシュする場合、Security.allowDomain("*") を呼び出すことによってこのような状況を処理することもできます。ただし、これは危険な近道になりかねません。任意のドメインの任意の他の SWF ファイルから呼び出し元 SWF ファイルにアクセスできるようになるためです。通常、_url プロパティを使用した方が安全です。

セキュリティについて詳しくは、Flash Player デベロッパーセンターのトピック：セキュリティを参照してください。

パラメーター

関連する API エレメント

指定したドメイン内の SWF ファイルおよび HTML ファイルが、HTTPS プロトコルでホストされた呼び出し元 SWF ファイルのオブジェクトと変数にアクセスすることを許可します。

Flash Player では柔軟性を最大化するために allowInsecureDomain() が用意されていますが、このメソッドは呼び出さないことをお勧めします。 HTTPS を介してファイルを提供すると、開発者やユーザーに対して複数の保護機能を提供できますが、allowInsecureDomain の呼び出しによって、これらの保護機能は脆弱になります。

注意：AIR アプリケーションサンドボックスのコードからこのメソッドを呼び出すと、SecurityError 例外がスローされます。アプリケーションセキュリティドメイン外のコンテンツは、アプリケーションサンドボックスのコンテンツを直接クロススクリプトできません。ただし、アプリケーションサンドボックス外のコンテンツは、サンドボックスブリッジを使用してアプリケーションセキュリティサンドボックス内のコンテンツと通信できます。

このメソッドは、Security.allowDomain() と同様に機能します。ただし、アクセス元が HTTPS 以外のプロトコルでロードされ、アクセス先が HTTPS でロードされる操作も許可します。Flash Player 7 以降では、HTTPS 以外のファイルで、HTTPS ファイルをスクリプトすることは許可されません。アクセス先 HTTPS SWF ファイルで allowInsecureDomain() メソッドを使用すると、この制限が解除されます。

HTTPS 以外のファイルから HTTPS ファイルへのスクリプトを有効にする場合にのみ、allowInsecureDomain() を使用してください。アクセス元の HTTPS 以外のファイルとアクセス先の HTTPS ファイルが、同じドメインに所属しているときのスクリプト（例えば、http://mysite.com にある SWF ファイルで https://mysite.com にある SWF ファイルをスクリプトする場合）を有効にするために使用します。HTTPS 以外のファイル間でのスクリプト、HTTPS ファイル間でのスクリプトまたは HTTPS ファイルから HTTPS 以外のファイルへのスクリプトを有効にするためには使用しないでください。このような状況では、代わりに allowDomain() を使用します。

次の情報は、考えられるシナリオのうちの 1 つで、クロススクリプトの実際例を通じて allowInsecureDomain() を理解できるように設計されています。セキュリティアーキテクチャに関する問題をすべて取り上げているわけではなく、背景情報としてのみ使用する必要があります。Flash Player デベロッパーセンターには、Flash Player およびセキュリティに関する広範な情報があります。詳細については、Flash Player デベロッパーセンターのトピック：セキュリティを参照してください。

次の 2 つのコンポーネントから構成される e-コマースサイトを構築するシナリオについて考えてみます。1 つはカタログで、公開情報しか含まれていないため、保護する必要はありません。もう 1 つは、ショッピングカート/チェックアウトコンポーネントで、ユーザーの財務情報と個人情報を保護するためにセキュリティで保護する必要があります。ここで、カタログのサービスは http://mysite.com/catalog.swf から、カートのサービスは https://mysite.com/cart.swf から提供するものとします。このサイトの 1 つの要件として、第三者がセキュリティアーキテクチャの脆弱性を利用して、ユーザーのクレジットカード番号を盗むことができないことが挙げられます。

ここで、中間当事者である攻撃者がサーバーとユーザーの間に介入して、ユーザーがショッピングカートアプリケーションに入力したクレジットカード番号を盗もうとするとします。中間当事者としては、一部のユーザーが利用している悪質な ISP、ユーザーの職場にいる悪意がある管理者など、パブリックインターネット経由で送信されるネットワークパケットをユーザーとサーバー間で表示または変更できるものが考えられます。この状況は珍しいことではありません。

cart.swf で HTTPS を使用してクレジットカード情報をサーバーに送信している場合、中間当事者の攻撃者は、HTTPS 送信が暗号化されているため、ネットワークパケットから直接この情報を盗むことができません。ただし、攻撃者は別の手法を使用できます。それは、いずれかの SWF ファイルの内容をユーザーへの配信時に変更し、その SWF ファイルを（ユーザー情報を攻撃者が所有する別のサーバーに送信する）改変バージョンと置き換えるという手法です。

HTTPS プロトコルは、何よりもまずこの "変更" 攻撃を防止します。暗号化されているだけでなく、HTTPS 送信に不正操作防止機能が付いているためです。中間当事者の攻撃者がパケットを変更すると、受信側はその変更を検出し、パケットを廃棄します。このため、この状況で攻撃者は cart.swf を変更できません。このファイルが HTTPS 経由で配信されるからです。

ところで、HTTP 経由で提供される catalog.swf 内のボタンで、HTTP 経由で提供される cart.swf 内のショッピングカートにアイテムを追加できるようにしたいとします。この機能を実現するために、cart.swf で allowInsecureDomain() を呼び出します。これで、catalog.swf は cart.swf をスクリプトできます。ただし、このアクションでは、予期しない結果が発生します。この場合、攻撃者は、catalog.swf をユーザーが最初にダウンロードする際、その内容を変更できます。catalog.swf は HTTP で配信され、不正操作防止機能が付いていないためです。攻撃者が変更した catalog.swf は、これで cart.swf をスクリプトできるようになります。cart.swf に allowInsecureDomain() への呼び出しが含まれているためです。変更された catalog.swf ファイルは、ActionScript を使用して、cart.swf 内の変数にアクセスできるため、ユーザーのクレジットカード情報やその他の機密データを読み取ることができます。その後、変更された catalog.swf は、このデータを攻撃者のサーバーに送信できます。

この実装は明らかに好ましいものではありませんが、サイト上の 2 つの SWF ファイル間でクロススクリプトを許可したい場合があります。次に、この仮想の e-コマースサイトを再設計して allowInsecureDomain() を除外する方法として、考えられる方法を 2 つ示します。

• アプリケーション内のすべての SWF ファイルを HTTPS 経由で提供します。これは最も単純で信頼性が高いソリューションです。説明したシナリオでは、catalog.swf と cart.swf の両方を HTTPS 経由で提供します。catalog.swf などのファイルを HTTP から HTTPS に切り替える際、帯域幅の使用量とサーバーの CPU 負荷が少し上がり、ユーザー側では、アプリケーションのロード時間がやや長くなる可能性があります。実際のサーバーで実験して、これらの影響の重大度を判別する必要があります。通常は、それぞれ 10 ～ 20% 程度で、まったく影響がないこともあります。サーバーにある HTTPS 加速ハードウェアやソフトウェアを使用すると、通常は結果を改善できます。関係するすべての SWF ファイルを HTTPS 経由で提供する主要なメリットは、ブラウザーから内容が混在した警告を生成せずに、HTTPS URL をユーザーのブラウザー内の主要な URL として使用できることです。また、ブラウザーのカギのアイコンが表示されるため、セキュリティに関する共通の信頼できるインジケーターがユーザーに提供されます。
• HTTP から HTTPS へのスクリプトでなく、HTTPS から HTTP へのスクリプトを使用します。説明したシナリオでは、ユーザーのショッピングカートの内容を catalog.swf に保存し、cart.swf でチェックアウトプロセスのみ管理させることができます。チェックアウト時に、cart.swf で、catalog.swf 内の ActionScript 変数からカートの内容を取得できます。HTTP から HTTPS へのスクリプトに関する制限は非対称的なものです。HTTP 経由で提供される catalog.swf ファイルが HTTPS 経由で提供される cart.swf ファイルをスクリプトすることは安全上許可されませんが、HTTPS 経由で提供される cart.swf ファイルは HTTP 経由で提供される catalog.swf ファイルをスクリプトできます。このアプローチは、すべて HTTPS 経由のアプローチよりも微妙な点があります。不正操作を受けやすいため、HTTP 経由で提供される SWF ファイルは信頼しないように注意する必要があります。例えば、cart.swf でカートの内容を記述した ActionScript 変数を取得する際、cart.swf 内の ActionScript コードで、この変数の値が期待した形式になっていると信頼することはできません。カートの内容を確認して、cart.swf に好ましくないアクションを実行させる無効なデータが含まれていないことを調べる必要があります。また、中間当事者が catalog.swf を変更して、例えば、ユーザーのカートにアイテムを入れることにより、有効だが不正確なデータを cart.swf に提供する危険性を甘受する必要があります。通常のチェックアウトプロセスでは、カートの内容と合計金額を表示してユーザーに最後の承認を求めることで、この危険性をいくぶん緩和していますが、それでも危険性は残っています。

Web ブラウザーでは、長年にわたり HTTPS ファイルと HTTPS 以外のファイルの分離を強制してきました。説明したシナリオでは、この制限が必要であることの 1 つの理由が明確に示されています。Flash Player では、絶対必要な場合、このセキュリティの制限を回避できますが、それを実行する前に結果を慎重に検討する必要があります。

セキュリティについて詳しくは、Flash Player デベロッパーセンターのトピック：セキュリティを参照してください。

パラメーター

関連する API エレメント

url パラメーターで指定された場所でポリシーファイルを探します。Adobe AIR および Flash Player は、ポリシーファイルを使用して、アプリケーションが自身のサーバー以外のサーバーからデータをロードしてよいかどうか判断します。メソッド名は loadPolicyFile() ですが、ネットワー要求によってポリシーファイルが要求されるまではファイルは実際にはロードされません。

Security.loadPolicyFile() によって、Flash Player または AIR では任意の場所からポリシーファイルをロードできるようになります。次に例を示します。

     Security.loadPolicyFile("http://www.example.com/sub/dir/pf.xml");
     

これにより、Flash Player または AIR は指定された URL からポリシーファイルを取得しようとします。この場所に置かれているポリシーファイルによって得られる許可は、サーバーの仮想ディレクトリ階層で同レベル以下のコンテンツすべてに適用されます。

例えば、前のコードに続くこれらの行によって例外はスローされません。

 import flash.net.*;
     var request:URLRequest = new URLRequest("http://www.example.com/sub/dir/vars.txt");
     var loader:URLLoader = new URLLoader();
     loader.load(request);
     
     var loader2:URLLoader = new URLLoader();
     var request2:URLRequest = new URLRequest("http://www.example.com/sub/dir/deep/vars2.txt");
     loader2.load(request2);
     

ただし、次のコードではセキュリティ例外がスローされます。

 import flash.net.*;
     var request3:URLRequest = new URLRequest("http://www.example.com/elsewhere/vars3.txt");
     var loader3:URLLoader = new URLLoader();
     loader3.load(request3);
     

loadPolicyFile() を使用して、任意の数のポリシーファイルをロードできます。ポリシーファイルを必要とする要求がある場合、Flash Player または AIR はポリシーファイルのダウンロードがすべて完了するまで必ず待機します。その間に要求が拒否されることはありません。loadPolicyFile() で指定されたポリシーファイルによって要求が許可されなかった場合は、最終的にデフォルトの場所が参照されます。

マスターポリシーファイルのチェックを行うとき、Flash Player はサーバーの応答を 3 秒間待機します。 応答がない場合、Flash Player ではマスターポリシーファイルが存在しないと判断されます。しかし、loadPolicyFile() の呼び出しのデフォルトタイムアウト値はありません。Flash Player では、呼び出されているファイルが存在するものとして、そのファイルをロードするのに必要なだけ待機します。したがって、マスターポリシーファイルを確実にロードするには、loadPolicyFile() を使用し、明示的に呼び出します。

一般的な予約ポートには接続できません。遮断されたポートの詳しいリストについては、『ActionScript 3.0 開発ガイド』の「ネットワーク API の制限」を参照してください。

特定のポート番号で xmlsocket プロトコルを使用することで、直接 XMLSocket サーバーからポリシーファイルを取得することができます。次に例を示します。ソケット接続は、上記のよく予約されるポートに関する制限事項の対象外です。

     Security.loadPolicyFile("xmlsocket://foo.com:414");
     

このコードを使用すると、Flash Player または AIR は指定されたホストとポートからポリシーファイルを取得しようとします。指定されたポートを使用して接続が確立されると、Flash Player または AIR は <policy-file-request /> を送信します（これは、null バイトで終了します）。ポリシーファイルを終了するためにサーバーから null バイトを送信し、それ以降の接続を閉じる必要があります。サーバー側で接続を閉じなければ、最後の null バイトが受信されるとすぐに Flash Player 側または AIR 側で接続が閉じられます。

SWF ファイルがこのメソッドを使用しないようにするには、allowNetworking パラメーター（SWF コンテンツを含んでいる HTML ページの object タグおよび embed タグのパラメーター）を設定します。

セキュリティについて詳しくは、Flash Player デベロッパーセンターのトピック：セキュリティを参照してください。

パラメーター

Flash Player のセキュリティ設定パネルを表示します。このメソッドは Adobe AIR のコンテンツに適用されません。AIR アプリケーションでこのメソッドを呼び出しても無効です。

パラメーター

関連する API エレメント

このファイルは AIR アプリケーションで実行され、そのアプリケーションのパッケージ（AIR ファイル）と共にインストールされます。このコンテンツは AIR アプリケーションリソースディレクトリ（アプリケーションコンテンツのインストール先）に含まれています。

関連する API エレメント

このファイルはローカルファイルであり、信頼性があります。このファイルは Flash Player 設定マネージャーまたは FlashPlayerTrust 構成ファイルを使用します。このファイルは、ローカルのデータソースから読み取ることも、インターネットでやり取りすることもできます。

関連する API エレメント

このファイルはローカルファイルであり、信頼性はなく、ネットワークを指定してパブリッシュされた SWF ファイルではありません。Adobe AIR では、ローカルファイルはアプリケーションリソースディレクトリにはありません。これらのファイルはアプリケーションセキュリティサンドボックスに配置されます。 ファイルは、ローカルのデータソースから読み取ることはできますが、インターネットでのやり取りはできません。

関連する API エレメント

このファイルはローカルファイルであり、信頼性はありませんが、ネットワークを指定してパブリッシュされた SWF ファイルです。このファイルはインターネットとのやり取りはできますが、ローカルデータソースからの読み取りはできません。

関連する API エレメント

このファイルはインターネット URL からのものであり、ドメインベースのサンドボックス規則に従って機能します。

関連する API エレメント