Adobe
サインイン 注文状況 マイアカウント

著者 Deneb Meketa

Deneb Meketa
  • Adobe

Content

更新日

28 October 2008

ページ ツール

タグ

ユーザーレベル

中級

2008年4月にリリースされたFlash Player 9 セキュリティアップデータの仕様変更について記述されております。
「2008年４月のFlash Player 9のセキュリティアップデートについて」も併せてご確認ください。

注：この記事では、Flash Player 9 Update 3（9.0.115.0）、Flash Player 9 April 2008 Security Update（9.0.124.0）、およびFlash Player 10.0（10.0.2.xx）について解説します。

注: この記事は2008年７月に更新されています。更新前のバージョンの記事を閲覧したユーザにとって重要な変更点は、次の３点です。Flash Player 9.0.124.0には、ソケット接続に対する完全に厳密な制限動作（フェーズ1.5）が実装されています。Flash Player 10.0からは、この新しい制限のフェーズ２が実装されています。そして最後に、フェーズ２のデフォルトURLメタポリシーは、最も厳格な制約である「none」から、より緩やかな「master-only」に変更されています。これにより、URLマスターポリシーファイル（/crossdomain.xmlに配置されたポリシーファイル）は、新たなmeta-policyを追加することなく従来通りに機能します。

2003年に、Flash Player 7ソフトウェアでは、ポリシーファイルによるドメイン間の直接データロード許可というクライアントとサーバ間の通信チャネルがWebの新機能として導入されました。 ポリシーファイルが導入される前、Webコンテンツで実行できたのは、ランタイム設定やページをリロードしないトランザクションなど、ホストサーバとの双方向通信のみでした。 ポリシーファイルにより、サーバは他のドメイン（つまり、通常は任意の場所）のクライアントコンテンツにデータを選択的に開放できるようになりました。 ポリシーファイルの導入により、リッチなインターネットアプリケーションの作成者にとってドメイン境界は大きな障害ではなくなりました。

ほとんどの新しいテクノロジと同様に、ポリシーファイルは最初の導入時には完全なものではありませんでした。 導入から４年が経過し、ポリシーファイルには、インターネットセキュリティ上の問題点が２点あることが判明しました。これらの問題についてはこの記事で追って説明します。 ポリシーファイルの基本前提は今でも有効であり、Flash開発者はFlash 6以降と同じように引き続きポリシーファイルを使用できます。ただし、新たに見つかった問題点に対応するために、アドビではポリシーファイルの使用についていくつかの厳密なルールを定めています。 また、ポリシーファイルを便利で使いやすいものにするために、様々な改善も行われています。 これらの変更が行われた理由をわかりやすく簡単に説明します。

この記事では、読者がポリシーファイルに関してある程度知識をお持ちであることを前提としています。 ポリシーファイルの詳細については、Adobe LiveDocs「ActionScript 3.0のプログラミング」の「Flash Playerセキュリティ」の章、別途記事「Flash Playerのクロスドメインポリシーファイル推奨使用法」*、および別途記事「クロスドメインポリシーファイルの仕様」を参照してください。また、この記事では取り上げていない、ポリシーファイルのHTTPヘッダ送信権限について詳しくは、別途記事の「2008年４月のFlash Player 9のセキュリティアップデートについて」を参照してください。

Webサイトにおいて必要な対策

厳密なルールに準拠するために、ポリシーファイルを提供するWebサイトにはいくつかの小さな変更が必要になります。 これらの変更は、主にサイト自体を保護するためのものであり、基本的には、ポリシーファイルに関する新しいセキュリティ上のベストプラクティスになります。

ほとんどのサイトでは、変更は困難ではないと予想されますが、影響が及ぶサイトが多数あるため、アドビではFlash Playerの厳密な要件を3段階のフェーズで導入しています。 フェーズ１（Flash Player 9.0.115.0から開始）では、少数の厳密なルールは直ちに強制されますが、ルールに違反しても、ほとんどの場合はFlash Playerのデバッグバージョンで警告が表示されるだけです。 フェーズ1.5（Flash Player 9.0.124.0から開始）では、ソケット接続の場合に限りフェーズ１の警告がエラーになるようになりました。フェーズ２（Flash Player 10.0から開始）では、フェーズ１のすべての警告がエラーとなり、厳密なルールが完全に適用されるようになります。

Webサイトの管理者は次の手順に従うことをお勧めします。

  1. 即時： 即時かつ厳密な対処に関する節を読んだ後、即時解決を要する問題を診断および修正するためのワークフロー手順を実行します。 この手順は、Flash Player互換コンテンツ（SWFファイル）を提供するサイトにのみ適用されます。この手順を追うことで、フェーズ１の影響に対処できます。
  2. 即時： ソケットポリシーファイルに関する節を読んだ後、ソケットポリシーファイルを設定するためのワークフロー手順を実行します。 この手順は主に、既にソケットポリシーファイルを提供しているサイトが適用の対象となりますが、ポリシーファイルまたはSWFファイルがないサイトの防御策としても役立ちます。この手順を追うことで、フェーズ1.5の影響に対処できます。
  3. 時間がある場合：メタポリシーに関する節を読んだ後、メタポリシーを選択および設定するためのワークフロー手順を実行します。 この手順は主に、既にポリシーファイルを提供しているサイトが適用の対象となりますが、ポリシーファイルまたはSWFファイルがないサイトの防御策としても役立ちます。この手順を追うことで、フェーズ２の影響に対処できます。

対応済みの問題

厳密なポリシーファイルルールは、次の２つの問題に対応しています。

ポリシーファイル管理。ポリシーファイルではないと思われるサーバ上のファイルが、ポリシーファイルとして使用されている可能性があります。 例えば、サーバでユーザによるアップロードが許可されているが、クロスドメインアクセス用にデータが開かれることが意図されていない場合、ユーザが意図的にポリシーファイルを作成し、ポリシーファイルを別の種類のファイル（普通のテキスト、XML、HTMLなどのファイル）、またはバイナリファイル（PNGやJPEGなどのイメージファイル）と偽装する可能性があります。 この偽装されたポリシーファイルをアップロードしたユーザが、偽装されたポリシーファイルを利用してサーバのドメインの外部からデータをロードするSWFファイルを作成する可能性があります。 同様に、権限が制限されているサイトの保守担当者が、管理者の意に反してサイトにポリシーファイルを追加したり、意図しないポリシーファイルを誤って作成したりする可能性もあります。 これは基本的に、サーバ上に配置することが許可されるポリシーファイルの管理方法に関する問題です。 サーバ管理者は、ポリシーファイルでサーバ全体のポリシー（メタポリシーと呼びます）を設定し、サーバ上のすべてのポリシーファイルを簡単に検索して、サーバに存在するすべてのクロスドメイン許可を監査できる必要があります。 Flash Playerの厳密なポリシーファイルルールにより、サーバ管理者によるメタポリシーの宣言が可能になり、ポリシーファイルが正常かどうかをチェックして、適切な形式かどうかを確認できます。

DNS強化。DNSリバインディングと呼ばれる種類のクロスサイトスクリプティング攻撃は、Flash Player以外に、ブラウザ、仮想マシン、およびその他のユーザエージェントプログラムを対象とする可能性があります。 DNSリバインディング攻撃は、ユーザエージェントの同一生成元ポリシー（same-origin policy）を悪用します。この攻撃では、特定のインターネットドメインのコンテンツが、明示的な許可なしでそのドメイン内の他のリソースをロードしたり、それらのリソースと通信したりすることが許可されます。 独自のドメインを管理し、独自のDNSサーバを実行している攻撃者は、そのDNSサーバを動的に再設定して、特定のドメイン名が自分の管理下にあるIPアドレス（悪意のあるSWFファイルやその他のコンテンツの提供に使用される可能性があります）にいったん解決された後で、自分の管理下にない別のIPアドレスに解決されるようにする可能性があります。 ユーザエージェントプログラムでIPアドレスの変更が検出されない場合、同一生成元ポリシーにより、２番目のホストからの許可がなくても、攻撃者のコンテンツが２番目のIPアドレスにアクセスすることが許可されます。 Flash Playerはブラウザに依存してHTTPネットワークを提供しているため、HTTPのみに関連するリバインディングの脆弱性はブラウザで解決する必要があります。 ただし、Flash Playerにはソケットレベルネットワーク（ActionScriptのSocketクラスおよびXMLSocketクラスを使用）が用意されており、Flash Player 9.0.115.0の厳密なポリシーファイルルールにより、ソケットに関連する場合はDNSリバインディングの脆弱性を緩和できます。 特に、厳密なルールにおいては、接続しているSWFファイルの送信元ドメインがソケットサーバと同じと思われる場合でも、ソケット接続を確立するために、常にソケットポリシーファイルからの許可が必要です。 また、Flash Playerバージョン9.0.115.0以降では、ドメイン名だけでなくIPアドレスに基づいて、ソケット接続を対応するソケットポリシーファイルと照合しています。

その他の改善点

上記の問題に対応すると同時に、ポリシーファイルをより便利に簡単に使うための新機能も追加されました。

  • Flash Playerのデバッグバージョンからのポリシーファイルイベントの詳細ログ。 ポリシーファイルのロードと処理、およびそのポリシーファイルに依存する操作が失敗したか正常に終了したかは、すべて報告されます。 これは、厳密なルールへの移行だけでなく、ポリシーファイル展開に関連する問題の検出や解決にも役立ちます。
  • 固定されたソケットマスターポリシーファイルポート（TCPポート843）。ソケットポリシーファイルの検出時にデフォルトで参照されます。 これにより、以前に使用されていた「任意のポートを選択する」システムではなく、標準的な方法でソケットポリシーファイルを提供できます。
  • ローカルソケットの強力なクライアント認証を必要とするオプション。 localhostソケットから提供されるソケットポリシーファイルは、以前はHTTPSポリシーファイル用に予約されていたsecure="true"宣言を使用して、特定のドメインのHTTPS SWFのみ接続するように指定できます。 これにより、オンラインのFlashコンテンツをネイティブのローカルアプリケーションと結び付ける、安全なハイブリッドアプリケーションが実現します。

即時かつ厳密な対処のための動作の変更点

Flash Player 9.0.115.0のポリシーファイルに関する変更点は、開発者のみに警告を発するものが大半であったため、SWFアプリケーションが即座に、意図どおりに動作しなくなる可能性は最低限に抑えられていました。 このような即時の変更は、正規のコンテンツでは発生する可能性が低いと考えられる動作パターンのみに適用されるよう配慮されていました。 しかし、正規のコンテンツに一切の影響が及ばないというわけではありませんでした。

即時かつ厳密な対処から発生する問題の検出と修正の段階的な説明については、即時解決を要する問題に対するワークフローを参照してください。 ただし、影響を受ける開発者（SWFコンテンツの担当者）は、この概要の節を最初に読むことをお勧めします。

不正な形式のポリシーファイル

この記事で説明しているその他の変更点とは異なり、不正な形式のポリシーファイルに対するFlash Playerの制限はバージョン9.0.115.0の新機能ではありません。これらの制限は、9.0.47.0以降で実施されています。ただし、バージョン9.0.115.0以降では、新しいログメカニズムにより、これらの制限から生じる問題が見つけやすくなります。

現在、Flash Playerでは、コンテンツが適切な形式ではないポリシーファイルは拒否されます。 無効な形式が作成される原因は、次のとおりです。

  • 開始タグ<cross-domain-policy>の前、または終了タグ</cross-domain-policy>の後にある、無関係な先頭または末尾のコンテンツ（XMLコメントおよび宣言以外のもの）。 このような無関係なコンテンツにより、実際にはファイルは無効なXMLドキュメントになります。
  • <cross-domain-policy>以外のトップレベルXMLタグ。
  • 任意のタグ内のテキスト（コメント以外）。

Flash Playerで不正な形式のポリシーファイルが拒否されるようになったことは、ポリシーファイル管理に関する改善点の一例です。 不正な形式のポリシーファイルは、Webサイト管理者がポリシーファイルとして使用可能であると見なしていないファイルをFlash Playerが取り扱っている可能性を示す場合があります。

アドビでは、ユーザが必要に応じてポリシーファイルのタグと形式を検証するために使用できる、XMLスキーマのドキュメントを提供しています （これはオプションの手順であり、XMLスキーマのドキュメントに詳しくない場合は、スキップしても支障はありません）。 スキーマの場所は次のとおりです。

PolicyFile.xsdはすべてのポリシーファイルに使用できる汎用的なスキーマです。 その他の４つのスキーマは、様々なプロトコル用のポリシーファイルのシンタックスを制限します。

即時かつ厳密な対処に関するすべての問題と同様に、即時解決を要する問題に対するワークフローに従って、SWFコンテンツが不正な形式のポリシーファイルの影響を受けるかどうかを判断します。 不正な形式のポリシーファイルのレポートがログで見つかった場合は、開発者（または影響を受けるポリシーファイルの管理担当者）はポリシーファイルを編集し、無関係なコンテンツの削除、スペルミスの削除などを実行します。

ドメイン内のリダイレクト

ポリシーファイルが導入されて以来、ポリシーファイルが要求されたときにHTTPサーバが別のドメインへのリダイレクトを返した場合、Flash Playerは常にポリシーファイルを無視してきました。 ただし、ドメイン内のリダイレクトは許可されていましたし、ポリシーファイルの要求が同じサーバ上の別の場所にリダイレクトされた場合でも、ポリシーファイルの有効な場所は最初に要求されたURLであると見なされていました。 ポリシーファイルの有効な場所が重要なのは、この場所がポリシーファイルのスコープ、つまりポリシーファイルがアクセスを許可するリソースのセットを示しているためです。 例えば、 http://example.com/directory1/crossdomain.xml にあるポリシーファイルは、 http://example.com/directory1/ およびその下にあるリソースへのアクセスを許可しますが、 http://example.com/elsewhere/など、同じサーバ上の別の場所にあるリソースへのアクセスは許可しません。サイト上の有効なアクセス許可を予測するのが困難になるため、通常はポリシーファイルのリダイレクトを使用しないことをお勧めします。

Flash Playerバージョン9.0.115.0以降では、同じドメインのリダイレクトを含むポリシーファイルを引き続き受け入れますが、リダイレクトされたポリシーファイルの有効な場所として、最初のURLではなく最終的なURLを使用します。 例えば、場所 http://example.com/forks/crossdomain.xml のリダイレクト先が http://example.com/spoons/crossdomain.xmlである場合、作成されたポリシーファイルは http://example.com/spoons/ およびその下の場所へのアクセスを許可しますが、 http://example.com/forks/の下の場所へのアクセスは許可しません。

