CloudStockElementsすべての製品サポートに問い合わせよくあるお問合せFAQや、各種サポートへの連絡方法を参照できます。アプリを学ぶ基本的な使用方法や、仕事での新しい活用方法を学びます。コミュニティで質問フォーラムに質問を投稿すると、エキスパートが回答します。アドビは世界を変えるデジタルエクスペリエンスを提供しています。アドビのクリエイティブ、マーケティング、ドキュメントソリューションは、新進アーティストからグローバルブランドまでのあらゆるデジタルコンテンツを適切なタイミングで適切な人に提供することで最高の結果の実現を支援します。商品が発送されるまで、クレジットカードには課金されません。提供開始の予定日は変更される場合があります。ダウンロードの準備が整うまで、クレジットカードには課金されません。提供開始の予定日は変更される場合があります。セキュリティアップデータの仕様変更について記述されております。9のセキュリティアップデートについて」も併せてご確認ください。10.0(10.0.2.xx)について解説します。この記事は2008年7月に更新されています。更新前のバージョンの記事を閲覧したユーザにとって重要な変更点は、次の3点です。9.0.124.0には、ソケット接続に対する完全に厳密な制限動作(フェーズ1.5)が実装されています。10.0からは、この新しい制限のフェーズ2が実装されています。最後に、フェーズ2のデフォルトURLメタポリシーは、最も厳格な制約である「none」から、より緩やかな「master-only」に変更されています。これにより、URLマスターポリシーファイル(/crossdomain.xmlに配置されたポリシーファイル)は、新たなmeta-policyを追加することなく従来通りに機能します。7ソフトウェアでは、ポリシーファイルによるドメイン間の直接データロード許可というクライアントとサーバ間の通信チャネルがWebの新機能として導入されました。ポリシーファイルが導入される前、Webコンテンツで実行できたのは、ランタイム設定やページをリロードしないトランザクションなど、ホストサーバとの双方向通信のみでした。ポリシーファイルにより、サーバは他のドメイン(つまり、通常は任意の場所)のクライアントコンテンツにデータを選択的に開放できるようになりました。ポリシーファイルの導入により、リッチなインターネットアプリケーションの作成者にとってドメイン境界は大きな障害ではなくなりました。ほとんどの新しいテクノロジと同様に、ポリシーファイルは最初の導入時には完全なものではありませんでした。導入から4年が経過し、ポリシーファイルには、インターネットセキュリティ上の問題点が2点あることが判明しました。これらの問題についてはこの記事で追って説明します。6以降と同じように引き続きポリシーファイルを使用できます。新たに見つかった問題点に対応するために、アドビではポリシーファイルの使用についていくつかの厳密なルールを定めています。ポリシーファイルを便利で使いやすいものにするために、様々な改善も行われています。これらの変更が行われた理由をわかりやすく簡単に説明します。この記事では、読者がポリシーファイルに関してある程度知識をお持ちであることを前提としています。Playerのクロスドメインポリシーファイル推奨使用法」*、および別途記事「クロスドメインポリシーファイルの仕様」を参照してください。9のセキュリティアップデートについて」を参照してください。厳密なルールに準拠するために、ポリシーファイルを提供するWebサイトにはいくつかの小さな変更が必要になります。これらの変更は、主にサイト自体を保護するためのものであり、基本的には、ポリシーファイルに関する新しいセキュリティ上のベストプラクティスになります。Playerの厳密な要件を3段階のフェーズで導入しています。Playerのデバッグバージョンで警告が表示されるだけです。9.0.124.0から開始)では、ソケット接続の場合に限りフェーズ1の警告がエラーになるようになりました。10.0から開始)では、フェーズ1のすべての警告がエラーとなり、厳密なルールが完全に適用されるようになります。Webサイトの管理者は次の手順に従うことをお勧めします。即時かつ厳密な対処に関する節を読んだ後、即時解決を要する問題を診断および修正するためのワークフロー手順を実行します。Player互換コンテンツ(SWFファイル)を提供するサイトにのみ適用されます。この手順を追うことで、フェーズ1の影響に対処できます。ソケットポリシーファイルに関する節を読んだ後、ソケットポリシーファイルを設定するためのワークフロー手順を実行します。この手順は主に、既にソケットポリシーファイルを提供しているサイトが適用の対象となりますが、ポリシーファイルまたはSWFファイルがないサイトの防御策としても役立ちます。この手順を追うことで、フェーズ1.5の影響に対処できます。時間がある場合:メタポリシーに関する節を読んだ後、メタポリシーを選択および設定するためのワークフロー手順を実行します。この手順は主に、既にポリシーファイルを提供しているサイトが適用の対象となりますが、ポリシーファイルまたはSWFファイルがないサイトの防御策としても役立ちます。この手順を追うことで、フェーズ2の影響に対処できます。厳密なポリシーファイルルールは、次の2つの問題に対応しています。ポリシーファイル管理。ポリシーファイルではないと思われるサーバ上のファイルが、ポリシーファイルとして使用されている可能性があります。サーバでユーザによるアップロードが許可されているが、クロスドメインアクセス用にデータが開かれることが意図されていない場合、ユーザが意図的にポリシーファイルを作成し、ポリシーファイルを別の種類のファイル(普通のテキスト、XML、HTMLなどのファイル)、またはバイナリファイル(PNGやJPEGなどのイメージファイル)と偽装する可能性があります。この偽装されたポリシーファイルをアップロードしたユーザが、偽装されたポリシーファイルを利用してサーバのドメインの外部からデータをロードするSWFファイルを作成する可能性があります。同様に、権限が制限されているサイトの保守担当者が、管理者の意に反してサイトにポリシーファイルを追加したり、意図しないポリシーファイルを誤って作成したりする可能性もあります。これは基本的に、サーバ上に配置することが許可されるポリシーファイルの管理方法に関する問題です。サーバ管理者は、ポリシーファイルでサーバ全体のポリシー(メタポリシーと呼びます)を設定し、サーバ上のすべてのポリシーファイルを簡単に検索して、サーバに存在するすべてのクロスドメイン許可を監査できる必要があります。Playerの厳密なポリシーファイルルールにより、サーバ管理者によるメタポリシーの宣言が可能になり、ポリシーファイルが正常かどうかをチェックして、適切な形式かどうかを確認できます。Player以外に、ブラウザ、仮想マシン、およびその他のユーザエージェントプログラムを対象とする可能性があります。policy)を悪用します。この攻撃では、特定のインターネットドメインのコンテンツが、明示的な許可なしでそのドメイン内の他のリソースをロードしたり、それらのリソースと通信したりすることが許可されます。独自のドメインを管理し、独自のDNSサーバを実行している攻撃者は、そのDNSサーバを動的に再設定して、特定のドメイン名が自分の管理下にあるIPアドレス(悪意のあるSWFファイルやその他のコンテンツの提供に使用される可能性があります)にいったん解決された後で、自分の管理下にない別のIPアドレスに解決されるようにする可能性があります。ユーザエージェントプログラムでIPアドレスの変更が検出されない場合、同一生成元ポリシーにより、2番目のホストからの許可がなくても、攻撃者のコンテンツが2番目のIPアドレスにアクセスすることが許可されます。Playerはブラウザに依存してHTTPネットワークを提供しているため、HTTPのみに関連するリバインディングの脆弱性はブラウザで解決する必要があります。9.0.115.0の厳密なポリシーファイルルールにより、ソケットに関連する場合はDNSリバインディングの脆弱性を緩和できます。厳密なルールにおいては、接続しているSWFファイルの送信元ドメインがソケットサーバと同じと思われる場合でも、ソケット接続を確立するために、常にソケットポリシーファイルからの許可が必要です。Playerバージョン9.0.115.0以降では、ドメイン名だけでなくIPアドレスに基づいて、ソケット接続を対応するソケットポリシーファイルと照合しています。上記の問題に対応すると同時に、ポリシーファイルをより便利に簡単に使うための新機能も追加されました。Playerのデバッグバージョンからのポリシーファイルイベントの詳細ログ。ポリシーファイルのロードと処理、およびそのポリシーファイルに依存する操作が失敗したか正常に終了したかは、すべて報告されます。これは、厳密なルールへの移行だけでなく、ポリシーファイル展開に関連する問題の検出や解決にも役立ちます。固定されたソケットマスターポリシーファイルポート(TCPポート843)。ソケットポリシーファイルの検出時にデフォルトで参照されます。これにより、以前に使用されていた「任意のポートを選択する」システムではなく、標準的な方法でソケットポリシーファイルを提供できます。ローカルソケットの強力なクライアント認証を必要とするオプション。SWFのみ接続するように指定できます。これにより、オンラインのFlashコンテンツをネイティブのローカルアプリケーションと結び付ける、安全なハイブリッドアプリケーションが実現します。9.0.115.0のポリシーファイルに関する変更点は、開発者のみに警告を発するものが大半であったため、SWFアプリケーションが即座に、意図どおりに動作しなくなる可能性は最低限に抑えられていました。このような即時の変更は、正規のコンテンツでは発生する可能性が低いと考えられる動作パターンのみに適用されるよう配慮されていました。正規のコンテンツに一切の影響が及ばないというわけではありませんでした。即時かつ厳密な対処から発生する問題の検出と修正の段階的な説明については、即時解決を要する問題に対するワークフローを参照してください。影響を受ける開発者(SWFコンテンツの担当者)は、この概要の節を最初に読むことをお勧めします。Playerの制限はバージョン9.0.115.0の新機能ではありません。これらの制限は、9.0.47.0以降で実施されています。バージョン9.0.115.0以降では、新しいログメカニズムにより、これらの制限から生じる問題が見つけやすくなります。Playerでは、コンテンツが適切な形式ではないポリシーファイルは拒否されます。無効な形式が作成される原因は、次のとおりです。開始タグ<cross-domain-policy>の前、または終了タグ</cross-domain-policy>の後にある、無関係な先頭または末尾のコンテンツ(XMLコメントおよび宣言以外のもの)。このような無関係なコンテンツにより、実際にはファイルは無効なXMLドキュメントになります。<cross-domain-policy>以外のトップレベルXMLタグ。任意のタグ内のテキスト(コメント以外)。Playerで不正な形式のポリシーファイルが拒否されるようになったことは、ポリシーファイル管理に関する改善点の一例です。Playerが取り扱っている可能性を示す場合があります。(これはオプションの手順であり、XMLスキーマのドキュメントに詳しくない場合は、スキップしても支障はありません)。スキーマの場所は次のとおりです。http://www.adobe.com/xml/schemas/PolicyFile.xsdhttp://www.adobe.com/xml/schemas/PolicyFileFtp.xsdhttp://www.adobe.com/xml/schemas/PolicyFileHttp.xsdhttp://www.adobe.com/xml/schemas/PolicyFileHttps.xsdhttp://www.adobe.com/xml/schemas/PolicyFileSocket.xsdPolicyFile.xsdはすべてのポリシーファイルに使用できる汎用的なスキーマです。その他の4つのスキーマは、様々なプロトコル用のポリシーファイルのシンタックスを制限します。即時かつ厳密な対処に関するすべての問題と同様に、即時解決を要する問題に対するワークフローに従って、SWFコンテンツが不正な形式のポリシーファイルの影響を受けるかどうかを判断します。不正な形式のポリシーファイルのレポートがログで見つかった場合は、開発者(または影響を受けるポリシーファイルの管理担当者)はポリシーファイルを編集し、無関係なコンテンツの削除、スペルミスの削除などを実行します。Playerは常にポリシーファイルを無視してきました。ドメイン内のリダイレクトは許可されていましたし、ポリシーファイルの要求が同じサーバ上の別の場所にリダイレクトされた場合でも、ポリシーファイルの有効な場所は最初に要求されたURLであると見なされていました。ポリシーファイルの有効な場所が重要なのは、この場所がポリシーファイルのスコープ、つまりポリシーファイルがアクセスを許可するリソースのセットを示しているためです。http://example.com/elsewhere/など、同じサーバ上の別の場所にあるリソースへのアクセスは許可しません。サイト上の有効なアクセス許可を予測するのが困難になるため、通常はポリシーファイルのリダイレクトを使用しないことをお勧めします。Playerバージョン9.0.115.0以降では、同じドメインのリダイレクトを含むポリシーファイルを引き続き受け入れますが、リダイレクトされたポリシーファイルの有効な場所として、最初のURLではなく最終的なURLを使用します。http://example.com/forks/の下の場所へのアクセスは許可しません。Playerで最終的なリダイレクト先のURLが使用されるようになったことは、ポリシーファイル管理に関する改善点の一例です。管理者は、サーバ上のポリシーファイルアクセス許可のセットを簡単に確認できる必要があります。リダイレクトの最初のURLを有効な場所として使用した場合、リダイレクトを作成することで、サイト上のどの場所でもポリシーファイルの存在をシミュレートできます。最終的なURLのみを有効な場所として使用することで、意図したポリシーファイルのみが使用されるようになります。リダイレクトによりサイト上のアクセス許可が変更されることはなく、既に設定されているポリシーファイルがロードされるだけです。ポリシーファイルがリダイレクトされることはまれですが、即時かつ厳密な対処に関するすべての問題と同様に、即時解決を要する問題に対するワークフローに従って、SWFコンテンツがポリシーファイルのリダイレクトの影響を受けるかどうかを判断してください。ポリシーファイルのリダイレクトのレポートがログで見つかった場合、それ自体は必ずしもコンテンツが目的どおりに機能しないことを示すわけではありません。このログは、後で、許可されるはずの操作が許可されなかった場合、問題解決の手がかりとなる可能性があります。/crossdomain.xmlにあるマスターHTTPポリシーファイルの場所の要求をリダイレクトするときです。これにより、リダイレクト先のポリシーファイルのステータスがマスターファイルではなくなります。その後、そのサイトはマスターポリシーファイルを一切使用できなくなるため、メタポリシーの宣言のような一般的な操作が実行できなくなります。Playerバージョン9.0.115.0以降では、ファイルの種類がテキストファイルであることを示すContent-Type値を使用して送信されていないHTTPポリシーファイルは無視されます。Playerでは、ポリシーファイルのContent-Typeは次のいずれかである必要があります。text/*(任意のtextタイプ)application/xmlまたはapplication/xhtml+xmlContent-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を指定するという2つの問題を同時に解決できます。PlayerでテキストのContent-Type値が必要になったことは、ポリシーファイル管理に関する改善点の一例です。Playerが取り扱っている可能性を示す場合があります。PlayerがブラウザのネットワークスタックからHTTP応答ヘッダを読み取ることができるかどうかによって決まります。最新のブラウザはこれに対応していますが、一部の古いブラウザは対応していません。HTTP応答ヘッダをサポートしているブラウザ、およびサポートしていないブラウザのリストについては、付録Aを参照してください。PlayerでHTTP応答ヘッダを読み取ることができない場合は、ポリシーファイルログに警告メッセージが生成され、Content-Typeに関係なく、また、Content-Typeがまったくない場合でも、ポリシーファイルが受け入れられます。即時に適用される厳密なソケット注:この節のコンテンツは、過去の情報を公開する目的でのみ提供されています。9.0.124.0のリリース以降、ソケット接続はすべて、この厳密な規則に基づいて処理されるようになっています。Playerバージョン9.0.115.0と9.0.124.0の違いのみを解説していますが、9.0.124.0以降のバージョンに対応するソケットサーバ管理者にとっては、さほど重要な情報ではない可能性があります。Playerバージョン9.0.115.0以降では、ソケットポリシーファイルに対して一連の厳密なルールが定義されます。ソケットポリシーファイルは、ソケットサーバへのActionScript言語による接続を許可します。厳密なルールの詳細については、ソケットポリシーファイルの節で説明していますが、簡単に言うと、ActionScriptソケット接続を確立するためにソケットポリシーファイルからの許可が常に必要であるというルールです。以前のルールでは、SWFファイルは、ポリシーファイルがない独自のドメイン内にある番号の大きいポートへのソケット接続を確立できました。HTTPポリシーファイルのみに基づいて番号の大きいソケットポートに接続できました。厳密なソケットルールでは、このような状況は許可されなくなります。フェーズで導入されました。フェーズ1では、ルールに違反した場合、ホストが新たなルールの即時的な適用を選択していない限り、警告メッセージのみが生成されていました。いくつかの特殊なソケットでは、フェーズ1でも厳密なルールが直ちに適用されました。具体的には、以下のケースがこの特殊なソケットに該当します。Playerが実行されているローカルマシン上のソケット。ActionScriptでlocalhostと識別されるソケットは例外です。ローカルソケットとは、ループバックアドレス(IPv4の場合は127.0.0.1、IPv6の場合は::1)、およびローカルに割り当てられた外部アドレス(イーサネットアダプタに割り当てられたアドレスなど)のソケットです。PlayerのDNS強化に関する改善点の一例です。厳密なソケットルールを選択する方式は、サーバホストには適していますが、ほとんどのユーザがサーバとして扱っていないローカルマシンには適していません。このルールにより、不正なDNSサーバが(SWFファイルを提供するために)ホスト名をいったんリモートアドレスに解決してから、(ローカルサービスに接続するために)ローカルアドレスに解決することを防止できます。特別な名前であるlocalhostは、このルールからは除外されます。これは、一般的にリモートDNSがlocalhostの解決に関与する可能性がないためです。リンクローカルIPアドレスのソケット。ActionScriptで*.localと識別される(名前が.localで終わる)ソケットは例外です。リンクローカルIPアドレスとは、1つのリンク(ポイントツーポイント接続やネットワークハブなどの1つのネットワークセグメント)でのみ割り当てられるアドレスです。多くの場合、リンクローカルアドレスは「ゼロ設定」のピアツーピアネットワークに使用されます。リンクローカルアドレスの形式は、IPv4の場合169.254.*、IPv6の場合fe80:*です。これは、上記のローカルアドレスの場合と非常に似ています。.localは、通常はリモートDNSが.localアドレスの解決に関与する可能性がないために除外されています。1024以上のポート上のソケットで、独自のソケットポリシーファイルを提供し、ポリシーファイルコンテンツに独自のドメインをリストしていないソケット。これは、実際には個別のルールではなく、厳密なソケットルールを選択した結果です。独自のソケットポリシーファイルを提供するソケットでは、自動的に新しいルールが選択されます。SWFファイルが古いルールに従って、独自のドメイン内にあるこのようなソケットへの接続を確立する場合、ポリシーファイルは必要ではありませんが、厳密なルールに従う場合は、ソケットポリシーファイルが必要になります。ソケットが提供するソケットポリシーファイルに独自のドメインがリストされていない場合、同じドメインのSWFファイルは接続できない可能性があります。即時かつ厳密な対処に関するすべての問題と同様に、即時解決を要する問題に対するワークフローに従って、SWFコンテンツが即時に適用される厳密なソケットの影響を受けるかどうかを判断し、検出された問題を修正するための手順を実行します。9.0.115.0におけるポリシーファイル管理機能の向上をサポートする主な変更点は、メタポリシーが追加されたことです。メタポリシーは「ポリシーに対するポリシー」、つまり、サーバ管理者がサーバ上に存在することを許可したポリシーファイルを指定したものです。サーバのメタポリシーの選択に関する手順の説明については、メタポリシーのワークフローを参照してください。サーバの管理者は、先にこの概要の節に目を通すことをお勧めします。Player互換コンテンツを提供する予定がない場合でも、この節を読むことをお勧めします。そのようなサーバでもポリシーファイルベースの攻撃を受ける可能性はあります。メタポリシーを使用する理由ポリシーファイル管理の改善点の説明で述べたように、メタポリシーの目標は、適切な権限によって作成されたポリシーファイルのみを使用することです。メタポリシーの選択にあたっては、ポリシーファイルの機能、および許可されていないポリシーファイルが及ぼす影響を理解することが重要です(図1を参照)。図1.ポリシーファイルを使用したデータフローこの図では、サイトb.comはa.comのアクセスを許可するポリシーファイルをホストしています。a.comのSWFファイルは、b.comサイトの一部またはすべてから直接データをロードできます(ロードできるデータの範囲は、ポリシーファイルの場所によって異なります)。b.comの管理者は、ポリシーファイルを慎重に扱う必要があります。これは、ポリシーファイルにより、他のドメインのSWFファイルに対してb.comへのアクセス時にユーザの資格情報を使用して動作する許可が付与されるためです。上記の図では、ユーザはa.comのSWFファイルを参照しています(1)。a.comのSWFファイルは他のサイトc.com(図には表示されていません)に埋め込まれている可能性もあります。a.comのSWFファイルは、b.comのポリシーファイルを使用して、b.comからデータをロードするアクセス許可を取得します(2)。これで、b.comへのアクセスをユーザに許可する資格情報を利用して、SWFファイルはb.comからデータをロードできます(3)。必要であれば、SWFファイルはb.comで見つかったデータを、SWFファイルをホストしているa.comのサーバにアップロードできます(4)。ここでは、a.comサーバがb.comに直接アクセスする場合のアクセス資格情報と、ユーザがb.comに対して保持しているアクセス資格情報を比較することが重要です。Cookieを受信したためにユーザがb.comにアクセスできる場合、ユーザの権限はa.comサーバよりも強くなります。この状況では、b.com上にポリシーファイルを作成するのは危険を伴う可能性があります。これは、a.comのSWFファイルは、b.com、ユーザまたはその両方のプライベートなデータを公開しないことについて信頼されている必要があるためです。ポリシーファイルにこのようなデータの脆弱性が発生する可能性がある場合、サーバ管理者が、ポリシーファイルの作成を制限できること(これにより脆弱性が回避されます)、およびサーバ上のすべてのポリシーファイルをいつでも簡単に検索できること(これにより現在のアクセス許可のセットを監査できます)が重要です。管理者権限がない担当者によるコンテンツの提供を許可するサーバもあれば、エンドユーザが定義したコンテンツを提供するサーバもあります。通常は、このようなコンテンツ提供者がポリシーファイルを作成できる状態は適切ではありません。このような場合にメタポリシーが役に立ちます。適切なメタポリシーを選択することで、管理者はポリシーファイルの作成を完全に禁止するか、すべての場所でポリシーファイルの作成を許可するか、その中間の方法として、基準に適合した特定のポリシーファイルのみを許可するかを選択できます。Player互換コンテンツを提供しないと想定されるサーバにも役に立ちます。b.comがファイアウォールの内側のHTML専用サーバで、あるユーザが何かしらの方法でb.com上にポリシーファイルを作成したとします。この場合、b.comへのアクセス権を持つユーザが、インターネット上の任意のサイトa.comのSWFファイルを表示すると、a.comのSWFファイルは、b.comからデータを取得しようとします。b.comがインターネット上のサーバで、ログイン資格情報を受け入れる場合も同じ論理が適用されます。(このようなサーバに適切なメタポリシーはnoneで、そのサーバでのポリシーファイルの存在を禁止します)。メタポリシーのスコープメタポリシーを宣言できるサーバは次のとおりです。HTTPサーバとHTTPSサーバ。各サーバは独自のメタポリシーを宣言します。この宣言は、他のサーバには影響しません。ポート80のHTTPサーバのメタポリシーはそのサーバにのみ影響し、同じホスト上のポート8080のHTTPサーバには影響しません。同様に、HTTPサーバのメタポリシーは同じホスト上のHTTPSサーバには影響しません。