Flash Player 記事

セキュリティに関するFlash Player 9の変更点

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

セキュリティに関する変更点のほとんどについて、Flash Player 9.0.115.0では開発者に警告が表示されるだけです。ただし、変更点のうちいくつかはFlash Playerの機能の変更に直結するため、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スキーマのドキュメントに詳しくない場合は、スキップしても支障はありません）。 スキーマの場所は次のとおりです。

• http://www.adobe.com/xml/schemas/PolicyFile.xsd
• http://www.adobe.com/xml/schemas/PolicyFileFtp.xsd
• http://www.adobe.com/xml/schemas/PolicyFileHttp.xsd
• http://www.adobe.com/xml/schemas/PolicyFileHttps.xsd
• http://www.adobe.com/xml/schemas/PolicyFileSocket.xsd

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がまったくない場合でも、ポリシーファイルが受け入れられます。

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

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コンテンツが即時に適用される厳密なソケットの影響を受けるかどうかを判断し、検出された問題を修正するための手順を実行します。

ページ 2 / 7

前のページ

次のページ