Flash Playerで最終的なリダイレクト先のURLが使用されるようになったことは、ポリシーファイル管理に関する改善点の一例です。 管理者は、サーバ上のポリシーファイルアクセス許可のセットを簡単に確認できる必要があります。 ただし、リダイレクトの最初のURLを有効な場所として使用した場合、リダイレクトを作成することで、サイト上のどの場所でもポリシーファイルの存在をシミュレートできます。 最終的なURLのみを有効な場所として使用することで、意図したポリシーファイルのみが使用されるようになります。 リダイレクトによりサイト上のアクセス許可が変更されることはなく、既に設定されているポリシーファイルがロードされるだけです。

ポリシーファイルがリダイレクトされることはまれですが、即時かつ厳密な対処に関するすべての問題と同様に、即時解決を要する問題に対するワークフローに従って、SWFコンテンツがポリシーファイルのリダイレクトの影響を受けるかどうかを判断してください。 ポリシーファイルのリダイレクトのレポートがログで見つかった場合、それ自体は必ずしもコンテンツが目的どおりに機能しないことを示すわけではありません。ただし、このログは、後で、許可されるはずの操作が許可されなかった場合、問題解決の手がかりとなる可能性があります。

特に問題となるのは、 /crossdomain.xmlにあるマスターHTTPポリシーファイルの場所の要求をリダイレクトするときです。これにより、リダイレクト先のポリシーファイルのステータスがマスターファイルではなくなります。 その後、そのサイトはマスターポリシーファイルを一切使用できなくなるため、メタポリシーの宣言のような一般的な操作が実行できなくなります。

Content-Typeのホワイトリスト

