各サーバは独自のメタポリシーを宣言します。ホスト全体がソケットメタポリシーを宣言できます。このポリシーは、すべてのポートでそのホストへの低レベルのソケット接続を管理します。低レベルのソケット接続とは、ActionScriptのSocketクラスおよびXMLSocketクラスを使用して開始される接続です。APIが使用され、ソケットメタポリシーの影響を受けることはなく、関与する特定のサーバのメタポリシーの影響のみを受けます。HTTP、HTTPSおよびFTPの各メタポリシーをソケットメタポリシーと区別するために、URLメタポリシーと呼ぶこともあります。ソケットメタポリシーの詳細については、ソケットポリシーファイルの節を参照してください。現在、上記の種類以外のサーバでは、メタポリシーの宣言、またはポリシーファイルの作成は不要です。Playerネットワークプリミティブで許可されるのは、HTTP、HTTPSおよびFTPの各サーバへのソケットレベルでの直接接続のみです。Playerではなくサーバでセキュリティに関する決定を行います)。メタポリシーのオプション使用可能なメタポリシーは次のとおりです。すべてのポリシーファイルが許可されます。このメタポリシーは、ログイン資格情報を必要とするコンテンツを提供しないインターネット上のサーバにのみ適用できます。Content-Typeがtext/x-cross-domain-policyのすべてのポリシーファイルが許可されます。その他のポリシーファイルは許可されません。このメタポリシーは、HTTPサーバおよびHTTPSサーバにのみ使用できます。ほとんどのHTTPサーバはContent-Typeの割り当て方法を柔軟に決定できるため、ポリシーファイルごとに許可を設定する場合には最も便利なオプションです。text/x-cross-domain-policyタイプを割り当てるには、一般に、個々の場所に対してこのタイプを指定するか、またはtext/x-cross-domain-policyをcrossdomain.xmlという名前のファイルに割り当てます。前者の場合は、ポリシーファイルごとに管理者の承認が必要です。後者の場合は、ポリシーファイルが任意の場所に配置されますが、このようなファイルを検索したり、アップロードやその他のコンテンツ作成プロセスでフィルタすることが容易になります。/crossdomain.xmlで終わるポリシーファイル)が許可されます。その他のポリシーファイルは許可されません。このメタポリシーは、FTPサーバにのみ使用できます。必須のファイル名をカスタマイズすることはできません。/crossdomain.xmlにあります)のみが許可されます。ポリシーファイルは許可されません。このメタポリシーをマスターポリシーファイル内で宣言すると、そのマスターポリシーファイルは、このメタポリシーを宣言する目的でのみ存在することになり、<allow-access-from>ディレクティブが含まれていても無視されます。これは、HTTP応答ヘッダでのみ指定できる特別なメタポリシーです。この特定のHTTP応答がポリシーファイルと解釈されないようにすることができます。他のすべてのメタポリシーとは異なり、none-this-responseは、サーバ全体に対するメタポリシーを宣言するのではなく、1つのHTTP応答にのみ影響します。他のすべてのメタポリシーとは異なり、none-this-responseは他のメタポリシーと組み合わせて競合せずに使用できます。none-this-responseと別のメタポリシーの両方が存在する場合、現在のHTTP応答はポリシーファイルになることはできませんが、追加のメタポリシーはサーバ全体に対するメタポリシーであると解釈されます。none-this-responseメタポリシーが主に役に立つのは、ポリシーファイルの生成を許可したくないスクリプトがサーバに含まれる場合です。通常、スクリプトは出力のContent-Typeを選択し、任意のHTTP応答ヘッダを生成できるため、スクリプト出力をフィルタして、出力が適正なポリシーファイルを表すかどうかを確認するのは困難です。(また、スクリプトで独自のメタポリシーHTTP応答ヘッダが生成されても、管理者が指定したメタポリシー以外のオープンなメタポリシーを採用するようにサーバに強制することはできません。これは、最も制限の高いメタポリシーを選択することで、常にメタポリシーの競合が解決されるためです)。メタポリシーの指定方法HTTPサーバ、HTTPSサーバ、またはFTPサーバでメタポリシーを宣言するには、2つの方法があります(ソケットポリシーファイルは動作が異なります)。そのサーバのマスターポリシーファイルでメタポリシーを宣言します。/crossdomain.xmlにあります。<site-control>という新しいタグを、トップレベルの<cross-domain-policy>タグの内側に配置し、この<site-control>タグのpermitted-cross-domain-policies属性で、使用される特定のメタポリシーを指定します。メタポリシーby-content-typeを宣言するポリシーファイルの例を次に示します。permitted-cross-domain-policies="by-content-type"/></cross-domain-policy>X-Permitted-Cross-Domain-PoliciesというHTTP応答ヘッダで、メタポリシーを宣言します。このオプションはFTPサーバでは使用できません。このヘッダを有効にするためには、すべてのHTTP応答と共に返す必要があります。これは、要求がポリシーファイルに対するものかどうかを検出する信頼できる方法がないためです。メタポリシーnoneを宣言するHTTP応答ヘッダの例を次に示します。none(一方がnone-this-responseの場合のみ有効な)2つのメタポリシーを指定する必要がある場合は、X-Permitted-Cross-Domain-Policiesヘッダを2回指定するか、メタポリシー値をセミコロンで区切ったヘッダを1回指定します。どちらの指定もHTTPヘッダでは標準的な方法です。メタポリシーを宣言するには、上記2つの方法のうち1つのみを選択する必要があります。誤って両方の場所でメタポリシーを宣言した場合、HTTP応答ヘッダで宣言したメタポリシーが、マスターポリシーファイルで宣言したメタポリシーよりも優先されます。2つの方法のそれぞれに利点があります。考慮事項は次のとおりです。通常は、新しいHTTP応答ヘッダを返すよりも、マスターポリシーファイルを編集する方が簡単です。マスターポリシーファイルの使用は、HTTPとFTPの両方に有効です。マスターポリシーファイルの使用により、サーバからのすべてのHTTP応答にヘッダを追加する必要がなくなります。HTTP応答ヘッダでメタポリシーを宣言する場合の利点サーバのドキュメントルートディレクトリで常にマスターポリシーファイルを作成できるとは限りません。Playerはマスター以外のポリシーファイルを受け入れる前にマスターポリシーファイルを取得する必要があります。HTTP応答ヘッダでメタポリシーが宣言された場合、マスターポリシーファイルに対する要求は不要です。HTTP応答ヘッダでメタポリシーを宣言する必要があるサーバ構成は、通常は1つのサーバ構成ファイルで管理でき、提供するドキュメントコンテンツを変更する必要がないものです。none-this-responseメタポリシーを指定すると、ポリシーファイルを生成するスクリプトの機能を制御できます。Playerではメタポリシーがby-content-typeであると見なされるというルールを認識しておく必要があります。これは、メタポリシーの宣言に適した方法ではありませんが、誤ってこの状況に陥った場合に備えて、ここに記載しています。デフォルトのメタポリシーサーバがメタポリシーを宣言しない場合、次の2つの結果が考えられます。9.0.115.0から導入されたフェーズ1では、デフォルトのメタポリシーはallです。このフェーズでは互換性が優先されるため、メタポリシーが明示的に選択されるまでサイトは影響を受けません。10.0から導入されるフェーズ2では、デフォルトのメタポリシーはmaster-onlyになります。Playerリリースによっていずれかのコンテンツがポリシーファイルと解釈される前に、サイトはメタポリシーを明示的に選択する必要があります。PlayerがブラウザのネットワークスタックからHTTP応答ヘッダを読み取ることができるかどうかによって決まります。最新のブラウザはこれに対応していますが、一部の古いブラウザは対応していません。HTTP応答ヘッダをサポートしているブラウザ、およびサポートしていないブラウザのリストについては、付録Aを参照してください。PlayerでHTTP応答を読み取ることができない場合は、ポリシーファイルログに警告メッセージが生成され、すべてのドメインでメタポリシーallの適用が想定されます。PlayerがHTTP応答ヘッダを読み取ることができない場合、allメタポリシーの宣言は無視されます(HTTP応答ヘッダではなくマスターHTTPポリシーファイルに表示される宣言も含みます)。対策が必要な理由サーバでメタポリシーを宣言するのには2つの理由があります。10.0以降)をインストールするユーザには適用されなくなります。Player互換コンテンツを意図的に提供するかどうかに関係なく、サーバでテキストファイルを作成できるユーザはポリシーファイルを作成できます。このポリシーファイルを使用すると、サーバまたはユーザ(あるいはその両方)のプライベートなデータを公開できます。Playerのユーザには、デフォルトのメタポリシーallは適用されなくなります。URLメタポリシーの宣言のワークフローでは、メタポリシーを選択および適用するために必要な手順を示します。ソケットポリシーファイルActionScriptのネットワーク接続は、通常、URLに基づき、HTTP、HTTPS、およびFTPを使用して行われます。ActionScriptでは、下位のTCPソケットレベルで直接的にネットワーク接続を行うことができるSocketクラスとXMLSocketクラスもサポートされています。URLによるネットワーク接続は、URLポリシーファイルによって承認されますが、ActionScriptのソケットレベル接続は、ソケットポリシーファイルによって承認されます。9.0.115.0および9.0.124.0では、ソケットポリシーファイルの機能が、部分的に変更されています。これらの変更は、主にDNS強化という目標を達成するためのもので、ActionScriptを利用したDNSリバインディング攻撃によって、不正なソケット接続が行われないようにすることを目的としています。有効なソケットポリシーファイル構成をホストに実装するための簡単な手順については、ソケットポリシーファイルのワークフローを参照してください。サーバホストの管理者は、先にこの概要の節に目を通すことをお勧めします。Player互換コンテンツを提供する予定がない場合でも、一読することをお勧めします。そのようなホストでも、ソケットベースのDNSリバインディング攻撃を受ける可能性はあります。ここでは、メタポリシーの節の内容を前提としているため、必ずメタポリシーの節を先にお読みください。7.0.19.0でソケットポリシーファイルが導入されたときから変更されていない情報を示します。クライアントコンテンツからの接続を承認することです。URLポリシーファイルは、提供元のHTTP、HTTPS、またはFTPの各サーバからのデータロードの承認に使用されますが、ソケットポリシーファイルは、提供元のホストへのソケット接続の承認に使用されます。注:「URLポリシーファイル」、「URLメタポリシー」などの用語は、HTTP、HTTPS、およびFTPを通じたネットワーク接続を表しています。URL」のようにURLを使用して表現される場合がありますが(ActionScriptからloadPolicyFileを呼び出す場合)、ここでは便宜的に上記のような表現を使用します。すべてのポリシーファイルには、許可(接続を承認するドメインのリスト)、およびスコープ(アクセス許可の対象となる一連のリソース)の2つの必須属性が含まれます。ソケットポリシーファイルは、許可に関してはURLポリシーファイルと同様に機能しますが、スコープに関してはURLポリシーファイルとは仕組みが異なります。URLポリシーファイルのスコープは、ポリシーファイルの場所によって決まりますが、ソケットポリシーファイルのスコープは、ファイルの内容によって決まります。to-ports属性によって、ソケット接続を許可するTCPポートを指定します。ソケットポリシーファイルは、ホスト上の任意のTCPポートから提供できますが、ポート1024以上のポートからロードされるソケットポリシーファイルでは、ポート1024以上のポートに対する接続のみ承認できます。1024より小さい番号のポートから読み込まれるソケットポリシーファイルでは、ホスト上の任意のポートに対する接続を承認できます。ソケットポリシーファイルは、メイン接続(ActionScriptによって行われるソケット接続で、ソケットポリシーファイルによって承認される)と同じポートから提供することも、メイン接続とは別のポートから提供することもできます。Playerから<policy-file-request/>で転送を指定)、ポリシーファイル要求とメイン接続要求を区別して応答できるようにする必要があります。通常は、ソケットポリシーファイルを別のポートから提供する方が簡単です。これにより、ホストのソケットポリシーを1か所で集中管理できます。ほとんどのサーバには、自身のソケットポリシーファイルを提供する機能が備わっていません。URLポリシーファイルのマスター場所として認識していました。Playerでは、ソケットポリシーファイルの固定のマスター場所を認識していませんでした。9.0.115.0では、ソケットマスターポリシーファイルという概念を導入し、このファイルを固定のTCPポート番号843から提供します。ソケットマスターポリシーファイルを使用することにより、次のような様々なニーズに対応できます。ポート番号を固定することで、ソケットポリシーをホストから提供するための標準的な方法が確立されます。以前は、各ホストの管理者が自分でソケットポリシーファイルの提供ポートを決定する必要がありました。固定のポート番号が与えられたことで、スタンドアロンのソケットポリシーファイルサーバをポート843にデフォルトでバインドできるため、管理者は慣れないコンピュータでもソケットポリシーを簡単に見つけることができます。マスター場所が決定されたことで、ソケットメタポリシーを宣言できるようになりました。ソケットメタポリシーは、以前説明したURLメタポリシーと同様、ホスト上に配置できるソケットポリシーファイルの種類を制御するためのものです。これについては、後述のソケットメタポリシーに関する節で詳しく説明します。Playerのフェーズ1バージョンでも、ホスト管理者が新しいソケットルールの使用を選択できるようになります。これについては、後述の「厳密なソケットルールの使用」の節で詳しく説明します。Playerにソケットポリシーファイルの場所を指示しなくても、自動的にソケットポリシーファイルが呼び出されます。注:アドビでは、ソケットポリシーファイルサーバに関する情報ページを公開する予定です。このページでは、ソケットポリシーファイルの提供だけを行うサーバを作成するための手順やサンプルコードを紹介します。Authority)に対し、TCPポート843をソケットポリシーファイルの提供用に予約するよう申請しています。これには時間がかかることが予想されますが、その間にポート843の使用目的に関する文書をできる限り広く公開したいと考えています。ポート番号843は1024よりも小さいため、ソケットマスターポリシーファイルでは、ホスト上の任意のポートに対するアクセスを承認できます。Unixスタイルのホストでは、通常、サーバを1024未満のポートにバインドするにはルートアクセス(管理者権限)が必要なため、1024の境界は重要な意味を持ちます。Unixスタイルのホストでソケットマスターポリシーファイルをセットアップするには、通常はルートアクセスが必要になるため、ホストを有効に保護できます。ソケットマスターポリシーファイルをファイアウォール経由で提供する場合は、ファイアウォールのトラバースに関する問題についての節を参照してください。ソケットメタポリシーソケットメタポリシーは、URLメタポリシーと同様の機能を果たします。次のような違いがあります。ソケットメタポリシーは、URLポリシーファイルではなく、ソケットポリシーファイルを対象としています。ソケットメタポリシーは、1つのURLサーバだけではなく、ホスト全体を対象としています。ソケットメタポリシーは、ソケットマスターポリシーファイル内でのみ宣言できます。シンタックスは、URLマスターポリシーファイルでのメタポリシーの宣言と同様、<site-control>タグを使用します。ソケットメタポリシーは、HTTPとは無関係なため、HTTP応答ヘッダでは宣言できません。ソケットメタポリシーでは、URLメタポリシーとして使用できるメタポリシーのセットとは異なるメタポリシーのセットを使用します。ソケットメタポリシーとURLメタポリシーでは、デフォルト値が異なります。有効なソケットメタポリシーは次のとおりです。このホストでは、任意のポートからソケットポリシーファイルを提供できます。このメタポリシーは、ログイン信用情報を必要とするコンテンツを提供しないインターネット上のホストにのみ適用できます。このホストでは、ソケットマスターポリシーファイル(ポート843から提供)のみ使用できます。このホストでは、ソケットポリシーファイルを提供できません。このメタポリシーをマスターポリシーファイル内で宣言すると、そのマスターポリシーファイルは、このメタポリシーを宣言する目的でのみ存在することになり、<allow-access-from>ディレクティブが含まれていても無視されます。デフォルトのソケットメタポリシーはallです。Playerでは、ソケットマスターポリシーファイル内でソケットメタポリシーが宣言されていないすべてのホストについて、メタポリシーがallであるものと見なされます。Playerのフェーズ1とフェーズ2のどちらについても、デフォルト値はallです。この点は、URLポリシーファイルとは異なります。URLメタポリシーのデフォルト値は、フェーズ2ではmaster-onlyになります。このように、ソケットポリシーファイルのデフォルトのメタポリシーは、URLポリシーファイルほど厳密ではありません。これは、ソケットでは、URLサーバと比べて、不正ポリシーファイルが使用される危険性が非常に低いためです。HTTPサーバでは、ユーザが作成したコンテンツ(サーバ管理者以外の人が作成したコンテンツ)が提供されることが珍しくないため、フェーズ2でデフォルトのURLメタポリシーをmaster-onlyにすることによって、誰かがポリシーファイルを作成する前に、管理者が事前にポリシーファイルを使用できるようにしておくことは、有効な手段です。ホストで認証を受けていないユーザがインストールを実行したり、TCPポートをリッスンするサーバ全体を変更したりすることが許可されることはめったにないため、デフォルトのソケットメタポリシーをallにすることによって、管理者が明示的に禁止しない限り、ホスト上の任意の場所にソケットポリシーファイルを作成できるようにしておくことも重要です。9.0.115.0で行われた主な変更は、厳密なソケットルールの導入です。厳密なソケットルールとは、次の2つです。ソケットポリシーファイルがない場合、SWFファイルから自身のドメインにソケット接続を行うことができなくなりました。9.0.115.0より前のバージョンでは、ポリシーファイルがなくても、SWFファイルから自身のドメインの1024以上のポートに対してソケット接続を行うことが許可されていました。ソケット接続の承認にHTTPポリシーファイルを使用できなくなりました。提供)を使用して、同じホスト上の1024以上のポートに対するソケット接続を承認することができました。これら2つのルールを簡単な表現にまとめると、「厳密なソケットルールでは、すべてのソケット接続にはソケットポリシーファイルによる許可が必要である」ということになります。Player9のほとんどのポリシーファイルに関する変更と同様、厳密なソケットルールは、2段階のフェーズに分けて導入されました。Playerのデバッグバージョンで警告が表示されるだけでした。9.0.124.0から開始)では、これらの警告がエラーとなり、以前のルールに従って作成されたSWFファイルが意図通りに機能しなくなる恐れがありました。Playerのフェーズ1バージョンを使用しているユーザについてもDNSリバインディング攻撃からサイトを保護できるよう、厳密なルールの適用がフェーズ1の段階から選択肢として提供されていました。ソケットポリシーファイルのワークフローでは、厳密なソケットルールの導入によって発生する問題を発見および解決するための詳細な方法が示されています。要約すると、上記2つのうちいずれかの状況でソケット接続を行うSWFファイルを管理している場合、接続先のホストでソケットポリシーファイルが提供されている必要があります。ソケットポリシーファイルを提供するには、通常、ポート843にソケットマスターポリシーファイルサーバをセットアップしますが、これ以外の方法については、ワークフローに関する節を参照してください。Playerのフェーズ1バージョンでは、次のように構成することにより、ホストで厳密なソケットルールが使用されるようになります。これは、ホスト管理者とSWFファイルの保守担当者の両者にとって重要な情報です。ホスト管理者は、この情報に従って、より安全なルールを管理対象のホストに適用することを選択でき、SWFファイルの保守担当者は、このような構成によって、保守対象のSWFファイルがソケット接続を行うことができるかどうかにどのような影響があるのかを理解する必要があるからです。ホストが、ポート843からソケットポリシーファイルを提供する場合(ソケットマスターポリシーファイル)、厳密なソケットルールがホスト全体に適用されます。これは、ポリシーファイルの内容に関係なく実行されます。ソケットマスターポリシーファイルが空である場合や、メタポリシーallが宣言されている場合でも、ホストでは厳密なソケットルールが使用されます。このホストにソケット接続を行うには、必ずソケットポリシーファイル(多くの場合、厳密なソケットルールへの移行の原因となったソケットマスターポリシーファイルと同じポリシーファイル)による許可が必要になります。これは、ホスト管理者が厳密なソケットルールの適用を選択する場合に使用する一般的なメカニズムです。/crossdomain.xml)で宣言している場合、そのマスターHTTPポリシーファイルでは、同じホストへのソケット接続に対する承認が行われません。この構成では、2つの厳密なソケットルールのうち、1つだけがホストに適用されます。SWFファイルによる同じホストへの接続に関するルールは、適用されません。マスター以外のソケットポートからソケットポリシーファイルを提供する場合、厳密なソケットルールは、そのポートにのみ適用されます。このポートにソケット接続を行うには、必ずソケットポリシーファイル(多くの場合、このポートから提供されているソケットポリシーファイルと同じポリシーファイル)による許可が必要になります。このルールによって発生する可能性のある意図しない影響については、即時に適用される厳密なソケットに関する節で説明しています。その影響とは、1024以上のソケットポートから提供されるソケットポリシーファイルのリストに自身のドメインが含まれていない場合、そのドメインのSWFファイルが接続できなくなることです(以前はポリシーファイルがなくても接続できました)。Playerでは、HTTPSサーバからのポリシーファイルにおいて、<allow-access-from>ディレクティブのsecure="true"という特殊な属性がサポートされています。secure="true"を指定すると、そのドメイン内、または同じ<allow-access-from>ディレクティブのリストに記載されたドメインのSWFファイルは、そのSWFファイル自体がHTTPS経由で取得された場合にのみ、データを取得できます。(HTTPSにはドメイン認証と耐タンパー性のテクノロジが組み込まれているため、HTTPS経由で取得されるSWFファイルは、HTTP経由で取得されるSWFファイルよりも、偽造の可能性が低いと言えます)。実際には、HTTPSポリシーファイルでは、secure="true"がデフォルトの動作になっています。これをオーバーライドするには、HTTPSポリシーファイルで、明示的にsecure="false"と宣言する必要がありますが、これはお勧めしません。Playerでは、secure="true"宣言が新しい状況でサポートされます。Playerと同じコンピュータから実行されているソケットサーバ)で提供されるソケットポリシーファイルでもサポートが開始されます。secure="true"が、ローカルソケットポリシーファイルの<allow-access-from>ディレクティブで宣言されている場合、そのドメイン内、または同じ<allow-access-from>ディレクティブのリストに記載されているドメインのSWFファイルは、そのSWFファイルがHTTPS経由で取得された場合にのみ、許可されたポートに接続できます。この機能を使用したローカルソケットポリシーファイルの例を次に示します。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ファイルは、ローカルコンポーネントに接続できなくなります。Playerをインストールしている必要があります。これより前のバージョンでは、secure="true"ディレクティブは無視されてしまいます。Playerと同じコンピュータで実行されているソケットサーバ)以外から提供されるソケットポリシーファイルで、secure="true"ディレクティブを使用することはお勧めしません。Playerでは、ローカルホスト以外から取得されたと思われるソケットポリシーファイルでsecure="true"が検出されると、ポリシーファイルログに警告が記録されます。Playerでは、ローカル以外のソケットポリシーファイルにsecure="true"が含まれていても、実際にはこれに従いますが、ソケット接続がローカルホストに対するものかどうかを100%の信頼度で判断することはできないため、このような警告が記録されます。ローカルホスト以外から提供されるソケットポリシーファイルでsecure="true"を宣言することによって、安全性が阻害される可能性がある理由を説明します。Playerには安全なソケットレベルのネットワーク接続機能が備わっていません。ソケットレベルのHTTPSに相当するもの(いわばソケットレベルのSSLおよびTLS)が、まだ存在しないということです。したがって、ソケットポリシーファイルは、常にSSLおよびTLSを利用せずに取得されます。attacks、ネットワーク上のクライアントとサーバの間に存在する第三者が、クライアントやサーバに気づかれずにネットワーク上の対話の内容を変更する)を受けやすいと言えます。attacker)によって、この宣言がsecure="false"に置き換えられる可能性があります。(secure="true"の使用がHTTPSポリシーファイルのみで許可されており、HTTPポリシーファイルでは許可されていないのも、同じ理由からです)。Playerに転送するときに、ホストの外部でネットワーク接続が行われることはありません。このため、ローカルソケットポリシーファイルでは、secure="true"が有効であると言えます。9.0.115.0で行われたソケットポリシーファイルに対する変更の1つは、ActionScriptには影響せず、その内容も変更されません。Playerがドメインa.comからのソケットポリシーファイルを検出すると、そのポリシーファイルがa.comに対するすべてのソケット接続の承認に使用されていました。この方法では、DNSリバインディングにより、ソケット接続時にa.comの参照先がポリシーファイルの取得時とは異なるホストに設定される可能性があります。あるホストが別のホストに対するアクセス権を指定することになります。バージョン9.0.115.0からは、ソケット接続を許可する前に、ソケットポリシーファイルが接続先のホストと同じIPアドレスから取得されたものであるかどうかが、常にチェックされます。9.0.115.0では、ホストで通常とは少し異なるトラフィックが発生する場合があるため、その調整が行われます。トラフィックの相違点は、次のとおりです。Playerではまずポート843にアクセスして、ホストでソケットマスターポリシーファイルが提供されているかどうかを確認します。3.0のソケット接続で実行されるポリシーファイルの確認に関するデフォルトの動作は変更されません。3.0のソケット接続では、メイン接続と同じポートに対するチェックがデフォルトで行われていました)。Playerは、その場所にポリシーファイルが存在しないものと判断してその試行を中止し、ポリシーファイルログに警告を記録して、ソケットポリシーファイルによる承認の次の段階へ移行します。Playerが成功する可能性のないソケット接続を長時間待機することがなくなりますが、一時的なネットワークの停止や、低速な接続、サーバに過剰な負荷がかかっている状況などに対する柔軟性が、若干損なわれることになります。このような状況がなければ自動的に取得されるソケットポリシーファイルが存在することがわかっている場合は、SWFファイルから明示的にloadPolicyFileを呼び出し、そのソケットポリシーファイルのURLを指定することにより、3秒のタイムアウト動作が実行されないようにすることができます。これにより、そのポリシーファイルの取得待機時間を長くすることができ、TCPのタイムアウト(2分間)が経過するまで、次の段階に移行しないようにすることができます。Playerによる取得試行動作に設定された3秒間のタイムアウトが実行されないようにするには、ActionScriptからloadPolicyFile("xmlsocket://mysite.com:843")を呼び出します。ファイアウォールのトラバースに関する問題とソケットポリシーファイルソケットマスターポリシーファイルの欠点は、クライアントがポート843にアクセスできなければならないことです。アウトバウンド通信を制限するファイアウォールの内側にいるユーザの中には、これができない人もいます。アウトバウンド通信を制限するファイアウォールでも、ポート843へのアクセスを許可することは有効です。Playerにおいて、ホスト管理者が宣言したセキュリティポリシーを適用できるようになります。ポート843の目的を標準化することができれば、他の種類のサーバがこのポートに関連付けられることがなくなります。ソケットマスターポリシーファイルは新しい概念であり、ファイアウォールのルールセットにポート843へのアクセスが組み込まれるようになるまでには、まだ時間がかかります。ここでも、ポート843へのアクセスを許可するかどうかについては、ファイアウォール管理者個人の裁量に委ねられます。Playerユーザやサーバホストに深刻な問題を引き起こすことがない理由を説明します。ポート843にアクセスできないことによる影響は、次のとおりです。ソケットメタポリシーが遵守されません。すべてのソケットポリシーファイルによるアクセス許可の付与が認められます(ただし、ファイアウォールの内側にいるユーザについてのみ)。Playerに認識されません。ファイアウォールの内側にいるユーザは、依然として1024以上のソケットポートを対象としたDNSリバインディング攻撃の媒介者となる可能性があります。ホストでソケットマスターポリシーファイルを使用してソケット接続の承認を行っている場合、ファイアウォールの内側にいるユーザは、このような接続を確立できません。このような影響により、細かい問題が発生する場合もありますが、大きな問題にはなりません。その理由は次のとおりです。ユーザがファイアウォールの内側におり、ポート843にアクセスできない場合、対象のポートにもアクセスできない可能性があるため、上記3つのデメリットが実質的に問題にならなくなります。ファイアウォールで常に接続が許可されているポートにはいくつかありますが(HTTPの80など)、多くのポートへのアクセスは許可されておらず、1024以上のほとんど、またはすべてのポートへのアクセスも許可されていない可能性が高いと言えます。この最後の点により、特に問題2が発生することはほとんどないと考えられます。ファイアウォールの内側を対象としたDNSリバインディング攻撃で、ポート843へのアクセスが問題になることは少ないと考えられます。これは、ファイアウォールでその内側にあるサーバのすべてのポートへのアクセスがブロックされることはめったにないからです。上記の問題1について、ソケットメタポリシーによる制限を回避しようとする攻撃者(そのような攻撃者自体がほとんどいない)が、アウトバウンド通信を制限するファイアウォールの内側にいるユーザを特に媒介者として利用しようとする可能性は低いと考えられます。対策が必要な理由ホストでソケットポリシーファイル(多くの場合ポート843のソケットマスターポリシーファイル)を提供する理由は、次の2つです。9.0.124.0またはそれ以降)をインストールするユーザについては、このようなSWFファイルからソケット接続を行うことができません。Player互換のコンテンツをまったく提供する予定がない場合でも、悪意ある攻撃者がDNSリバインディング攻撃によってホストに不正なソケットレベルの接続を行おうとする可能性があります。Playerのフェーズ1バージョンのユーザが、そのような攻撃の媒介者になることがなくなります。ソケットポリシーファイルの構成のワークフローでは、マスターソケットポリシーファイルをホストから提供するために必要な手順を示します。10.0の変更点に関連する問題にすばやく対処できるようになります。この記事の前半にある、変更点に関する概要の節を読んでから、この節を参照することをお勧めします。9.0.115.0では、ポリシーファイルログという新機能が導入されました。ポリシーファイルログには、ポリシーファイルの取得、ポリシーファイルの処理が正常に終了したか失敗したか、ポリシーファイルに依存する要求の結果など、ポリシーファイルに関連するすべてのイベントのメッセージが表示されます。ポリシーファイルログに表示されるメッセージの一覧については、付録Bを参照してください。ポリシーファイルログを使用するには、次の手順を実行します。9.0.115.0以降のデバッグバージョンをインストールします。Playerを使用できます。Playerサポートセンターのダウンロードページから入手できます。mm.cfg構成ファイルの場所を探します。Playerが起動時に読み取る一般的なデバッグ構成ファイルです。mm.cfgは「ホーム」ディレクトリにあります。一般的な例を次に示します。/Users/ユーザ名mm.cfgが存在しない場合は作成し、次の行の1つまたは両方を追加します。startupPolicyFileLogAppendが有効になっていない場合は、新しいルートレベルの各SWFによりログファイルがクリアされます。PolicyFileLogAppendが有効になっている場合は、ログファイルの前の内容が常に保持され、最終的にはログファイルが大きくなります。テスト中に複数の異なるルートレベルのSWFファイルがロードされる場合は、PolicyFileLogAppendを有効にします。PolicyFileLogAppendを有効にした場合は、適宜手動でログファイルの名前を変更するか、またはログファイルを削除する必要があります。この作業を行わないと、ログファイルが非常に大きくなり、前の出力が終了した場所と新しい出力が開始された場所を見つけるのが難しくなります。policyfiles.txtというポリシーファイルログが書き込まれる場所を探します。このログは必ずしも存在しているとは限りません。Playerによって作成されます。policyfiles.txtは次の場所にあります。通常とは異なり、この場合はプログラムがログファイルをPreferencesディレクトリに書き込みます。Playerを閉じます。これで、policyfiles.txtがLogsディレクトリに作成されます。最新の変更時刻であることを確認します。loaded」)が表示されていることを確認します。メッセージが表示されている場合、ポリシーファイルログは機能しています。テストする必要があるすべてのSWFコンテンツにアクセスします。ポリシーファイルの取得を伴うシナリオを使用して、コンテンツを実行します。Playerを閉じます。テストの実行中にポリシーファイルで行われた処理の詳細について、policyfiles.txtを確認します。不明なメッセージがある場合は、付録Bを参照してください。Playerを実行したときにログが上書きされないようにします。9.0.115.0のいくつかの変更点は、SWFコンテンツに直ちに影響するため、ごく一部のSWFファイルで問題が発生する可能性があります。現状のSWFコンテンツを保持する場合は、早急に次の手順を実行する必要があります。9.0.115.0以降のデバッグバージョンをインストールします。Playerを使用して、本番環境をシミュレートします。ActiveXプレーヤーまたはプラグインプレーヤーを使用できます。どちらを使用しても結果は同じになります。Playerサポートセンターのダウンロードページから入手できます。PlayerのHTTP応答ヘッダをサポートできる最新のブラウザを使用するようにします。これにより、即時解決を要する問題に対する完全なテストを実施できるようになります。この要件を満たすブラウザの詳細については、付録Aを参照してください。上記のように、ポリシーファイルログを有効にします。SWFコンテンツをテストします。できるだけ多くのコンテンツを実行するようにします。Playerを閉じ、ポリシーファイルログを確認します。ポリシーファイルログで、[strict]というラベルを含むメッセージを探します。このラベルは、即時解決を要する問題の可能性があることを示しています。期待どおりに機能していないコンテンツの状況をメモします。そのようなコンテンツは、デバッグが必要な問題を示している可能性があります。9.0.115.0での動作と異なることを確認します。Playerの間で動作に違いがない場合は、ポリシーファイルの厳密な対処に関連する問題ではありません。Uninstallerを使用します。ActiveXコントロールのセキュリティ機能により、次の「/clean」コマンドを使用してアンインストーラを実行する必要があります。Playerの提供について」にアクセスします。ポリシーファイルログで見つかった[strict]メッセージを分類します。メッセージの内容は次のとおりです。syntax.不正な形式のポリシーファイルは無視されているため、クロスドメインアクセスが拒否される可能性があります。このログメッセージの説明、および不正な形式のポリシーファイルについての節を参照してください。scope.ポリシーファイルのリダイレクトによって、ポリシーファイルのスコープが変更される可能性があり、その結果、クロスドメインアクセスが拒否される可能性があります。このログメッセージの説明、およびドメイン内のリダイレクトについての節を参照してください。'(content-type)'.サーバで宣言された必須のテキストのContent-TypeがないHTTPポリシーファイルが受信されましたが、無視されます。クロスドメインアクセスが拒否される可能性があります。このログメッセージの説明、およびContent-Typeのホワイトリストについての節を参照してください。Content-Type.サーバで宣言された必須のテキストのContent-TypeがないHTTPポリシーファイルが受信されましたが、無視されます。クロスドメインアクセスが拒否される可能性があります。このログメッセージの説明、およびContent-Typeのホワイトリストについての節を参照してください。file.SWFコンテンツは、ローカルホスト上にあると思われるソケットに接続しようとしましたが、ホストがlocalhostとして指定されていませんでした。厳密なソケットルールが直ちに適用され、アクセスが拒否されます。このログメッセージの説明、および即時に適用される厳密なソケットについての節を参照してください。URLメタポリシーの設定メタポリシーの節で説明したように、HTTPサーバ、HTTPSサーバ、またはFTPサーバでメタポリシーを選択および宣言するのは2つの理由があります。10.0以降)をインストールするユーザには適用されなくなります。Playerのユーザ向けにスムーズに移行されます。Player互換コンテンツを意図的に提供するかどうかに関係なく、サーバでテキストファイルを作成できるユーザはポリシーファイルを作成できます。このポリシーファイルを使用すると、サーバまたはユーザ(あるいはその両方)のプライベートなデータを取得できます。Playerのユーザには、デフォルトのメタポリシーallは適用されなくなります。管理していないサーバ上のサイトを操作している場合は、ホストされるサービスのユーザ向けの考慮事項についての節を参照してください。管理しているサーバ上のメタポリシーを設定するには、次の手順を実行します。メタポリシーの基本をよく理解します。使用可能なメタポリシーのリストを確認します。サーバに最も適したメタポリシーを決定します。HTTPサーバおよびHTTPSサーバ向けのガイドラインを次に示します(FTPサーバ向けのガイドラインも似ていますが、詳細が若干異なります)。サーバでポリシーファイルを提供しない場合は、メタポリシーnoneを選択します。サーバがユーザ定義コンテンツを提供する場合は、ユーザがポリシーファイルを作成できないようにするメタポリシー方針を選択します。これは基本的に、allを選択しないことを意味します。by-content-typeを選択した場合は、ユーザ定義コンテンツでContent-Typeにtext/x-cross-domain-policyを割り当てるための条件を満たすことができなくなります。サーバへのアップロード権限を持つユーザが、ポリシーファイルを簡単に作成できるようにするには、メタポリシーallを選択します。/crossdomain.xmlにあるマスターポリシーファイルの内容を変更できるようにします。個別に承認された場所にマスター以外のポリシーファイルを配置するには、メタポリシーby-content-typeを選択し、指定された場所にtext/x-cross-domain-policyのContent-Typeを割り当てます。これを実行するためのApache設定スニペットの例を次に示します。text/x-cross-domain-policy</Location>事前に決められた場所にマスター以外のポリシーファイル(crossdomain.xmlという名前のファイルなど)を配置するには、メタポリシーby-content-typeを選択し、条件を満たす場所にtext/x-cross-domain-policyのContent-Typeを割り当てます。これを実行するためのApache設定スニペットの例を次に示します。text/x-cross-domain-policy</Files>ポリシーファイルの生成を許可したくないスクリプトをサーバがホストしている場合、このようなスクリプトの出力に特別なメタポリシーnone-this-responseを追加します。これを実行するためのApache設定スニペットの例を次に示します。(FTPサーバはマスターポリシーファイルを使用する必要があります)。各方法の長所と短所について、メタポリシーの指定方法に関する節を確認してください。/crossdomain.xmlにあるマスターポリシーファイルに書き込みます。permitted-cross-domain-policies="by-content-type"/></cross-domain-policy>HTTP応答ヘッダでメタポリシーを宣言する場合は、適切なX-Permitted-Cross-Domain-Policiesヘッダを返すようにサーバを設定します。これを実行するためのApache設定スニペットの例を次に示します。master-only</Location>ホストされるサービスのユーザ向けの特別な考慮事項ホストされるサービス上のサイト、または完全には管理していないサーバを操作していて、ポリシーファイルを提供する場合は、以下の点を考慮します。9.0.115.0の動作が停止した場合は、即時解決を要する問題に対するワークフローを実行します。サーバ管理者が対応しなくても、見つかったほとんどの問題を修正できるようになる必要があります。10.0がリリースされるまでに、ポリシーファイルが機能するようにするために、メタポリシーを設定する必要があります。サービス利用者の問題を解決するためには、サーバ管理者にサービス全体を変更してもらう必要があります。サービスプロバイダに連絡し、この記事を案内して変更の検討を依頼することもできます。自分で問題を修正できます。URLメタポリシーを設定するためのワークフローを実行します。HTTP応答ヘッダに影響を及ぼすことはできないため、オプションは限定される可能性があります。適切なオプションは次のとおりです。サイトで1つのポリシーファイルを使用する場合は、次のオプションを使用します。permitted-cross-domain-policies="master-only"/>サイトでのポリシーファイルの作成を制限しない場合は、次のオプションを使用します。permitted-cross-domain-policies="all"/>ソケットポリシーファイルの設定ソケットポリシーファイルについての節で説明したように、ホスト上のポート843からソケットマスターポリシーファイルを提供するのには2つの理由があります。9.0.124.0またはそれ以降)をインストールするユーザについては、このようなSWFファイルからソケット接続を行うことができません。(特定のSWFコンテンツがソケットポリシーファイルなしでホストへの接続を確立するかどうかわからない場合は、ポリシーファイルログを使用してコンテンツをテストし、非推奨のソケット設定に関する警告を探します)。Player互換のコンテンツをまったく提供する予定がない場合でも、悪意ある攻撃者がDNSリバインディング攻撃によってホストに不正なソケットレベルの接続を行おうとする可能性があります。Playerのフェーズ1バージョンのユーザが、そのような攻撃の媒介者になることがなくなります。ソケットマスターポリシーファイルの提供は、これらの問題に対処する唯一の方法ではありませんが、最も簡単かつ一貫性のある方法です。何らかの理由でポート843からマスターソケットポリシーを提供できない場合は、ポート単位でこれらの問題に対処し、個別のポートからマスター以外のポリシーファイルを提供します。ソケットマスターポリシーファイルはホスト全体に同時に対応する必要があります。ソケットマスターポリシーファイルを提供するには、次の手順を実行します。使用可能なソケットメタポリシーのリストを確認し、ホストに適したソケットメタポリシーを決定します。ソケットマスターポリシーファイルを作成し、目的のソケットメタポリシーと付与するアクセス許可を宣言します。to-ports="999,8080-8082"/></cross-domain-policy>ソケットポリシーファイルサーバの情報ページにアクセスし、ソケットポリシーファイルサーバの設定方法を決定します。ホストでソケットポリシーファイルサーバを実行し、作成したソケットマスターポリシーファイルを提供します。PlayerがHTTP応答ヘッダにアクセスするときにのみ適用されます。PlayerにHTTP応答ヘッダを提供しないため、これは常に可能であるとは限りません。HTTP応答ヘッダへのアクセスを必要とする2つの機能は、次のとおりです。PlayerがHTTP応答ヘッダにアクセスすると、テキスト以外のContent-Type値を含むHTTPポリシーファイル、およびContent-Type値がまったくないHTTPポリシーファイルは拒否されます。PlayerにHTTP応答ヘッダへのアクセス権がない場合は、Content-Typeに関係なくHTTPポリシーファイルが使用されます。PlayerにHTTP応答ヘッダへのアクセス権がある場合は、マスターHTTPポリシーファイルおよびX-Permitted-Cross-Domain-Policies応答ヘッダで宣言されたHTTPメタポリシーが使用されます。PlayerにHTTP応答ヘッダへのアクセス権がない場合、すべてのHTTPサーバにメタポリシーallがあると想定されます。表1に、アドビがHTTP応答ヘッダについてテストを実施したブラウザを示します。付録B:ログメッセージの解説この節では、ポリシーファイルログ(crossdomain.xml)に記録されるメッセージについて説明します。ログ記録に関する節で詳述したとおり、これらのメッセージの一部には、識別子[strict]が接頭辞として付加されています。この識別子は、フェーズ2の近い将来発生する可能性のある問題の警告ではなく、フェーズ1での即時解決を要する問題であることを示します。詳細については、即時解決を要する問題の節を参照してください。(URL)最上位のSWFファイルが、示されたURLからロードされました。通常、これはログの最初のメッセージです。追加モードのログ記録を有効にした場合は、複数回表示されることがあります。Playerセッションを開始したSWFファイルを確認することができます。要求者に許可するために、ポリシーファイル内の<allow-access-from>を検索していますSWFファイルが、ポリシーファイルからのデータ読み込み許可が必要な操作を実行しようとしたため、ポリシーファイルの検出処理が開始されます。このメッセージのURLは、SWFファイルのロード元と、SWFファイルがどのリソースを要求したかを示します。要求者に許可するために、ポリシーファイル内の<allow-http-request-headers-from>を検索していますSWFファイルが、ポリシーファイルからのヘッダ送信許可が必要とされる、カスタムリクエストヘッダを伴うHTTP操作を実行しようとしたため、当該ポリシーファイルの検出処理が開始されます。このメッセージのURLは、SWFファイルのロード元と、SWFファイルがどの送信先にカスタムHTTPリクエストヘッダを送信しようとしているかを示します。9のセキュリティアップデートについて」を参照してください。要求者からの要求は、ポリシーファイルのアクセス権がないため拒否されました。SWFファイルが、ポリシーファイルによる許可が必要な操作を実行しようとしましたが、この操作を許可した有効なポリシーファイルが見つかりませんでした。このメッセージのURLは、SWFファイルがどのリソースを要求したか、およびSWFファイルのロード元を示します。このメッセージは様々な理由で発生します。発生した特定の問題を示すのではなく、実行できなかった必要な手順を示します。場合によっては、このメッセージが表示される前に、より具体的な別のメッセージが表示され、この最終的なエラーメッセージの前に多くの情報が提供されることがあります。考えられる原因は次のとおりです。操作を許可するために適用できるポリシーファイルが存在しません。リソースが存在するサーバを管理している場合は、そのサーバにポリシーファイルを追加する必要があります。それ以外の場合、SWFファイルのホストサーバを通じて操作を委任する必要があります。適用できるポリシーファイルは存在しますが、ポリシーファイルとリソースの両方が存在するサーバにその時点で到達不能でした。サーバホストにpingして、到達可能かどうかを確認します。(URL)」という内容のメッセージが示されます。reached」)が表示されますが、その他の要求の場合は、このメッセージが表示されることに注意してください。適用できるポリシーファイルは存在しますが、SWFファイルの特定のドメインによるアクセスに対する許可が付与されていません。既存のポリシーファイルにリストされたSWFファイルのドメインを取得するか、既存のポリシーファイルによって許可されたドメインにSWFを移動するか、新しいポリシーファイルを追加するか、またはSWFファイルのホストサーバを通じた要求の委任を試行してください。Playerに通知しませんでした。SWFファイルからallowDomainを呼び出してみてください。適用できるポリシーファイルは存在しますが、何らかの理由で無効になっています。この場合、このメッセージの前に、ポリシーファイルのURLと検出された問題を示す、より具体的なメッセージが表示されます。詳細については、ポリシーファイルのロードエラーの節を参照してください。より許可されていません。SWFファイルがそれ自体のドメイン外でソケット接続の確立を試行しましたが、接続を許可する唯一のポリシーファイルは同じホストのHTTPマスターポリシーファイルでした。ソケット接続を許可するHTTPポリシーファイルの構成は、フェーズ1で非推奨となっています。この特定のHTTPポリシーファイルはメタポリシーを宣言しています。サーバは、HTTPポリシーファイルによってソケット接続が許可されることのない、フェーズ2のルールを選択します。詳細については、厳密なソケットルールの節を参照してください。接続先のホストを管理している場合は、ポート843にソケットマスターポリシーファイルを追加するか、メイン接続のサーバがソケットポリシーファイルも提供するようにしてみてください。これらの処理のいずれも実行できない場合、SWFのホストサーバを通じてソケット接続を委任してください。ホストは許可されません。Playerを実行しているコンピュータに属するIPアドレスへのソケット接続を確立しようとしましたが、この操作を許可するソケットポリシーファイルが見つかりませんでした。厳密なポリシーファイルルールでは、ソケット接続を確立するには、ソケットポリシーファイルの許可が必要です。フェーズ1では、ほとんどのソケット接続の場合、この変更によって単に警告が表示されるだけですが、ローカルIPアドレスへの接続の場合は、フェーズ1でも厳密なルールが有効です。詳細については、「厳密なソケットルールの使用」の節を参照してください。この問題に対処するには、ローカルマシンにソケットポリシーファイルサーバを追加するか、ActionScriptでソケット接続を確立するときに、別の名前を指定するのではなく、ローカルマシンのアドレスを"localhost"として明示的に指定するようにSWFファイルを変更します。"localhost"の使用はフェーズ1でのみ機能し、フェーズ2では機能しません。したがって、可能な場合は、ローカルソケットポリシーファイルサーバを手配することをお勧めします。メタポリシーが指定されていません。適用しますが、この設定は推奨されていません。