Flash Playerバージョン9.0.115.0以降では、ファイルの種類がテキストファイルであることを示すContent-Type値を使用して送信されていないHTTPポリシーファイルは無視されます。 Flash Playerでは、ポリシーファイルのContent-Typeは次のいずれかである必要があります。

  • text/*（任意のtextタイプ）
  • application/xmlまたはapplication/xhtml+xml

Content-Type値は、HTTPサーバが提供する応答ヘッダによって決まります。 サーバは、ファイル名、拡張子、場所、コンテンツ、またはファイルを生成するサーバスクリプトの命令に基づいて、Content-Typeを選択します。 ポリシーファイルに関連付けられたContent-Typeを変更する必要がある場合は、レジストリマッピングファイル名の拡張子をContent-Type値に再設定するか、一般的なサーバ構成ファイルを編集する必要があります。 HTTPサーバのドキュメントを参照してください。

即時かつ厳密な対処に関するすべての問題と同様に、即時解決を要する問題に対するワークフローに従って、SWFコンテンツがテキスト以外のContent-Type値の影響を受けるかどうかを判断し、一般的なHTTPサーバプラットフォームでContent-Type値を変更するための手順を実行します。 Content-Typeの問題を解決する必要がある場合は、メタポリシーに関する節も必ず参照してください。これは、メタポリシーを選択するには、すべてのポリシーファイルに対して特別なContent-Type（text/x-cross-domain-policy）を指定するのが一般的なためです。これにより、メタポリシーを設定し、テキストのContent-Typeを指定するという２つの問題を同時に解決できます。

Flash PlayerでテキストのContent-Type値が必要になったことは、ポリシーファイル管理に関する改善点の一例です。 テキスト以外のContent-Typeを含むポリシーファイルは、Webサイト管理者がポリシーファイルとして使用可能であると見なしていないファイルをFlash Playerが取り扱っている可能性を示す場合があります。

ブラウザ内でFlash Playerを実行する場合、Content-Typeのホワイトリストの適用は、Flash PlayerがブラウザのネットワークスタックからHTTP応答ヘッダを読み取ることができるかどうかによって決まります。 最新のブラウザはこれに対応していますが、一部の古いブラウザは対応していません。 HTTP応答ヘッダをサポートしているブラウザ、およびサポートしていないブラウザのリストについては、付録Aを参照してください。 Flash PlayerでHTTP応答ヘッダを読み取ることができない場合は、ポリシーファイルログに警告メッセージが生成され、Content-Typeに関係なく、また、Content-Typeがまったくない場合でも、ポリシーファイルが受け入れられます。

即時に適用される厳密なソケット

注：この節のコンテンツは、過去の情報を公開する目的でのみ提供されています。ポリシーファイル規則の厳格化フェーズ1.5が導入されたFlash Player 9.0.124.0のリリース以降、ソケット接続はすべて、この厳密な規則に基づいて処理されるようになっています。この節では、Flash Playerバージョン9.0.115.0と9.0.124.0の違いのみを解説していますが、9.0.124.0以降のバージョンに対応するソケットサーバ管理者にとっては、さほど重要な情報ではない可能性があります。

Flash Playerバージョン9.0.115.0以降では、ソケットポリシーファイルに対して一連の厳密なルールが定義されます。 ソケットポリシーファイルは、ソケットサーバへのActionScript言語による接続を許可します。 厳密なルールの詳細については、ソケットポリシーファイルの節で説明していますが、簡単に言うと、ActionScriptソケット接続を確立するためにソケットポリシーファイルからの許可が常に必要であるというルールです。 以前のルールでは、SWFファイルは、ポリシーファイルがない独自のドメイン内にある番号の大きいポートへのソケット接続を確立できました。また、HTTPポリシーファイルのみに基づいて番号の大きいソケットポートに接続できました。 厳密なソケットルールでは、このような状況は許可されなくなります。

ほとんどのソケットサーバでは、厳密なルールが２段階の フェーズで導入されました。フェーズ１では、ルールに違反した場合、ホストが新たなルールの即時的な適用を選択していない限り、警告メッセージのみが生成されていました。 ただし、いくつかの特殊なソケットでは、フェーズ１でも厳密なルールが直ちに適用されました。具体的には、以下のケースがこの特殊なソケットに該当します。

  • Flash Playerが実行されているローカルマシン上のソケット。ただし、ActionScriptでlocalhostと識別されるソケットは例外です。 ローカルソケットとは、ループバックアドレス（IPv4の場合は127.0.0.1、IPv6の場合は::1）、およびローカルに割り当てられた外部アドレス（イーサネットアダプタに割り当てられたアドレスなど）のソケットです。 このルールは、Flash PlayerのDNS強化に関する改善点の一例です。 厳密なソケットルールを選択する方式は、サーバホストには適していますが、ほとんどのユーザがサーバとして扱っていないローカルマシンには適していません。 このルールにより、不正なDNSサーバが（SWFファイルを提供するために）ホスト名をいったんリモートアドレスに解決してから、（ローカルサービスに接続するために）ローカルアドレスに解決することを防止できます。 特別な名前であるlocalhostは、このルールからは除外されます。これは、一般的にリモートDNSがlocalhostの解決に関与する可能性がないためです。
  • リンクローカルIPアドレスのソケット。ただし、ActionScriptで*.localと識別される（名前が.localで終わる）ソケットは例外です。 リンクローカルIPアドレスとは、１つのリンク（ポイントツーポイント接続やネットワークハブなどの１つのネットワークセグメント）でのみ割り当てられるアドレスです。 多くの場合、リンクローカルアドレスは「ゼロ設定」のピアツーピアネットワークに使用されます。 リンクローカルアドレスの形式は、IPv4の場合169.254.*、IPv6の場合fe80:*です。 これは、上記のローカルアドレスの場合と非常に似ています。 .localは、通常はリモートDNSが.localアドレスの解決に関与する可能性がないために除外されています。
  • 1024以上のポート上のソケットで、独自のソケットポリシーファイルを提供し、ポリシーファイルコンテンツに独自のドメインをリストしていないソケット。 これは、実際には個別のルールではなく、厳密なソケットルールを選択した結果です。 独自のソケットポリシーファイルを提供するソケットでは、自動的に新しいルールが選択されます。 SWFファイルが古いルールに従って、独自のドメイン内にあるこのようなソケットへの接続を確立する場合、ポリシーファイルは必要ではありませんが、厳密なルールに従う場合は、ソケットポリシーファイルが必要になります。 ソケットが提供するソケットポリシーファイルに独自のドメインがリストされていない場合、同じドメインのSWFファイルは接続できない可能性があります。

即時かつ厳密な対処に関するすべての問題と同様に、即時解決を要する問題に対するワークフローに従って、SWFコンテンツが即時に適用される厳密なソケットの影響を受けるかどうかを判断し、検出された問題を修正するための手順を実行します。

メタポリシー

Flash Player 9.0.115.0におけるポリシーファイル管理機能の向上をサポートする主な変更点は、メタポリシーが追加されたことです。 メタポリシーは「ポリシーに対するポリシー」、つまり、サーバ管理者がサーバ上に存在することを許可したポリシーファイルを指定したものです。

サーバのメタポリシーの選択に関する手順の説明については、メタポリシーのワークフローを参照してください。 ただし、サーバの管理者は、先にこの概要の節に目を通すことをお勧めします。 管理対象のサーバでFlash Player互換コンテンツを提供する予定がない場合でも、この節を読むことをお勧めします。そのようなサーバでもポリシーファイルベースの攻撃を受ける可能性はあります。

メタポリシーを使用する理由

ポリシーファイル管理の改善点の説明で述べたように、メタポリシーの目標は、適切な権限によって作成されたポリシーファイルのみを使用することです。 ただし、メタポリシーの選択にあたっては、ポリシーファイルの機能、および許可されていないポリシーファイルが及ぼす影響を理解することが重要です（図１を参照）。

ポリシーファイルを使用したデータフロー
図１.ポリシーファイルを使用したデータフロー

この図では、サイトb.comはa.comのアクセスを許可するポリシーファイルをホストしています。 つまり、a.comのSWFファイルは、b.comサイトの一部またはすべてから直接データをロードできます（ロードできるデータの範囲は、ポリシーファイルの場所によって異なります）。

b.comの管理者は、ポリシーファイルを慎重に扱う必要があります。これは、ポリシーファイルにより、他のドメインのSWFファイルに対してb.comへのアクセス時にユーザの資格情報を使用して動作する許可が付与されるためです。 上記の図では、ユーザはa.comのSWFファイルを参照しています（１）。または、a.comのSWFファイルは他のサイトc.com（図には表示されていません）に埋め込まれている可能性もあります。 a.comのSWFファイルは、b.comのポリシーファイルを使用して、b.comからデータをロードするアクセス許可を取得します（２）。 これで、b.comへのアクセスをユーザに許可する資格情報を利用して、SWFファイルはb.comからデータをロードできます（３）。 必要であれば、SWFファイルはb.comで見つかったデータを、SWFファイルをホストしているa.comのサーバにアップロードできます（４）。

ここでは、a.comサーバがb.comに直接アクセスする場合のアクセス資格情報と、ユーザがb.comに対して保持しているアクセス資格情報を比較することが重要です。 ユーザとb.comの両方がネットワークファイアウォールの内側にあるためにユーザがb.comにアクセスできる場合、またはログインによりHTTP Cookieを受信したためにユーザがb.comにアクセスできる場合、ユーザの権限はa.comサーバよりも強くなります。 この状況では、b.com上にポリシーファイルを作成するのは危険を伴う可能性があります。これは、a.comのSWFファイルは、b.com、ユーザまたはその両方のプライベートなデータを公開しないことについて信頼されている必要があるためです。

ポリシーファイルにこのようなデータの脆弱性が発生する可能性がある場合、サーバ管理者が、ポリシーファイルの作成を制限できること（これにより脆弱性が回避されます）、およびサーバ上のすべてのポリシーファイルをいつでも簡単に検索できること（これにより現在のアクセス許可のセットを監査できます）が重要です。 管理者権限がない担当者によるコンテンツの提供を許可するサーバもあれば、エンドユーザが定義したコンテンツを提供するサーバもあります。 通常は、このようなコンテンツ提供者がポリシーファイルを作成できる状態は適切ではありません。

このような場合にメタポリシーが役に立ちます。 適切なメタポリシーを選択することで、管理者はポリシーファイルの作成を完全に禁止するか、すべての場所でポリシーファイルの作成を許可するか、その中間の方法として、基準に適合した特定のポリシーファイルのみを許可するかを選択できます。

メタポリシーは、Flash Player互換コンテンツを提供しないと想定されるサーバにも役に立ちます。 b.comがファイアウォールの内側のHTML専用サーバで、あるユーザが何かしらの方法でb.com上にポリシーファイルを作成したとします。この場合、b.comへのアクセス権を持つユーザが、インターネット上の任意のサイトa.comのSWFファイルを表示すると、a.comのSWFファイルは、b.comからデータを取得しようとします。 b.comがインターネット上のサーバで、ログイン資格情報を受け入れる場合も同じ論理が適用されます。 このように、b.comがFlash Player互換コンテンツを提供すると想定されていない場合でも、メタポリシーを宣言すると役に立ちます （このようなサーバに適切なメタポリシーはnoneで、そのサーバでのポリシーファイルの存在を禁止します）。

メタポリシーのスコープ

メタポリシーを宣言できるサーバは次のとおりです。

  • HTTPサーバとHTTPSサーバ。 各サーバは独自のメタポリシーを宣言します。この宣言は、他のサーバには影響しません。 例えば、ポート80のHTTPサーバのメタポリシーはそのサーバにのみ影響し、同じホスト上のポート8080のHTTPサーバには影響しません。 同様に、HTTPサーバのメタポリシーは同じホスト上のHTTPSサーバには影響しません。その逆も同様です。
  • FTPサーバ。 各サーバは独自のメタポリシーを宣言します。
  • ホスト全体がソケットメタポリシーを宣言できます。このポリシーは、すべてのポートでそのホストへの低レベルのソケット接続を管理します。 低レベルのソケット接続とは、ActionScriptのSocketクラスおよびXMLSocketクラスを使用して開始される接続です。 HTTPサーバおよびFTPサーバへの高レベルの接続では、SocketとXMLSocket以外のActionScript APIが使用され、ソケットメタポリシーの影響を受けることはなく、関与する特定のサーバのメタポリシーの影響のみを受けます。 HTTP、HTTPSおよびFTPの各メタポリシーをソケットメタポリシーと区別するために、URLメタポリシーと呼ぶこともあります。 ソケットメタポリシーの詳細については、ソケットポリシーファイルの節を参照してください。

現在、上記の種類以外のサーバでは、メタポリシーの宣言、またはポリシーファイルの作成は不要です。 Flash Playerネットワークプリミティブで許可されるのは、HTTP、HTTPSおよびFTPの各サーバへのソケットレベルでの直接接続のみです。 SWFファイルはソケットレベル接続を使用して他のタイプのサーバに接続できますが、この場合、Flash Playerは上位のプロトコルを認識しないため、ポリシーファイルは上位レベルではなくソケットレベルでチェックされます （Flash Playerでは、RTMPプロトコルファミリを使用してFlash Media Serverへの接続も許可しますが、RTMPではセキュリティの動作が異なり、Flash Playerではなくサーバでセキュリティに関する決定を行います）。

メタポリシーのオプション

使用可能なメタポリシーは次のとおりです。

  • all： すべてのポリシーファイルが許可されます。 このメタポリシーは、ログイン資格情報を必要とするコンテンツを提供しないインターネット上のサーバにのみ適用できます。
  • by-content-type： Content-Typeがtext/x-cross-domain-policyのすべてのポリシーファイルが許可されます。 その他のポリシーファイルは許可されません。 このメタポリシーは、HTTPサーバおよびHTTPSサーバにのみ使用できます。 ほとんどのHTTPサーバはContent-Typeの割り当て方法を柔軟に決定できるため、ポリシーファイルごとに許可を設定する場合には最も便利なオプションです。 text/x-cross-domain-policyタイプを割り当てるには、一般に、個々の場所に対してこのタイプを指定するか、またはtext/x-cross-domain-policyをcrossdomain.xmlという名前のファイルに割り当てます。前者の場合は、ポリシーファイルごとに管理者の承認が必要です。後者の場合は、ポリシーファイルが任意の場所に配置されますが、このようなファイルを検索したり、アップロードやその他のコンテンツ作成プロセスでフィルタすることが容易になります。
  • by-ftp-filename： crossdomain.xmlという名前のすべてのポリシーファイル（つまり、URLが /crossdomain.xmlで終わるポリシーファイル）が許可されます。 その他のポリシーファイルは許可されません。 このメタポリシーは、FTPサーバにのみ使用できます。 必須のファイル名をカスタマイズすることはできません。
  • master-only： マスターポリシーファイル（ /crossdomain.xmlにあります）のみが許可されます。
  • none： ポリシーファイルは許可されません。 このメタポリシーをマスターポリシーファイル内で宣言すると、そのマスターポリシーファイルは、このメタポリシーを宣言する目的でのみ存在することになり、<allow-access-from>ディレクティブが含まれていても無視されます。
  • none-this-response： これは、HTTP応答ヘッダでのみ指定できる特別なメタポリシーです。 この特定のHTTP応答がポリシーファイルと解釈されないようにすることができます。 他のすべてのメタポリシーとは異なり、none-this-responseは、サーバ全体に対するメタポリシーを宣言するのではなく、１つのHTTP応答にのみ影響します。 また、他のすべてのメタポリシーとは異なり、none-this-responseは他のメタポリシーと組み合わせて競合せずに使用できます。 none-this-responseと別のメタポリシーの両方が存在する場合、現在のHTTP応答はポリシーファイルになることはできませんが、追加のメタポリシーはサーバ全体に対するメタポリシーであると解釈されます。 none-this-responseメタポリシーが主に役に立つのは、ポリシーファイルの生成を許可したくないスクリプトがサーバに含まれる場合です。 通常、スクリプトは出力のContent-Typeを選択し、任意のHTTP応答ヘッダを生成できるため、スクリプト出力をフィルタして、出力が適正なポリシーファイルを表すかどうかを確認するのは困難です。 代わりに、none-this-responseメタポリシーヘッダを出力に追加することで、スクリプトの出力内容にかかわらず、有効なポリシーファイルが生成されないことを確認できます （また、スクリプトで独自のメタポリシーHTTP応答ヘッダが生成されても、管理者が指定したメタポリシー以外のオープンなメタポリシーを採用するようにサーバに強制することはできません。これは、最も制限の高いメタポリシーを選択することで、常にメタポリシーの競合が解決されるためです）。

メタポリシーの指定方法

HTTPサーバ、HTTPSサーバ、またはFTPサーバでメタポリシーを宣言するには、２つの方法があります（ソケットポリシーファイルは動作が異なります）。

  • そのサーバのマスターポリシーファイルでメタポリシーを宣言します。ポリシーファイルは /crossdomain.xmlにあります。<site-control>という新しいタグを、トップレベルの<cross-domain-policy>タグの内側に配置し、この<site-control>タグのpermitted-cross-domain-policies属性で、使用される特定のメタポリシーを指定します。 メタポリシーby-content-typeを宣言するポリシーファイルの例を次に示します。
<cross-domain-policy> <site-control permitted-cross-domain-policies="by-content-type"/> </cross-domain-policy>
  • X-Permitted-Cross-Domain-PoliciesというHTTP応答ヘッダで、メタポリシーを宣言します。 このオプションはFTPサーバでは使用できません。 このヘッダを有効にするためには、すべてのHTTP応答と共に返す必要があります。これは、要求がポリシーファイルに対するものかどうかを検出する信頼できる方法がないためです。 メタポリシーnoneを宣言するHTTP応答ヘッダの例を次に示します。
HTTP/1.1 200 OK X-Permitted-Cross-Domain-Policies: none

（一方がnone-this-responseの場合のみ有効な）２つのメタポリシーを指定する必要がある場合は、X-Permitted-Cross-Domain-Policiesヘッダを２回指定するか、メタポリシー値をセミコロンで区切ったヘッダを１回指定します。 どちらの指定もHTTPヘッダでは標準的な方法です。

メタポリシーを宣言するには、上記２つの方法のうち１つのみを選択する必要があります。 ただし、誤って両方の場所でメタポリシーを宣言した場合、HTTP応答ヘッダで宣言したメタポリシーが、マスターポリシーファイルで宣言したメタポリシーよりも優先されます。

２つの方法のそれぞれに利点があります。 考慮事項は次のとおりです。

マスターポリシーファイルでメタポリシーを宣言する場合の利点

  • 通常は、新しいHTTP応答ヘッダを返すよりも、マスターポリシーファイルを編集する方が簡単です。
  • マスターポリシーファイルの使用は、HTTPとFTPの両方に有効です。
  • マスターポリシーファイルの使用により、サーバからのすべてのHTTP応答にヘッダを追加する必要がなくなります。

HTTP応答ヘッダでメタポリシーを宣言する場合の利点

  • サーバのドキュメントルートディレクトリで常にマスターポリシーファイルを作成できるとは限りません。
  • マスターポリシーファイルでメタポリシーが宣言された状態で、マスター以外のポリシーファイルが要求された場合、Flash Playerはマスター以外のポリシーファイルを受け入れる前にマスターポリシーファイルを取得する必要があります。 一方、HTTP応答ヘッダでメタポリシーが宣言された場合、マスターポリシーファイルに対する要求は不要です。
  • HTTP応答ヘッダでメタポリシーを宣言する必要があるサーバ構成は、通常は１つのサーバ構成ファイルで管理でき、提供するドキュメントコンテンツを変更する必要がないものです。
  • none-this-responseメタポリシーを指定すると、ポリシーファイルを生成するスクリプトの機能を制御できます。

HTTPサーバおよびHTTPSサーバについては、 HTTP応答ヘッダまたはマスターポリシーファイルでメタポリシーを明示的に宣言せずに、Content-Typeがtext/x-cross-domain-policyのポリシーファイルを返すと、Flash Playerではメタポリシーがby-content-typeであると見なされるというルールを認識しておく必要があります。 これは、メタポリシーの宣言に適した方法ではありませんが、誤ってこの状況に陥った場合に備えて、ここに記載しています。

デフォルトのメタポリシー

サーバがメタポリシーを宣言しない場合、次の２つの結果が考えられます。

  • Flash Player 9.0.115.0から導入されたフェーズ１では、デフォルトのメタポリシーはallです。 このフェーズでは互換性が優先されるため、メタポリシーが明示的に選択されるまでサイトは影響を受けません。
  • Flash Player 10.0から導入されるフェーズ２では、デフォルトのメタポリシーはmaster-onlyになります。 このフェーズではセキュリティが優先されるため、最新のFlash Playerリリースによっていずれかのコンテンツがポリシーファイルと解釈される前に、サイトはメタポリシーを明示的に選択する必要があります。

ブラウザ内でFlash Playerを実行する場合、メタポリシーの適用は、Flash PlayerがブラウザのネットワークスタックからHTTP応答ヘッダを読み取ることができるかどうかによって決まります。 最新のブラウザはこれに対応していますが、一部の古いブラウザは対応していません。 HTTP応答ヘッダをサポートしているブラウザ、およびサポートしていないブラウザのリストについては、付録Aを参照してください。 Flash PlayerでHTTP応答を読み取ることができない場合は、ポリシーファイルログに警告メッセージが生成され、すべてのドメインでメタポリシーallの適用が想定されます。 Flash PlayerがHTTP応答ヘッダを読み取ることができない場合、allメタポリシーの宣言は無視されます（HTTP応答ヘッダではなくマスターHTTPポリシーファイルに表示される宣言も含みます）。

対策が必要な理由

サーバでメタポリシーを宣言するのには２つの理由があります。

  • サーバがマスター以外のポリシーファイルを提供し、管理者がこれらのポリシーファイルを許可するメタポリシーを宣言しなかった場合、当該ポリシーファイルは、フェーズ２バージョンの Flash Player（Flash Player 10.0以降）をインストールするユーザには適用されなくなります。
  • サーバがポリシーファイル、またはFlash Player互換コンテンツを意図的に提供するかどうかに関係なく、サーバでテキストファイルを作成できるユーザはポリシーファイルを作成できます。このポリシーファイルを使用すると、サーバまたはユーザ（あるいはその両方）のプライベートなデータを公開できます。 メタポリシーの宣言により、フェーズ１バージョンのFlash Playerのユーザには、デフォルトのメタポリシーallは適用されなくなります。

URLメタポリシーの宣言のワークフローでは、メタポリシーを選択および適用するために必要な手順を示します。

ソケットポリシーファイル

ActionScriptのネットワーク接続は、通常、URLに基づき、HTTP、HTTPS、およびFTPを使用して行われます。 しかし、ActionScriptでは、下位のTCPソケットレベルで直接的にネットワーク接続を行うことができるSocketクラスとXMLSocketクラスもサポートされています。 URLによるネットワーク接続は、URLポリシーファイルによって承認されますが、ActionScriptのソケットレベル接続は、ソケットポリシーファイルによって承認されます。

Flash Player 9.0.115.0および9.0.124.0では、ソケットポリシーファイルの機能が、部分的に変更されています。 これらの変更は、主にDNS強化という目標を達成するためのもので、ActionScriptを利用したDNSリバインディング攻撃によって、不正なソケット接続が行われないようにすることを目的としています。

有効なソケットポリシーファイル構成をホストに実装するための簡単な手順については、ソケットポリシーファイルのワークフローを参照してください。 ただし、サーバホストの管理者は、先にこの概要の節に目を通すことをお勧めします。 管理対象のホストでFlash Player互換コンテンツを提供する予定がない場合でも、一読することをお勧めします。そのようなホストでも、ソケットベースのDNSリバインディング攻撃を受ける可能性はあります。

ここでは、メタポリシーの節の内容を前提としているため、必ずメタポリシーの節を先にお読みください。

ソケットポリシーファイルの背景

ここでは、Flash Player 7.0.19.0でソケットポリシーファイルが導入されたときから変更されていない情報を示します。

ソケットポリシーファイルの目的は、URLポリシーファイルと同様、 クライアントコンテンツからの接続を承認することです。 URLポリシーファイルは、提供元のHTTP、HTTPS、またはFTPの各サーバからのデータロードの承認に使用されますが、ソケットポリシーファイルは、提供元のホストへのソケット接続の承認に使用されます。

注：「URLポリシーファイル」、「URLメタポリシー」などの用語は、HTTP、HTTPS、およびFTPを通じたネットワーク接続を表しています。 ソケットポリシーファイルの場所も、「xmlsocket: URL」のようにURLを使用して表現される場合がありますが（ActionScriptからloadPolicyFileを呼び出す場合）、ここでは便宜的に上記のような表現を使用します。

すべてのポリシーファイルには、許可（接続を承認するドメインのリスト）、およびスコープ（アクセス許可の対象となる一連のリソース）の２つの必須属性が含まれます。 ソケットポリシーファイルは、許可に関してはURLポリシーファイルと同様に機能しますが、スコープに関してはURLポリシーファイルとは仕組みが異なります。

URLポリシーファイルのスコープは、ポリシーファイルの場所によって決まりますが、ソケットポリシーファイルのスコープは、ファイルの内容によって決まります。つまり、to-ports属性によって、ソケット接続を許可するTCPポートを指定します。

ソケットポリシーファイルは、ホスト上の任意のTCPポートから提供できますが、ポート1024以上のポートからロードされるソケットポリシーファイルでは、ポート1024以上のポートに対する接続のみ承認できます。 1024より小さい番号のポートから読み込まれるソケットポリシーファイルでは、ホスト上の任意のポートに対する接続を承認できます。

ソケットポリシーファイルは、メイン接続（ActionScriptによって行われるソケット接続で、ソケットポリシーファイルによって承認される）と同じポートから提供することも、メイン接続とは別のポートから提供することもできます。 ソケットポリシーファイルをメイン接続と同じポートから提供する場合は、そのポートをリッスンしているサーバがソケットポリシーファイル要求を認識し（Flash Playerから<policy-file-request/>で転送を指定）、ポリシーファイル要求とメイン接続要求を区別して応答できるようにする必要があります。 通常は、ソケットポリシーファイルを別のポートから提供する方が簡単です。これにより、ホストのソケットポリシーを１か所で集中管理できます。また、ほとんどのサーバには、自身のソケットポリシーファイルを提供する機能が備わっていません。

ソケットマスターポリシーファイル

ポリシーファイルが最初に導入されて以来、Flash Playerでは、 crossdomain.xml をURLポリシーファイルのマスター場所として認識していました。 しかし、バージョン9.0.115.0より前のFlash Playerでは、ソケットポリシーファイルの固定のマスター場所を認識していませんでした。 Flash Player 9.0.115.0では、ソケットマスターポリシーファイルという概念を導入し、このファイルを固定のTCPポート番号843から提供します。

ソケットマスターポリシーファイルを使用することにより、次のような様々なニーズに対応できます。

  • ポート番号を固定することで、ソケットポリシーをホストから提供するための標準的な方法が確立されます。 以前は、各ホストの管理者が自分でソケットポリシーファイルの提供ポートを決定する必要がありました。 固定のポート番号が与えられたことで、スタンドアロンのソケットポリシーファイルサーバをポート843にデフォルトでバインドできるため、管理者は慣れないコンピュータでもソケットポリシーを簡単に見つけることができます。
  • マスター場所が決定されたことで、ソケットメタポリシーを宣言できるようになりました。 ソケットメタポリシーは、以前説明したURLメタポリシーと同様、ホスト上に配置できるソケットポリシーファイルの種類を制御するためのものです。 これについては、後述のソケットメタポリシーに関する節で詳しく説明します。
  • ソケットポリシーファイルをポート843から提供することで、Flash Playerのフェーズ１バージョンでも、ホスト管理者が新しいソケットルールの使用を選択できるようになります。 これについては、後述の「厳密なソケットルールの使用」の節で詳しく説明します。
  • マスター場所を固定することで、ActionScriptでloadPolicyFileを呼び出してFlash Playerにソケットポリシーファイルの場所を指示しなくても、自動的にソケットポリシーファイルが呼び出されます。

注：アドビでは、ソケットポリシーファイルサーバに関する情報ページを公開する予定です。 このページでは、ソケットポリシーファイルの提供だけを行うサーバを作成するための手順やサンプルコードを紹介します。

アドビでは、IANA（Internet Assigned Numbers Authority）に対し、TCPポート843をソケットポリシーファイルの提供用に予約するよう申請しています。 これには時間がかかることが予想されますが、その間にポート843の使用目的に関する文書をできる限り広く公開したいと考えています。

ポート番号843は1024よりも小さいため、ソケットマスターポリシーファイルでは、ホスト上の任意のポートに対するアクセスを承認できます。 Unixスタイルのホストでは、通常、サーバを1024未満のポートにバインドするにはルートアクセス（管理者権限）が必要なため、1024の境界は重要な意味を持ちます。つまり、Unixスタイルのホストでソケットマスターポリシーファイルをセットアップするには、通常はルートアクセスが必要になるため、ホストを有効に保護できます。

ソケットマスターポリシーファイルをファイアウォール経由で提供する場合は、ファイアウォールのトラバースに関する問題についての節を参照してください。

ソケットメタポリシー

ソケットメタポリシーは、URLメタポリシーと同様の機能を果たします。 ただし、次のような違いがあります。

  • ソケットメタポリシーは、URLポリシーファイルではなく、ソケットポリシーファイルを対象としています。 ソケットメタポリシーは、１つのURLサーバだけではなく、ホスト全体を対象としています。
  • ソケットメタポリシーは、ソケットマスターポリシーファイル内でのみ宣言できます。 シンタックスは、URLマスターポリシーファイルでのメタポリシーの宣言と同様、<site-control>タグを使用します。 ソケットメタポリシーは、HTTPとは無関係なため、HTTP応答ヘッダでは宣言できません。
  • ソケットメタポリシーでは、URLメタポリシーとして使用できるメタポリシーのセットとは異なるメタポリシーのセットを使用します。また、ソケットメタポリシーとURLメタポリシーでは、デフォルト値が異なります。

有効なソケットメタポリシーは次のとおりです。

  • all： このホストでは、任意のポートからソケットポリシーファイルを提供できます。 このメタポリシーは、ログイン信用情報を必要とするコンテンツを提供しないインターネット上のホストにのみ適用できます。
  • master-only： このホストでは、ソケットマスターポリシーファイル（ポート843から提供）のみ使用できます。
  • none： このホストでは、ソケットポリシーファイルを提供できません。 このメタポリシーをマスターポリシーファイル内で宣言すると、そのマスターポリシーファイルは、このメタポリシーを宣言する目的でのみ存在することになり、<allow-access-from>ディレクティブが含まれていても無視されます。

デフォルトのソケットメタポリシーはallです。 Flash Playerでは、ソケットマスターポリシーファイル内でソケットメタポリシーが宣言されていないすべてのホストについて、メタポリシーがallであるものと見なされます。 また、Flash Playerのフェーズ１とフェーズ２のどちらについても、デフォルト値はallです。 この点は、URLポリシーファイルとは異なります。URLメタポリシーのデフォルト値は、フェーズ２ではmaster-onlyになります。

このように、ソケットポリシーファイルのデフォルトのメタポリシーは、URLポリシーファイルほど厳密ではありません。 これは、ソケットでは、URLサーバと比べて、不正ポリシーファイルが使用される危険性が非常に低いためです。 例えば、HTTPサーバでは、ユーザが作成したコンテンツ（サーバ管理者以外の人が作成したコンテンツ）が提供されることが珍しくないため、フェーズ２でデフォルトのURLメタポリシーをmaster-onlyにすることによって、誰かがポリシーファイルを作成する前に、管理者が事前にポリシーファイルを使用できるようにしておくことは、有効な手段です。 一方、ホストで認証を受けていないユーザがインストールを実行したり、TCPポートをリッスンするサーバ全体を変更したりすることが許可されることはめったにないため、デフォルトのソケットメタポリシーをallにすることによって、管理者が明示的に禁止しない限り、ホスト上の任意の場所にソケットポリシーファイルを作成できるようにしておくことも重要です。

厳密なソケットルール

DNS強化を目的としてFlash Player 9.0.115.0で行われた主な変更は、厳密なソケットルールの導入です。 厳密なソケットルールとは、次の２つです。

  • ソケットポリシーファイルがない場合、SWFファイルから自身のドメインにソケット接続を行うことができなくなりました。 9.0.115.0より前のバージョンでは、ポリシーファイルがなくても、SWFファイルから自身のドメインの1024以上のポートに対してソケット接続を行うことが許可されていました。
  • ソケット接続の承認にHTTPポリシーファイルを使用できなくなりました。 9.0.115.0より前のバージョンでは、HTTPポリシーファイル（マスター場所であるポート80の crossdomain.xml から提供）を使用して、同じホスト上の1024以上のポートに対するソケット接続を承認することができました。

これら２つのルールを簡単な表現にまとめると、「厳密なソケットルールでは、すべてのソケット接続にはソケットポリシーファイルによる許可が必要である」ということになります。

Flash Player9のほとんどのポリシーファイルに関する変更と同様、厳密なソケットルールは、２段階のフェーズに分けて導入されました。 フェーズ１（Flash Player 9.0.115.0から開始）では、厳密なポリシーファイルルールに従っていなくても、Flash Playerのデバッグバージョンで警告が表示されるだけでした。 フェーズ1.5（Flash Player 9.0.124.0から開始）では、これらの警告がエラーとなり、以前のルールに従って作成されたSWFファイルが意図通りに機能しなくなる恐れがありました。 ホスト管理者に対しては、Flash Playerのフェーズ１バージョンを使用しているユーザについてもDNSリバインディング攻撃からサイトを保護できるよう、厳密なルールの適用がフェーズ１の段階から選択肢として提供されていました。

ソケットポリシーファイルのワークフローでは、厳密なソケットルールの導入によって発生する問題を発見および解決するための詳細な方法が示されています。 要約すると、上記２つのうちいずれかの状況でソケット接続を行うSWFファイルを管理している場合、接続先のホストでソケットポリシーファイルが提供されている必要があります。 ソケットポリシーファイルを提供するには、通常、ポート843にソケットマスターポリシーファイルサーバをセットアップしますが、これ以外の方法については、ワークフローに関する節を参照してください。

厳密なソケットルールの使用

Flash Playerのフェーズ１バージョンでは、次のように構成することにより、ホストで厳密なソケットルールが使用されるようになります。 これは、ホスト管理者とSWFファイルの保守担当者の両者にとって重要な情報です。ホスト管理者は、この情報に従って、より安全なルールを管理対象のホストに適用することを選択でき、SWFファイルの保守担当者は、このような構成によって、保守対象のSWFファイルがソケット接続を行うことができるかどうかにどのような影響があるのかを理解する必要があるからです。

  • ホストが、ポート843からソケットポリシーファイルを提供する場合（ソケットマスターポリシーファイル）、厳密なソケットルールがホスト全体に適用されます。 これは、ポリシーファイルの内容に関係なく実行されます。ソケットマスターポリシーファイルが空である場合や、メタポリシーallが宣言されている場合でも、ホストでは厳密なソケットルールが使用されます。 このホストにソケット接続を行うには、必ずソケットポリシーファイル（多くの場合、厳密なソケットルールへの移行の原因となったソケットマスターポリシーファイルと同じポリシーファイル）による許可が必要になります。 これは、ホスト管理者が厳密なソケットルールの適用を選択する場合に使用する一般的なメカニズムです。
  • ポート80のHTTPサーバが、URLメタポリシーをマスターポリシーファイル（ /crossdomain.xml）で宣言している場合、そのマスターHTTPポリシーファイルでは、同じホストへのソケット接続に対する承認が行われません。 この構成では、２つの厳密なソケットルールのうち、１つだけがホストに適用されます。SWFファイルによる同じホストへの接続に関するルールは、適用されません。
  • マスター以外のソケットポートからソケットポリシーファイルを提供する場合、厳密なソケットルールは、そのポートにのみ適用されます。 このポートにソケット接続を行うには、必ずソケットポリシーファイル（多くの場合、このポートから提供されているソケットポリシーファイルと同じポリシーファイル）による許可が必要になります。 このルールによって発生する可能性のある意図しない影響については、即時に適用される厳密なソケットに関する節で説明しています。 その影響とは、1024以上のソケットポートから提供されるソケットポリシーファイルのリストに自身のドメインが含まれていない場合、そのドメインのSWFファイルが接続できなくなることです（以前はポリシーファイルがなくても接続できました）。

安全なドメインのリスト

ポリシーファイルが導入されて以来、Flash Playerでは、HTTPSサーバからのポリシーファイルにおいて、<allow-access-from>ディレクティブのsecure="true"という特殊な属性がサポートされています。 secure="true"を指定すると、そのドメイン内、または同じ<allow-access-from>ディレクティブのリストに記載されたドメインのSWFファイルは、そのSWFファイル自体がHTTPS経由で取得された場合にのみ、データを取得できます。 これにより、HTTPSサーバのデータを保護することができ、取得元を正確に認証できないSWFファイルにデータが渡されることがなくなります （HTTPSにはドメイン認証と耐タンパー性のテクノロジが組み込まれているため、HTTPS経由で取得されるSWFファイルは、HTTP経由で取得されるSWFファイルよりも、偽造の可能性が低いと言えます）。 実際には、HTTPSポリシーファイルでは、secure="true"がデフォルトの動作になっています。これをオーバーライドするには、HTTPSポリシーファイルで、明示的にsecure="false"と宣言する必要がありますが、これはお勧めしません。

バージョン9.0.115.0以降、Flash Playerでは、secure="true"宣言が新しい状況でサポートされます。 つまり、ローカルソケット（Flash Playerと同じコンピュータから実行されているソケットサーバ）で提供されるソケットポリシーファイルでもサポートが開始されます。 secure="true"が、ローカルソケットポリシーファイルの<allow-access-from>ディレクティブで宣言されている場合、そのドメイン内、または同じ<allow-access-from>ディレクティブのリストに記載されているドメインのSWFファイルは、そのSWFファイルがHTTPS経由で取得された場合にのみ、許可されたポートに接続できます。 この機能を使用したローカルソケットポリシーファイルの例を次に示します。

<cross-domain-policy> <allow-access-from domain="my.com" secure="true" to-ports="3050"/> </cross-domain-policy>

このようなポリシーファイルで許可されるのは、HTTPS経由でmy.comから読み込まれたSWFファイルが、ポート3050に接続する場合のみです。 my.comからHTTP経由でロードされたSWFファイルには、このポリシーファイルではアクセス許可が与えられません。

secure="true"宣言と共にリストに記載されたドメインは、安全なドメインのリストと呼ばれます。

ローカルソケットポリシーファイルの安全なドメインのリストは、オンラインとオフラインの両方で使用するアプリケーションで役立つ可能性があります。 あるアプリケーションで、ユーザのマシンにネイティブのローカルコンポーネントをインストールして、Webブラウザ経由でオンラインのSWFインターフェイスを提供し、ActionScriptソケット接続を使用してWeb上のSWFとローカルコンポーネントとの間で通信する場合を考えてみましょう。 このシナリオでは、アプリケーション開発者は、特定のSWFファイルだけがローカルコンポーネントと通信できるようにする必要があります。そうしなければ、Web上の他のSWFファイルが、ローカルコンポーネントのネイティブな機能を乱用する可能性があるからです。 このアプリケーションの開発者が、すべてのSWFファイルをmy.comのHTTPSサーバに登録し、secure="true"宣言を含む前述のソケットポリシーファイルをローカルコンポーネントから提供すれば、その開発者が登録したSWFファイル以外のすべてのSWFファイルは、ローカルコンポーネントに接続できなくなります。

ローカルアプリケーションの開発者が安全なドメインのリストを利用するには、アプリケーションのユーザがバージョン9.0.115.0以上のFlash Playerをインストールしている必要があります。 これより前のバージョンでは、secure="true"ディレクティブは無視されてしまいます。

ただし、ローカルソケット（Flash Playerと同じコンピュータで実行されているソケットサーバ）以外から提供されるソケットポリシーファイルで、secure="true"ディレクティブを使用することはお勧めしません。 Flash Playerでは、ローカルホスト以外から取得されたと思われるソケットポリシーファイルでsecure="true"が検出されると、ポリシーファイルログに警告が記録されます。 Flash Playerでは、ローカル以外のソケットポリシーファイルにsecure="true"が含まれていても、実際にはこれに従いますが、ソケット接続がローカルホストに対するものかどうかを100％の信頼度で判断することはできないため、このような警告が記録されます。

ローカルホスト以外から提供されるソケットポリシーファイルでsecure="true"を宣言することによって、安全性が阻害される可能性がある理由を説明します。 この記事の執筆時点では、Flash Playerには安全なソケットレベルのネットワーク接続機能が備わっていません。つまり、ソケットレベルのHTTPSに相当するもの（いわばソケットレベルのSSLおよびTLS）が、まだ存在しないということです。 したがって、ソケットポリシーファイルは、常にSSLおよびTLSを利用せずに取得されます。 このため、ソケットポリシーファイルは、中間者攻撃（man-in-the-middle attacks、ネットワーク上のクライアントとサーバの間に存在する第三者が、クライアントやサーバに気づかれずにネットワーク上の対話の内容を変更する）を受けやすいと言えます。 ローカル以外のソケットから提供されるソケットポリシーファイルでsecure="true"を宣言すると、中間者攻撃（man-in-the-middle attacker）によって、この宣言がsecure="false"に置き換えられる可能性があります。 このため、ローカル以外のソケットポリシーファイルでsecure="true"を宣言すると、反対に安全性を阻害する可能性があるため、Flash Playerでは無条件にこれに従うことはできません （secure="true"の使用がHTTPSポリシーファイルのみで許可されており、HTTPポリシーファイルでは許可されていないのも、同じ理由からです）。 しかし、secure="true"をローカルソケットポリシーファイルで宣言した場合は、ソケットポリシーファイルをサーバからFlash Playerに転送するときに、ホストの外部でネットワーク接続が行われることはありません。 このため、ローカルソケットポリシーファイルでは、secure="true"が有効であると言えます。

アドレスを基準としたソケットポリシーファイルのスコープ

Flash Player 9.0.115.0で行われたソケットポリシーファイルに対する変更の１つは、ActionScriptには影響せず、その内容も変更されません。

9.0.115.0より前のバージョンでは、Flash Playerがドメインa.comからのソケットポリシーファイルを検出すると、そのポリシーファイルがa.comに対するすべてのソケット接続の承認に使用されていました。 この方法では、DNSリバインディングにより、ソケット接続時にa.comの参照先がポリシーファイルの取得時とは異なるホストに設定される可能性があります。つまり、あるホストが別のホストに対するアクセス権を指定することになります。

バージョン9.0.115.0からは、ソケット接続を許可する前に、ソケットポリシーファイルが接続先のホストと同じIPアドレスから取得されたものであるかどうかが、常にチェックされます。

ソケットポリシーファイルの動作によるサーバホストへの影響

Flash Player 9.0.115.0では、ホストで通常とは少し異なるトラフィックが発生する場合があるため、その調整が行われます。 トラフィックの相違点は、次のとおりです。

  • SWFファイルがソケット接続を実行しようとすると、それが自身のドメインに対してであっても、Flash Playerではまずポート843にアクセスして、ホストでソケットマスターポリシーファイルが提供されているかどうかを確認します。
  • ActionScript 1.0またはActionScript 2.0のSWFファイルがXMLSocket接続を実行しようとしたときに、ソケットマスターポリシーファイル、またはloadPolicyFileで指定された場所にあるポリシーファイルから接続許可がまだ取得されていない場合、Flash Playerでは、メイン接続と同じドメインのポート80でHTTPポリシーファイルを検索する（旧バージョンの動作）前に、メイン接続と同じポートからポリシーファイルを取得しようとします （ActionScript 3.0のソケット接続で実行されるポリシーファイルの確認に関するデフォルトの動作は変更されません。ActionScript 3.0のソケット接続では、メイン接続と同じポートに対するチェックがデフォルトで行われていました）。

Flash Playerによって自動的に要求されるソケットポリシーファイルについて、ホストが３秒以内に応答せず、接続試行も拒否しない場合、Flash Playerは、その場所にポリシーファイルが存在しないものと判断してその試行を中止し、ポリシーファイルログに警告を記録して、ソケットポリシーファイルによる承認の次の段階へ移行します。 このタイムアウト動作により、Flash Playerが成功する可能性のないソケット接続を長時間待機することがなくなりますが、一時的なネットワークの停止や、低速な接続、サーバに過剰な負荷がかかっている状況などに対する柔軟性が、若干損なわれることになります。このような状況がなければ自動的に取得されるソケットポリシーファイルが存在することがわかっている場合は、SWFファイルから明示的にloadPolicyFileを呼び出し、そのソケットポリシーファイルのURLを指定することにより、３秒のタイムアウト動作が実行されないようにすることができます。 これにより、そのポリシーファイルの取得待機時間を長くすることができ、TCPのタイムアウト（２分間）が経過するまで、次の段階に移行しないようにすることができます。 例えば、mysite.comのポート843にマスターソケットポリシーファイルがあることがわかっており、Flash Playerによる取得試行動作に設定された３秒間のタイムアウトが実行されないようにするには、ActionScriptからloadPolicyFile("xmlsocket://mysite.com:843")を呼び出します。

ファイアウォールのトラバースに関する問題とソケットポリシーファイル

ソケットマスターポリシーファイルの欠点は、クライアントがポート843にアクセスできなければならないことです。アウトバウンド通信を制限するファイアウォールの内側にいるユーザの中には、これができない人もいます。

しかし、アウトバウンド通信を制限するファイアウォールでも、ポート843へのアクセスを許可することは有効です。 これにより、Flash Playerにおいて、ホスト管理者が宣言したセキュリティポリシーを適用できるようになります。また、ポート843の目的を標準化することができれば、他の種類のサーバがこのポートに関連付けられることがなくなります。 しかし、ソケットマスターポリシーファイルは新しい概念であり、ファイアウォールのルールセットにポート843へのアクセスが組み込まれるようになるまでには、まだ時間がかかります。ここでも、ポート843へのアクセスを許可するかどうかについては、ファイアウォール管理者個人の裁量に委ねられます。以降では、この問題がFlash Playerユーザやサーバホストに深刻な問題を引き起こすことがない理由を説明します。

ポート843にアクセスできないことによる影響は、次のとおりです。

  1. ソケットメタポリシーが遵守されません。すべてのソケットポリシーファイルによるアクセス許可の付与が認められます（ただし、ファイアウォールの内側にいるユーザについてのみ）。
  2. Flash Playerのフェーズ１バージョンでは、ホストでソケットマスターポリシーファイルの採用によって新しいルールの使用を選択している場合、その選択がFlash Playerに認識されません。 ファイアウォールの内側にいるユーザは、依然として1024以上のソケットポートを対象としたDNSリバインディング攻撃の媒介者となる可能性があります。
  3. ホストでソケットマスターポリシーファイルを使用してソケット接続の承認を行っている場合、ファイアウォールの内側にいるユーザは、このような接続を確立できません。

このような影響により、細かい問題が発生する場合もありますが、大きな問題にはなりません。 その理由は次のとおりです。

  • ユーザがファイアウォールの内側におり、ポート843にアクセスできない場合、対象のポートにもアクセスできない可能性があるため、上記３つのデメリットが実質的に問題にならなくなります。 ファイアウォールで常に接続が許可されているポートにはいくつかありますが（HTTPの80など）、多くのポートへのアクセスは許可されておらず、1024以上のほとんど、またはすべてのポートへのアクセスも許可されていない可能性が高いと言えます。この最後の点により、特に問題２が発生することはほとんどないと考えられます。
  • ファイアウォールの内側を対象としたDNSリバインディング攻撃で、ポート843へのアクセスが問題になることは少ないと考えられます。これは、ファイアウォールでその内側にあるサーバのすべてのポートへのアクセスがブロックされることはめったにないからです。
  • 上記の問題１について、ソケットメタポリシーによる制限を回避しようとする攻撃者（そのような攻撃者自体がほとんどいない）が、アウトバウンド通信を制限するファイアウォールの内側にいるユーザを特に媒介者として利用しようとする可能性は低いと考えられます。

対策が必要な理由

ホストでソケットポリシーファイル（多くの場合ポート843のソケットマスターポリシーファイル）を提供する理由は、次の２つです。

  • ホストにソケット接続を行うSWFファイルを管理しており、現在はソケットポリシーファイルを使用せずに接続を行っている場合（接続先が自身のドメインであるため、またはHTTPポリシーファイルを使用しているため）、Flash Playerのフェーズ1.5バージョン（Flash Player 9.0.124.0またはそれ以降）をインストールするユーザについては、このようなSWFファイルからソケット接続を行うことができません。
  • ホストでソケットポリシーファイルを提供する予定がない場合、またはFlash Player互換のコンテンツをまったく提供する予定がない場合でも、悪意ある攻撃者がDNSリバインディング攻撃によってホストに不正なソケットレベルの接続を行おうとする可能性があります。 ソケットマスターポリシーファイルを提供することによって厳密なソケットルールの使用を選択すると、Flash Playerのフェーズ１バージョンのユーザが、そのような攻撃の媒介者になることがなくなります。

ソケットポリシーファイルの構成のワークフローでは、マスターソケットポリシーファイルをホストから提供するために必要な手順を示します。

ワークフロー

次の手順を使用すると、ポリシーファイルについてのFlash Player 9.0.115.0、Flash Player 9.0.124.0またはFlash Player 10.0の変更点に関連する問題にすばやく対処できるようになります。この記事の前半にある、変更点に関する概要の節を読んでから、この節を参照することをお勧めします。

ログの使用

Flash Player 9.0.115.0では、ポリシーファイルログという新機能が導入されました。 ポリシーファイルログには、ポリシーファイルの取得、ポリシーファイルの処理が正常に終了したか失敗したか、ポリシーファイルに依存する要求の結果など、ポリシーファイルに関連するすべてのイベントのメッセージが表示されます。 ポリシーファイルログに表示されるメッセージの一覧については、付録Bを参照してください。

ポリシーファイルログを使用するには、次の手順を実行します。

  1. Flash Player 9.0.115.0以降のデバッグバージョンをインストールします。 すべてのタイプ（ActiveX、プラグイン、スタンドアロン）のFlash Playerを使用できます。 デバッグバージョンのFlash Playerは、Flash Playerサポートセンターのダウンロードページから入手できます。
  2. mm.cfg構成ファイルの場所を探します。 これは、デバッグバージョンのFlash Playerが起動時に読み取る一般的なデバッグ構成ファイルです。 mm.cfgは「ホーム」ディレクトリにあります。一般的な例を次に示します。

    Windows： C:\Documents and Settings\ユーザ名

    Windows Vista： C:\Users\ユーザ名

    Macintosh： /Users/ユーザ名

  3. mm.cfgが存在しない場合は作成し、次の行の１つまたは両方を追加します。
PolicyFileLog=1 # Enables policy file logging PolicyFileLogAppend=1 # Optional; do not clear log at startup

PolicyFileLogAppendが有効になっていない場合は、新しいルートレベルの各SWFによりログファイルがクリアされます。 PolicyFileLogAppendが有効になっている場合は、ログファイルの前の内容が常に保持され、最終的にはログファイルが大きくなります。

テスト中に複数の異なるルートレベルのSWFファイルがロードされる場合は、PolicyFileLogAppendを有効にします。 ただし、PolicyFileLogAppendを有効にした場合は、適宜手動でログファイルの名前を変更するか、またはログファイルを削除する必要があります。この作業を行わないと、ログファイルが非常に大きくなり、前の出力が終了した場所と新しい出力が開始された場所を見つけるのが難しくなります。

  1. policyfiles.txtというポリシーファイルログが書き込まれる場所を探します。 このログは必ずしも存在しているとは限りません。次にSWFファイルが実行されたときにFlash Playerによって作成されます。 policyfiles.txtは次の場所にあります。

    Windows： C:\Documents and Settings\ユーザ名\Application Data\Macromedia\Flash Player\Logs

    Windows Vista： C:\Users\ユーザ名\AppData\Roaming\Macromedia\Flash Player\Logs

    Macintosh： /Users/ユーザ名/Library/Preferences/Macromedia/Flash Player/Logs 通常とは異なり、この場合はプログラムがログファイルをPreferencesディレクトリに書き込みます。

    Linux： /home/ユーザ名/.macromedia/Flash_Player/Logs

  2. Flash PlayerでSWFファイルを実行した後、Flash Playerを閉じます。
  3. これで、policyfiles.txtがLogsディレクトリに作成されます。 最新の変更時刻であることを確認します。 ファイルを開き、少なくとも１つのメッセージ（「Root-level SWF loaded」）が表示されていることを確認します。 メッセージが表示されている場合、ポリシーファイルログは機能しています。
  4. テストする必要があるすべてのSWFコンテンツにアクセスします。 ポリシーファイルの取得を伴うシナリオを使用して、コンテンツを実行します。 完了したらFlash Playerを閉じます。
  5. テストの実行中にポリシーファイルで行われた処理の詳細について、policyfiles.txtを確認します。 不明なメッセージがある場合は、付録Bを参照してください。
  6. 後で参照できるように保存しておく必要がある情報がpolicyfiles.txtに含まれている場合は、ログファイルの名前をpolicyfiles.txt以外に変更するか、別のディレクトリに移動して、次にFlash Playerを実行したときにログが上書きされないようにします。

即時解決を要する問題の検出と修正

即時かつ厳密な対処に関する節で説明したように、Flash Player 9.0.115.0のいくつかの変更点は、SWFコンテンツに直ちに影響するため、ごく一部のSWFファイルで問題が発生する可能性があります。 現状のSWFコンテンツを保持する場合は、早急に次の手順を実行する必要があります。

  1. Flash Player 9.0.115.0以降のデバッグバージョンをインストールします。 ブラウザベースバージョンのFlash Playerを使用して、本番環境をシミュレートします。 ActiveXプレーヤーまたはプラグインプレーヤーを使用できます。どちらを使用しても結果は同じになります。 デバッグバージョンのFlash Playerは、Flash Playerサポートセンターのダウンロードページから入手できます。
  2. テストでは、Flash PlayerのHTTP応答ヘッダをサポートできる最新のブラウザを使用するようにします。これにより、即時解決を要する問題に対する完全なテストを実施できるようになります。 この要件を満たすブラウザの詳細については、付録Aを参照してください。
  3. 上記のように、ポリシーファイルログを有効にします。
  4. SWFコンテンツをテストします。 できるだけ多くのコンテンツを実行するようにします。
  5. コンテンツをテストした後、Flash Playerを閉じ、ポリシーファイルログを確認します。 ポリシーファイルログで、[strict]というラベルを含むメッセージを探します。 このラベルは、即時解決を要する問題の可能性があることを示しています。
  6. 期待どおりに機能していないコンテンツの状況をメモします。そのようなコンテンツは、デバッグが必要な問題を示している可能性があります。 問題があるコンテンツの状況をポリシーファイルログの内容と関連付け、以前のバージョンのFlash Playerで再テストして、Flash Player 9.0.115.0での動作と異なることを確認します。 古いバージョンと新しいバージョンのFlash Playerの間で動作に違いがない場合は、ポリシーファイルの厳密な対処に関連する問題ではありません。

    Flash Playerをアンインストールして古いバージョンにダウングレードする必要がある場合は、Flash Player Uninstallerを使用します。 ActiveXコントロールのセキュリティ機能により、次の「/clean」コマンドを使用してアンインストーラを実行する必要があります。

    uninstall_flash_player.exe /clean

    テストに使用する古いバージョンのFlash Playerを入手するには、TechNoteの 「テスト用のアーカイブ版Flash Playerの提供について」にアクセスします。

  7. ポリシーファイルログで見つかった[strict]メッセージを分類します。 メッセージの内容は次のとおりです。
    • Ignoring policy file at (URL) due to incorrect syntax.不正な形式のポリシーファイルは無視されているため、クロスドメインアクセスが拒否される可能性があります。 このログメッセージの説明、および不正な形式のポリシーファイルについての節を参照してください。
    • Policy file requested from (URL) redirected to (URL); will use final URL in determining scope.ポリシーファイルのリダイレクトによって、ポリシーファイルのスコープが変更される可能性があり、その結果、クロスドメインアクセスが拒否される可能性があります。 このログメッセージの説明、およびドメイン内のリダイレクトについての節を参照してください。
    • Ignoring policy file at (URL) due to bad Content-Type '(content-type)'.サーバで宣言された必須のテキストのContent-TypeがないHTTPポリシーファイルが受信されましたが、無視されます。クロスドメインアクセスが拒否される可能性があります。 このログメッセージの説明、およびContent-Typeのホワイトリストについての節を参照してください。
    • Ignoring policy file at (URL) due to missing Content-Type.サーバで宣言された必須のテキストのContent-TypeがないHTTPポリシーファイルが受信されましたが、無視されます。クロスドメインアクセスが拒否される可能性があります。 このログメッセージの説明、およびContent-Typeのホワイトリストについての節を参照してください。
    • Local socket connection forbidden to host (host) without a socket policy file.SWFコンテンツは、ローカルホスト上にあると思われるソケットに接続しようとしましたが、ホストがlocalhostとして指定されていませんでした。 厳密なソケットルールが直ちに適用され、アクセスが拒否されます。 このログメッセージの説明、および即時に適用される厳密なソケットについての節を参照してください。

URLメタポリシーの設定

メタポリシーの節で説明したように、HTTPサーバ、HTTPSサーバ、またはFTPサーバでメタポリシーを選択および宣言するのは２つの理由があります。

  • サーバがポリシーファイルを提供し、管理者がそのポリシーファイルを許可するメタポリシーを宣言しない場合、ポリシーファイルは、フェーズ２バージョンのFlash Player（Flash Player 10.0以降）をインストールするユーザには適用されなくなります。 メタポリシーを設定することで、サーバのポリシーファイルがフェーズ２バージョンのFlash Playerのユーザ向けにスムーズに移行されます。
  • サーバがポリシーファイル、またはFlash Player互換コンテンツを意図的に提供するかどうかに関係なく、サーバでテキストファイルを作成できるユーザはポリシーファイルを作成できます。このポリシーファイルを使用すると、サーバまたはユーザ（あるいはその両方）のプライベートなデータを取得できます。 メタポリシーの宣言により、フェーズ１バージョンのFlash Playerのユーザには、デフォルトのメタポリシーallは適用されなくなります。

管理していないサーバ上のサイトを操作している場合は、ホストされるサービスのユーザ向けの考慮事項についての節を参照してください。

管理しているサーバ上のメタポリシーを設定するには、次の手順を実行します。

  1. まず、メタポリシーの基本をよく理解します。
  2. 使用可能なメタポリシーのリストを確認します。 サーバに最も適したメタポリシーを決定します。 HTTPサーバおよびHTTPSサーバ向けのガイドラインを次に示します（FTPサーバ向けのガイドラインも似ていますが、詳細が若干異なります）。
    • サーバでポリシーファイルを提供しない場合は、メタポリシーnoneを選択します。
    • サーバがユーザ定義コンテンツを提供する場合は、ユーザがポリシーファイルを作成できないようにするメタポリシー方針を選択します。 これは基本的に、allを選択しないことを意味します。by-content-typeを選択した場合は、ユーザ定義コンテンツでContent-Typeにtext/x-cross-domain-policyを割り当てるための条件を満たすことができなくなります。
    • サーバへのアップロード権限を持つユーザが、ポリシーファイルを簡単に作成できるようにするには、メタポリシーallを選択します。
    • サーバ上に１つのマスターポリシーファイルのみを配置する場合は、メタポリシーmaster-onlyを選択し、信頼できる担当者のみが /crossdomain.xmlにあるマスターポリシーファイルの内容を変更できるようにします。
    • 個別に承認された場所にマスター以外のポリシーファイルを配置するには、メタポリシーby-content-typeを選択し、指定された場所にtext/x-cross-domain-policyのContent-Typeを割り当てます。 これを実行するためのApache設定スニペットの例を次に示します。
<Location /crossdomain.xml> ForceType text/x-cross-domain-policy </Location> <Location /another/place/crossdomain.xml> ForceType text/x-cross-domain-policy </Location>
  • 事前に決められた場所にマスター以外のポリシーファイル（crossdomain.xmlという名前のファイルなど）を配置するには、メタポリシーby-content-typeを選択し、条件を満たす場所にtext/x-cross-domain-policyのContent-Typeを割り当てます。 これを実行するためのApache設定スニペットの例を次に示します。
<Files crossdomain.xml> ForceType text/x-cross-domain-policy </Files>
  • ポリシーファイルの生成を許可したくないスクリプトをサーバがホストしている場合、このようなスクリプトの出力に特別なメタポリシーnone-this-responseを追加します。 これを実行するためのApache設定スニペットの例を次に示します。
<Location /cgi-bin> Header set X-Permitted-Cross-Domain-Policies none-this-response </Location>
  1. マスターポリシーファイルとHTTP応答ヘッダのどちらを使用してメタポリシーを宣言するかを決定します （FTPサーバはマスターポリシーファイルを使用する必要があります）。 各方法の長所と短所について、メタポリシーの指定方法に関する節を確認してください。
    1. マスターポリシーファイルでメタポリシーを宣言する場合は、<site-control>タグを /crossdomain.xmlにあるマスターポリシーファイルに書き込みます。次に例を示します。
<cross-domain-policy> <site-control permitted-cross-domain-policies="by-content-type"/> </cross-domain-policy>
  1. HTTP応答ヘッダでメタポリシーを宣言する場合は、適切なX-Permitted-Cross-Domain-Policiesヘッダを返すようにサーバを設定します。 これを実行するためのApache設定スニペットの例を次に示します。
<Location /> Header set X-Permitted-Cross-Domain-Policies master-only </Location>

ホストされるサービスのユーザ向けの特別な考慮事項

ホストされるサービス上のサイト、または完全には管理していないサーバを操作していて、ポリシーファイルを提供する場合は、以下の点を考慮します。

  • Flash Player 9.0.115.0の動作が停止した場合は、即時解決を要する問題に対するワークフローを実行します。 サーバ管理者が対応しなくても、見つかったほとんどの問題を修正できるようになる必要があります。
  • Flash Player 10.0がリリースされるまでに、ポリシーファイルが機能するようにするために、メタポリシーを設定する必要があります。サービス利用者の問題を解決するためには、サーバ管理者にサービス全体を変更してもらう必要があります。 サービスプロバイダに連絡し、この記事を案内して変更の検討を依頼することもできます。
  • （サイトを不正な ポリシーファイルから守るなどの目的で）メタポリシーをすぐに設定する場合、またはサービスプロバイダがサービス全体の修正を行っていない場合、サイトのルートディレクトリへのアクセス権があれば、 自分で問題を修正できます。 URLメタポリシーを設定するためのワークフローを実行します。 HTTP応答ヘッダに影響を及ぼすことはできないため、オプションは限定される可能性があります。 適切なオプションは次のとおりです。

サイトで１つのポリシーファイルを使用する場合は、次のオプションを使用します。

<site-control permitted-cross-domain-policies="master-only"/>

サイトでのポリシーファイルの作成を制限しない場合は、次のオプションを使用します。

<site-control permitted-cross-domain-policies="all"/>

ソケットポリシーファイルの設定

ソケットポリシーファイルについての節で説明したように、ホスト上のポート843からソケットマスターポリシーファイルを提供するのには２つの理由があります。

  • •ホ ストにソケット接続を行うSWFファイルを管理しており、現在はソケットポリシーファイルを使用せずに接続を行っている場合（接続先が自身のドメインであ るため、またはHTTPポリシーファイルを使用しているため）、フェーズ1.5バージョンのFlash Player（Flash Player 9.0.124.0またはそれ以降）をインストールするユーザについては、このようなSWFファイルからソケット接続を行うことができません。 ソケットマスターポリシーファイルを提供することで、ホストへのソケット接続が、フェーズ1.5バージョンのFlash Playerのユーザ向けにスムーズに移行されます （特定のSWFコンテンツがソケットポリシーファイルなしでホストへの接続を確立するかどうかわからない場合は、ポリシーファイルログを使用してコンテンツをテストし、非推奨のソケット設定に関する警告を探します）。
  • ホストでソケットポリシーファイルを提供する予定がない場合、またはFlash Player互換のコンテンツをまったく提供する予定がない場合でも、悪意ある攻撃者がDNSリバインディング攻撃によってホストに不正なソケットレベルの接続を行おうとする可能性があります。 ソケットマスターポリシーファイルを提供することによって厳密なソケットルールの使用を選択すると、Flash Playerのフェーズ１バージョンのユーザが、そのような攻撃の媒介者になることがなくなります。

ソケットマスターポリシーファイルの提供は、これらの問題に対処する唯一の方法ではありませんが、最も簡単かつ一貫性のある方法です。 何らかの理由でポート843からマスターソケットポリシーを提供できない場合は、ポート単位でこれらの問題に対処し、個別のポートからマスター以外のポリシーファイルを提供します。 ただし、ソケットマスターポリシーファイルはホスト全体に同時に対応する必要があります。

ソケットマスターポリシーファイルを提供するには、次の手順を実行します。

  1. 使用可能なソケットメタポリシーのリストを確認し、ホストに適したソケットメタポリシーを決定します。
  2. ソケットマスターポリシーファイルを作成し、目的のソケットメタポリシーと付与するアクセス許可を宣言します。 次に例を示します。
<cross-domain-policy> <site-control permitted-cross-domain-policies="master-only"/> <allow-access-from domain="mysite.com" to-ports="999,8080-8082"/> </cross-domain-policy>
  1. ソケットポリシーファイルサーバの情報ページにアクセスし、ソケットポリシーファイルサーバの設定方法を決定します。
  2. ホストでソケットポリシーファイルサーバを実行し、作成したソケットマスターポリシーファイルを提供します。

付録A： ブラウザへの依存性

セキュリティに関するFlash Player 9.0.115.0の２つの変更点は、Flash PlayerがHTTP応答ヘッダにアクセスするときにのみ適用されます。 Flash Playerがブラウザ内で実行されている場合、一部のブラウザはFlash PlayerにHTTP応答ヘッダを提供しないため、これは常に可能であるとは限りません。

HTTP応答ヘッダへのアクセスを必要とする２つの機能は、次のとおりです。

  • Content-Typeのホワイトリスト： Flash PlayerがHTTP応答ヘッダにアクセスすると、テキスト以外のContent-Type値を含むHTTPポリシーファイル、およびContent-Type値がまったくないHTTPポリシーファイルは拒否されます。 Flash PlayerにHTTP応答ヘッダへのアクセス権がない場合は、Content-Typeに関係なくHTTPポリシーファイルが使用されます。
  • HTTPメタポリシー： Flash PlayerにHTTP応答ヘッダへのアクセス権がある場合は、マスターHTTPポリシーファイルおよびX-Permitted-Cross-Domain-Policies応答ヘッダで宣言されたHTTPメタポリシーが使用されます。 Flash PlayerにHTTP応答ヘッダへのアクセス権がない場合、すべてのHTTPサーバにメタポリシーallがあると想定されます。

表１に、アドビがHTTP応答ヘッダについてテストを実施したブラウザを示します。

表１.HTTP応答ヘッダについてテストされたブラウザ
ブラウザ ヘッダを提供しないバージョン ヘッダを提供するバージョン
Internet Explorer（Windows） — 5.5以降
Mozilla Firefox 2.0.0.3以前 2.0.0.4以降
Safari（Macintosh） 2.x以前 3.x以降

付録B：ログメッセージの解説

この節では、ポリシーファイルログ（crossdomain.xml）に記録されるメッセージについて説明します。 ログ記録に関する節で詳述したとおり、これらのメッセージの一部には、識別子[strict]が接頭辞として付加されています。この識別子は、フェーズ２の近い将来発生する可能性のある問題の警告ではなく、フェーズ１での即時解決を要する問題であることを示します。 詳細については、即時解決を要する問題の節を参照してください。

SWFのロード

ルートレベルの SWF を読み込みました : (URL)

最上位のSWFファイルが、示されたURLからロードされました。 通常、これはログの最初のメッセージです。追加モードのログ記録を有効にした場合は、複数回表示されることがあります。 このメッセージにより、後のメッセージのコンテキストがわかり、ログを生成したFlash Playerセッションを開始したSWFファイルを確認することができます。

ポリシーファイルに依存する要求

(URL) のリソースからのデータ読み込みを (URL) の要求者に許可するために、ポリシーファイル内の<allow-access-from>を検索しています

SWFファイルが、ポリシーファイルからのデータ読み込み許可が必要な操作を実行しようとしたため、ポリシーファイルの検出処理が開始されます。このメッセージのURLは、SWFファイルのロード元と、SWFファイルがどのリソースを要求したかを示します。

URL (URL) へのヘッダ送信を (URL) の要求者に許可するために、ポリシーファイル内の<allow-http-request-headers-from>を検索しています

SWFファイルが、ポリシーファイルからのヘッダ送信許可が必要とされる、カスタムリクエストヘッダを伴うHTTP操作を実行しようとしたため、当該ポリシーファイルの検出処理が開始されます。このメッセージのURLは、SWFファイルのロード元と、SWFファイルがどの送信先にカスタムHTTPリクエストヘッダを送信しようとしているかを示します。ヘッダ送信権限について詳しくは、別途記事「2008年４月のFlash Player 9のセキュリティアップデートについて」を参照してください。

(URL) のリソースに対する、(URL) の要求者からの要求は、ポリシーファイルのアクセス権がないため拒否されました。

SWFファイルが、ポリシーファイルによる許可が必要な操作を実行しようとしましたが、この操作を許可した有効なポリシーファイルが見つかりませんでした。 このメッセージのURLは、SWFファイルがどのリソースを要求したか、およびSWFファイルのロード元を示します。

このメッセージは様々な理由で発生します。発生した特定の問題を示すのではなく、実行できなかった必要な手順を示します。 場合によっては、このメッセージが表示される前に、より具体的な別のメッセージが表示され、この最終的なエラーメッセージの前に多くの情報が提供されることがあります。 考えられる原因は次のとおりです。

  • 操作を許可するために適用できるポリシーファイルが存在しません。 リソースが存在するサーバを管理している場合は、そのサーバにポリシーファイルを追加する必要があります。 それ以外の場合、SWFファイルのホストサーバを通じて操作を委任する必要があります。
  • 適用できるポリシーファイルは存在しますが、ポリシーファイルとリソースの両方が存在するサーバにその時点で到達不能でした。 サーバホストにpingして、到達可能かどうかを確認します。 SWFファイルが適用可能なポリシーファイルをロードするためにallowDomainを呼び出した場合、通常は、このメッセージのメッセージの前に「Failed to load policy file from (URL)」という内容のメッセージが示されます。 ソケット接続の場合は、この状況で、前に示したメッセージ（「...because the server cannot be reached」）が表示されますが、その他の要求の場合は、このメッセージが表示されることに注意してください。
  • 適用できるポリシーファイルは存在しますが、SWFファイルの特定のドメインによるアクセスに対する許可が付与されていません。 既存のポリシーファイルにリストされたSWFファイルのドメインを取得するか、既存のポリシーファイルによって許可されたドメインにSWFを移動するか、新しいポリシーファイルを追加するか、またはSWFファイルのホストサーバを通じた要求の委任を試行してください。
  • 適用できるポリシーファイルは存在しますが、デフォルト以外の場所に存在するため、操作を試行したSWFファイルがallowDomainを呼び出してポリシーファイルの場所をFlash Playerに通知しませんでした。 SWFファイルからallowDomainを呼び出してみてください。
  • 適用できるポリシーファイルは存在しますが、何らかの理由で無効になっています。 この場合、このメッセージの前に、ポリシーファイルのURLと検出された問題を示す、より具体的なメッセージが表示されます。詳細については、ポリシーファイルのロードエラーの節を参照してください。
(URL) のポリシーファイルでは、(URL) の SWF からホスト(host) のソケットへの接続が、 メタポリシー '(meta-policy)' により許可されていません。

SWFファイルがそれ自体のドメイン外でソケット接続の確立を試行しましたが、接続を許可する唯一のポリシーファイルは同じホストのHTTPマスターポリシーファイルでした。 ソケット接続を許可するHTTPポリシーファイルの構成は、フェーズ１で非推奨となっています。 この特定のHTTPポリシーファイルはメタポリシーを宣言しています。つまり、サーバは、HTTPポリシーファイルによってソケット接続が許可されることのない、フェーズ２のルールを選択します。 詳細については、厳密なソケットルールの節を参照してください。 接続先のホストを管理している場合は、ポート843にソケットマスターポリシーファイルを追加するか、メイン接続のサーバがソケットポリシーファイルも提供するようにしてみてください。 これらの処理のいずれも実行できない場合、SWFのホストサーバを通じてソケット接続を委任してください。

ソケットポリシーファイルがない場合、ローカルソケット接続による(host) のホストは許可されません。

SWFファイルがFlash Playerを実行しているコンピュータに属するIPアドレスへのソケット接続を確立しようとしましたが、この操作を許可するソケットポリシーファイルが見つかりませんでした。 厳密なポリシーファイルルールでは、ソケット接続を確立するには、ソケットポリシーファイルの許可が必要です。 フェーズ１では、ほとんどのソケット接続の場合、この変更によって単に警告が表示されるだけですが、ローカルIPアドレスへの接続の場合は、フェーズ１でも厳密なルールが有効です。 詳細については、「厳密なソケットルールの使用」の節を参照してください。 この問題に対処するには、ローカルマシンにソケットポリシーファイルサーバを追加するか、ActionScriptでソケット接続を確立するときに、別の名前を指定するのではなく、ローカルマシンのアドレスを"localhost"として明示的に指定するようにSWFファイルを変更します。 "localhost"の使用はフェーズ１でのみ機能し、フェーズ２では機能しません。したがって、可能な場合は、ローカルソケットポリシーファイルサーバを手配することをお勧めします。

フェーズ１で非推奨となった設定

ドメイン(domain) にはメタポリシーが指定されていません。 デフォルトのメタポリシー 'all' を適用しますが、この設定は推奨されていません。

こ れは、Flash Playerが、HTTP、HTTPS、またはFTPサーバからメタポリシーの指定がないポリシーファイルを取得したときに必ず表示される一般的なメッ セージです。 Flash Player 9.0.115.0が最初にリリースされた時点では、メタポリシーがそれ以前には存在していなかったため、このメッセージがほとんどすべてのサーバで表示 されます。 フェーズ１では、このメッセージは単なる警告であり、フェーズ２のFlash Player（Flash Player 10.0）がリリースされるまでにこのサーバがメタポリシーを選択する必要があり、選択しないと、Flashのコンテンツが意図したとおり動作しなくな ることを通知するものです。 詳細については、メタポリシーの節を参照してください。

フェーズ1.5で禁止された設定

ポリシーファイルがないと、(URL) の SWF はドメイン内のソケットに接続接続できません

SWF ファイルがそれ自体のドメインへのソケット接続を開始しましたが、この操作を許可するポリシーファイルが見つかりませんでした。 厳密なポリシーファイルルールでは、ソケット接続を確立するには、SWFファイル自体のドメインに対する接続の場合でも、ソケットポリシーファイルからの 許可が必要です。 詳細については、ソケットポリシーファイルの節を参照してください。 推奨されるアクションは、ソケットマスターポリシーファイルサーバをポート843に追加することです。

(URL) のポリシーファイルでは、(URL) の SWF からホスト(host) の ソケットへの接続を許可していますが、この設定は推奨されていません。

SWFファイルがソケット接続を開始しましたが、この操作を許可する唯一のポリシーファイルは、ソケットサーバと同じドメインのHTTPポリシーファイルでした。 厳密なポリシーファイルルールでは、ソケット接続を確立するには、ソケットポリシーファイルの許可が必要です。 ただし、フェーズ１では、ソケット接続を許可するHTTPポリシーファイルの古いシステムが引き続き許可されますが、この警告が表示されます。 フェーズ２に移行できるようにするには、ソケット接続と同じホスト名でソケットポリシーファイルサーバを利用できるようにする必要があります。 詳細については、ソケットポリシーファイルの節を参照してください。 推奨されるアクションは、ソケットマスターポリシーファイルサーバをポート843に追加することです。

プラットフォームの警告

このプラットフォームでは HTTP レスポンスヘッダを使用できません。 ポリシーファイルの厳密な規則を適用できません。

Flash PlayerがHTTP要求を行いましたが、HTTP応答ヘッダを確認できませんでした。 メタポリシーの節に記載されているとおり、一部の新しい厳密なポリシーファイルルールでは、例えばサーバからのContent-TypeおよびX-Permitted-Cross-Domain-Policies情報がわかるように、Flash PlayerがHTTP応答ヘッダにアクセスできる必要があります。 サーバからのメタポリシー情報は一切利用できなくなります。 厳密な影響の一覧と、この動作が予想されるブラウザの設定の一覧については、ブラウザの依存性についての付録を 参照してください。 この警告は、以前に動作していたコンテンツが動作しなくなることを示すものではありません。新しい、より厳密なルールを適用できないため、サーバおよび ユーザのセキュリティが低下する可能性があることを示すものです。 多くの一般的なブラウザの最新バージョンでは、Flash PlayerがHTTP応答ヘッダを確認できるため、一般に、ブラウザをアップグレードすると、このメッセージは表示されなくなります。

ポリシーファイルの正常なロード

ポリシーファイルを受け取りました : (URL)

ポリシーファイルが指定したURLから正常にロードされ、すべての有効性チェックに合格し、Flash Playerによって受け入れられました。 ポリシーファイルの<allow-access-from>ディレクティブが有効になります。 このポリシーファイルは、SWFファイルでloadPolicyFileを呼び出して明示的に要求することによりロードされたか、Flash Playerのデフォルトのポリシーファイルルールによって自動的に検出された可能性があります。

ポリシーファイルのロード中の警告

(URL) から要求されたポリシーファイルは(URL) にリダイレクトされました。 スコープの判断には最終 URL が使用されます。

Flash PlayerがHTTPポリシーファイルを要求し、元の要求が同じドメインの別の場所にリダイレクトされました。 リダイレクトについての節に記載されているとおり、バージョン9.0.115.0以降のFlash Playerでは、同じドメイン内でリダイレクトされたURLから取得したHTTPポリシーファイルの解釈が変更されています。 9.0.115.0より前のバージョンのFlash Playerでは、リダイレクトされたポリシーファイルを最初に要求したURLから取得したものとして扱っていましたが、バージョン9.0.115.0以降のFlash Playerでは、リダイレクトされたポリシーファイルを、リダイレクト後の最終的なURLから取得したものとして扱います。 この相違は、これらのポリシーファイルのスコープ、つまりアクセス可能な一連のリソースに影響する可能性があります。 この警告が表示された場合は、ログを詳細にチェックして、このポリシーファイルに依存するすべての要求が正常に実行されているかどうかを確認します。 要求が正常に実行されていない場合は、元の要求されたURLに、リダイレクトされたものではないポリシーファイルを追加する必要があります。 また、別のURLに、リダイレクトされたものではないポリシーファイルを配置することもできます。この場合は、新しいポリシーファイルのURLを使用するために、SWF内でloadPolicyFile呼び出しを追加または変更する必要があります。 いずれの場合も、ポリシーファイルのデバッグが困難になる可能性があるため、ポリシーファイル要求のリダイレクトを回避することを検討してください。

ドメイン(domain) にはメタポリシーが明示的に指定されていませんが、 ポリシーファイル(URL) の Content-Type は 'text/x-cross-domain-policy' です。 メタポリシー 'by-content-type' を適用します。

Flash Playerが、示されたURLからHTTPポリシーファイルを取得し、HTTPヘッダとこのドメインのマスターポリシーファイルでメタポリシーを探しましたが、メタポリシーが見つかりませんでした。 ただし、返されたポリシーファイルは<code>Content-Type</code>が<code>text/x-cross-domain-policy</code>であり、このサーバの管理者が、メタポリシーをサポートするように意図的に変更したことを示しています。 HTTPポリシーファイルの正式な<code>Content-Type</code>がこのドメインで使用されているため、Flash Playerは、このドメインのメタポリシーが<code>by-content-type</code>であると想定しています。 詳細については、<a href="/jp/devnet/flashplayer/articles/fplayer9_security_03.html#_How_to_Specify">メタポリシーの指定</a>の節を参照してください。 わかりやすくするために、この暗黙的なメカニズムに依存するのではなく、このサーバがメタポリシーを明示的に宣言することを推奨します。 このためには、マスターポリシーファイルの&lt;site-control&gt;タグを使用するか、HTTP応答ヘッダ<code>X-Permitted-Cross-Domain-Policies</code>を使用します。

ソケットポリシーファイルの待機中に(URL) がタイムアウトしました (3 秒間)。

Flash Playerがデフォルトで（ポート843または接続を試行したのと同じポートから）ソケットポリシーファイルを要求しましたが、ソケットポリシーファイ ル要求が成功せず、検出可能なエラーも発生しませんでした。Flash Playerが接続を試みたサーバは３秒以内に応答しませんでした。 これは、サーバが予期しないポリシーファイル要求を受信したか、クライアントとサーバ間のネットワークの問題による可能性があります。 Flash Playerがデフォルトでソケットポリシーファイルを要求した場合、サーバリソースの占有または問題のクライアント側への通知の遅延を回避するために、 ３秒間だけ応答を待機します。詳細については、ソケットポリシーファイルの 節を参照してください。 通常、この警告は次の２つのいずれかを意味します。 １つは、Flash Playerがデフォルトでチェックする最初の場所であるポート843にソケットポリシーファイルサーバを設定する必要があること、もう１つは、ソケット ポリシーファイルの場所を示すloadPolicyFileを呼び出すことにより、ActionScriptからFlash Playerにより明確なガイダンスを提供する必要があることです。 Flash Playerがデフォルトで場所をチェックできるようにするのではなく、loadPolicyFileを 呼び出す場合、Flash Playerは、３秒経過後タイムアウトすることはなく、ソケットポリシーファイルサーバからの応答があるまで待機します。 これにより、限界ネットワーク条件でのアプリケーションの信頼性を確保することができます。 このため、デフォルトのソケットポリシーファイルの場所であっても、loadPolicyFileを呼び出して、ソケットポリシーファイルサーバが応答するまでFlash Playerが単に待機するよう要求することは有効と言えます。

ポリシーファイルのロードエラー

ポリシーファイルを(URL) から読み込めませんでした

Flash Playerが、示されたURLからポリシーファイルを取得しようとしたときに、エラーが発生しました。 この問題の原因としては、ネットワークの問題、この場所でサーバが実行されていない、またはサーバが実行されているが、要求された場所が認識されなかった（HTTP 404エラーなど）などが考えられます。 このメッセージは、loadPolicyFileに渡された場所の場合はエラーとして、Flash Playerがデフォルトで要求したHTTP/HTTPS/FTPの場所の場合は警告として表示されますが、Flash Playerがデフォルトで要求したソケットポリシーファイルの場所については表示されません。

構文が正しくないため、(URL) のポリシーファイルは無視されます。

Flash Playerが、示されたURLからポリシーファイルを取得しましたが、このポリシーファイルに無効なシンタックスが含まれていました。 ポリシーファイルは無視され、一切の操作は許可されません。 正しいシンタックスが適用される理由、およびどのような一般的な種類の正しくないシンタックスがこのエラーを発生させるかについての詳細は、不正な形式のポリシーファイルに関する節を参照してください。 このポリシーファイルを管理する責任者は、正しくないシンタックスをできるだけ早く修正する必要があります。 このルールは、フェーズ１以前から適用されています（Flash Playerバージョン9.0.47.0以降）。

Content-Type '(content-type)' が正しくないため、(URL) のポリシーファイルは無視されます。

Flash Playerが、示されたURLからHTTPポリシーファイルを取得しましたが、このポリシーファイルのHTTP Content-Typeが標準ポリシーファイルと矛盾していました。 このサーバを保護するために、このポリシーファイルは無視され、一切の操作は許可されません。 詳細については、Content-Typeのホワイトリストの節を参照してください。 このポリシーファイルを管理する責任者は、不適切なContent-Typeをできるだけ早く変更する必要があります。

Content-Type が見つからないため、(URL) のポリシーファイルは無視されます。

上記のエラーに似ていますが、Content-Typeが見つかりませんでした。

(URL) へのクロスドメインリダイレクトが発生したため、(URL) から要求されたポリシーファイルは無視されます。

Flash Playerが、示された最初のURLからポリシーファイルを取得しようとしましたが、別のドメインにある、示された２番目のURLにリダイレクトされました。 この処理は禁止されています。 このポリシーファイルは無視され、一切の操作は許可されません。

(URL) のポリシーファイルは、メタポリシー '(meta-policy)' により無視されます。

Flash Playerが、示されたURLからポリシーファイルを取得しましたが、そのポリシーファイルのサーバのマスターポリシーファイルの<site-control>タグ、またはX-Permitted-Cross-Domain-Policies HTTPヘッダのいずれかで、示されたメタポリシーも見つかりました。 示されたメタポリシーは、このファイルをポリシーファイルとして有効にすることを明確に禁止しています。このため、このポリシーファイルは無視され、一切の操作は許可されません。 このメッセージ自体は必ずしも問題を示すものではありませんが、このポリシーファイルを有効にしようとする場合は、そのContent-TypeまたはFTPファイル名を変更するか、メタポリシーを変更する必要があります。

X-Permitted-Cross-Domain-Policies: none-this-response により、 (URL) のポリシーファイルは無視されます。

Flash Playerが、示されたURLからHTTPポリシーファイルを取得しましたが、HTTP応答ヘッダX-Permitted-Cross-Domain-Policies: none-this-responseも見つかりました。これは、このHTTP応答はポリシーファイルとして使用することが許可されていないことを示すサーバからの指示です。 通常、このヘッダはサーバスクリプトによるポリシーファイルの生成を防止するために使用されます。詳細については、ソケットメタポリシーの節を参照してください。 このポリシーファイルは無視され、一切の操作は許可されません。 このサーバを管理していて、このポリシーファイルにより操作を許可する必要がある場合は、サーバ設定を変更して、none-this-responseヘッダが生成されないようにする必要があります。

(URL) のソケットポリシーファイルは、サイズが大きすぎるため無視されます。 ソケットポリシーファイルのサイズは、20 KB 以下であることが必要です。

Flash Playerが、示された場所からソケットポリシーファイルを取得するプロセスを開始しましたが、受信するデータが大きすぎてダウンロードが中断されました。 このポリシーファイルは無視され、一切の操作は許可されません。 この中断はサーバを保護するために行われたものです。Flash Playerはポリシーファイルのサイズが大きいことを想定していないため、サイズの大きなポリシーファイルのダウンロードを中断して、エラー状況と思われるファイルがサーバにロードされないようにします。 このファイルが有効なソケットポリシーファイルである場合は、20KB以下になるようにサイズを縮小してみてください。

メタポリシーの誤った設定

(URL) の HTTP ヘッダに認識されないメタポリシーがあります : (meta-policy)

示されたURLからのX-Permitted-Cross-Domain-Policies HTTPヘッダで、無効なメタポリシーが指定されていました。 このメタポリシーは無視されました。 これは、誤った設定であり、サーバ上で修正する必要があります。 詳細については、メタポリシーの節を参照してください。

(URL) のポリシーファイルに認識されないメタポリシーがあります : (meta-policy)

示されたURLのマスターポリシーファイルの<site-control>タグで、無効なメタポリシーが指定されていました。 このメタポリシーは無視されましたが、ポリシーファイル自体は必ずしも無視されません（無視される場合は、追加のエラーメッセージが表示されます）。 このポリシーファイルの内容を管理する責任者は、有効なメタポリシー名が含まれるように、<site-control>タグを修正する必要があります。 詳細については、メタポリシーの節を参照してください。

(URL) の HTTP ヘッダのメタポリシーが競合しています : (meta-policy)

示されたURLからの１つ以上のX-Permitted-Cross-Domain-Policies HTTPヘッダに、複数の競合するメタポリシーが見つかりました。 サーバから受信したとおりの、メタポリシーストリング全体が表示されます。 複数のX-Permitted-Cross-Domain-Policiesヘッダが指定されていた場合、通常のHTTPヘッダと同じように、セミコロンで区切られた複数の値を持つ単一のヘッダとして結合されて表示されます。 Flash Playerは、このストリングで検出された最も厳しいメタポリシーを適用しました。 これは、誤った設定であり、サーバ上で修正する必要があります。 通常、複数のメタポリシーをHTTP応答ヘッダに指定することは無効です。唯一の例外は、他のメタポリシーと組み合わせることができるnone-this-responseだけですが、これは、見つかった個々のHTTP応答にのみ影響を与えます。 詳細については、メタポリシーの節を参照してください。

メタポリシー(meta-policy) ((URL) の HTTP ヘッダ) が、 以前に設定されたメタポリシー(meta-policy) と競合しています。

Flash Playerが、示されたURLのサーバから一貫性のないメタポリシーの宣言を見つけました。 Flash Playerはこのサーバから検出された最も厳しいメタポリシーを適用しましたが、比較的厳しくないメタポリシーが最初に見つかった場合は、後で矛盾が見つかるまで、この比較的厳しくないメタポリシーが有効になります。 これは、誤った設定であり、サーバ上で修正する必要があります。 詳細については、メタポリシーの節を参照してください。

メタポリシー(meta-policy) ((URL) のポリシーファイル) が、 以前に設定されたメタポリシー(meta-policy) と競合しています。

上記のエラーに似ていますが、HTTPヘッダではなく<site-control>タグで競合するメタポリシーファイルが見つかりました。

(URL) のポリシーファイルの <site-control> タグは無視されます。 このタグは、マスターポリシーファイルでのみ使用できます。

示されたURLからのポリシーファイル内に<site-control>タグを見つかりましたが、このポリシーファイルはマスターポリシーファイルではありませんでした。 この<site-control>タグは無視されましたが、ポリシーファイル自体は必ずしも無視されません（無視される場合は、追加のエラーメッセージが表示されます）。 <site-control>タグが有効なのは、マスターポリシーファイル（HTTP/HTTPS/FTPサーバの/crossdomain.xml、 またはポート843からのソケットポリシーファイル）内のみです。 このサーバを管理する責任者は、このポリシーファイルから<site-control>タグを削除し、このサーバが他の方法（マスターポリシーファイルまたはHTTP応答ヘッダ）で有効なメタポリシーを宣言していることを確認します。 詳細については、メタポリシーの節を参照してください。

(URL) のポリシーファイルの <site-control> タグは無視されます。 'by-content-type' メタポリシーは、HTTP サイトにのみ適用できます。

示されたURLからのマスターポリシーファイルで<site-control>タグが見つかりました。このタグは、HTTPまたはHTTPSサーバからではないポリシーファイルのメタポリシーby-content-typeを指定しています。 この<site-control>タグは無視されましたが、ポリシーファイル自体は必ずしも無視されません（無視される場合は、追加のエラーメッセージが表示されます）。 by-content-typeメタポリシーは、FTPサーバまたはソケットサーバからは利用できないContent-Typeヘッダに依存するため、HTTPおよびHTTPSサーバでのみ有効です。 このサーバを管理する責任者は、このサーバの有効なメタポリシーを選択する必要があります。 詳細については、メタポリシーの節を参照してください。

(URL) の HTTP ヘッダはメタポリシー 'by-ftp-filename' を指定します。 これは、HTTP ではなく FTP でのみ適用できます。

示されたURLからポリシーファイルを取得している際に、X-Permitted-Cross-Domain-Policies HTTP応答ヘッダが見つかりました。このヘッダは、メタポリシーby-ftp-filenameを指定しています。 X-Permitted-Cross-Domain-Policiesヘッダは無視されましたが、このURLのポリシーファイルは必ずしも無視されません（無視される場合は、追加のエラーメッセージが表示されます）。 by-ftp-filenameメタポリシーは、FTPサーバでのみ有効です。 このサーバを管理する責任者は、このサーバの有効なメタポリシーを選択する必要があります。 詳細については、メタポリシーの節を参照してください。

(URL) のポリシーファイルの <site-control> タグは無視されます。 'by-ftp-filename' メタポリシーは、FTP サイトにのみ適用できます。

上記のエラーに似ていますが、HTTPヘッダではなく<site-control>タグで無効なメタポリシーが見つかりました。

(URL) のポリシーファイルの <site-control> タグは無視されます。 'none-this-response' メタポリシーは、 X-Permitted-Cross-Domain-Policies HTTP レスポンスヘッダでのみ使用できます。

示されたURLからのマスターポリシーファイルで<site-control>タグが見つかりました。このタグは、ポリシーファイルのメタポリシーnone-this-responseを指定しています。 この<site-control>タグは無視されましたが、ポリシーファイル自体は必ずしも無視されません（無視される場合は、追加のエラーメッセージが表示されます）。 none-this-responseメタポリシーは、X-Permitted-Cross-Domain-Policies HTTP応答ヘッダでのみ有効です。これは、HTTPサーバが、サーバスクリプトによるポリシーファイルの生成を防止するためのメカニズムとしてのみ使用されます。 このサーバを管理する責任者は、このサーバの有効なメタポリシーを選択する必要があります。 詳細については、メタポリシーの節を参照してください。

(URL) のポリシーファイルは、メタポリシー 'none' を宣言することにより、 <allow-access-from> を無効にします。

示されたURLからのマスターポリシーファイルで<site-control>タグが見つかりました。このタグは、メタポリシーnoneを指定していますが、同じポリシーファイルに<allow-access-from>ディレクティブも見つかりました。 宣言されたメタポリシーnoneが、このサーバに対して適用されます。つまり、このサーバでは、ポリシーファイル（マスターポリシーファイル自体を含む）は許可されません。 マスターポリシーファイルは、メタポリシーを宣言する目的でのみ存在することが許可されます。 マスターポリシーファイルには<allow-access-from>ディレクティブが含まれているため、これらのディレクティブは無視されます。 このサーバを管理する責任者は、このポリシーファイルから<allow-access-from>ディレクティブを削除する必要があります。 詳細については、メタポリシーの節を参照してください。

ポリシーファイルの誤った設定

(URL) のポリシーファイル内の 'secure' 属性は無視されます。 'secure' 属性は、HTTPS およびソケットポリシーファイル内でのみ使用できます。

示されたURLから、１つ以上の<allow-access-from>ディレクティブを含むポリシーファイルが見つかりました。このディレクティブには、属性secure="true"またはsecure="false"が指定されていますが、これはHTTPSポリシーファイルでも、ソケットポリシーファイルでもありません。 secure属性は無視されましたが、<allow-access-from>ディレクティブは必ずしも無視されません（無視される場合は、追加のエラーメッセージが表示されます）。 secure属性は、<allow-access-from>ディレクティブで指定されたドメインの強力な認証（つまり、HTTPSのURLのみ）を要求するかどうかをFlash Playerに指示しますが、この属性はHTTPSポリシーファイルとソケットポリシーファイルでのみ有効です。 このルールは、最初にポリシーファイルが導入されたときから適用されています。 これは、ポリシーファイル自体が耐攻撃/耐タンパー性プロトコル（tamper-resistant protocol）を経由して送信されなかったため、中間者攻撃（man-in-the-middle attacker）によってsecure="true"宣言がsecure="false"に書き換えられ、非HTTPS SWFファイルが、このポリシーファイルで明記されたポリシーに反して、このドメインからデータを取得することが可能になる場合があります。 このサーバを管理する責任者は、このポリシーファイルからsecure属性を削除する必要があります。

(URL) のポリシーファイルでは、secure が 'true' になっていますが、 ホスト(host) はローカルコンピュータを参照していないようです。安全でない可能性があります。

示されたURLから、１つ以上の<allow-access-from>ディレクティブを含むソケットポリシーファイルが見つかりました。このディレクティブには、属性secure="true"またはsecure="false"が指定されていますが、ソケットポリシーファイルはローカルマシンから提供されたものではないようです。 secure属性は指定されたとおりに適用されますが、このソケットポリシーファイルが実際にはローカルマシン以外の場所から提供されたものである場合は、セキュリティで保護されていない設定が使用されている可能性があります。 secure属性は、<allow-access-from>ディレクティブで指定されたドメインの強力な認証（つまり、HTTPSのURLのみ）を要求するかどうかをFlash Playerに指示するものであり、ローカルマシンから提供されたソケットポリシーファイルでは有効です。これは、man-in-the-middle攻撃によって別のポリシーファイルに置き換えられる可能性のあるネットワーク伝送がないためです。 ただし、ソケットポリシーファイルがリモートホストから提供された場合は、ソケットポリシーファイルが中間者攻撃（man-in-the-middle attacks）に対して脆弱性のある方法で送信されるため、secure="true"の指定はセキュリティ上誤った認識をもたらす可能性があります。 Flash Playerでは、セキュリティで保護されたチャネルを介してソケットポリシーファイルを取得する方法がまだ用意されていません。 詳細については、ソケットポリシーファイルの節を参照してください。

ポリシーファイルの解析エラー

ドメイン '(domain)' ((URL) のポリシーファイル) の無効な <allow-access-from> タグを無視します。

示されたURLからのポリシーファイルには、domain属性（<allow-access-from>ディレクティブ内）の値として、示されたストリングが含まれていました。 このストリングは有効なドメインとして認識されませんでした。 この特定の<allow-access-from>ディレクティブは無視されますが、同じポリシーファイル内の他のディレクティブは有効となり、受け入れられる可能性があります。 このポリシーファイルを管理する責任者は、この無効なドメインを修正する必要があります。

無効なポート番号指定 '(port-string)' ((URL) のポリシーファイル) を無視します。

示されたURLからのポリシーファイルには、to-ports属性（<allow-access-from>ディレクティブ内）の値として、示されたストリングが含まれていました。 このストリングは有効なポート範囲として認識されませんでした。 ポート範囲には、ワイルドカード*、個別のポート番号、ダッシュで区切られたポート範囲、または個別の番号および範囲のカンマ区切りのリストを含めることができます。 この特定の<allow-access-from>ディレクティブは無視されますが、同じポリシーファイル内の他のディレクティブは有効となり、受け入れられる可能性があります。 このポリシーファイルを管理する責任者は、この無効なポート範囲を修正する必要があります。

製品

ソリューション

業種別ソリューション

サポート

ラーニング

ご購入方法

ダウンロード

会社情報

国・地域および言語の選択

Copyright © 2012 Adobe Systems Incorporated. All rights reserved.

利用条件 | プライバシーポリシーとCookie （更新）

Reviewed by TRUSTe: site privacy statement