以下の Flash Player サンプルマイクロベンチマークテストとその結果は、Macromedia がプレーヤーの開発にあたり、どのようなパフォーマンス検証を行っているかを示すものです。
時間の測定単位はミリセカンド
テストマシンの仕様は以下の通りです。
画面解像度 32 ビット (同時実行アプリケーションなし、マウス操作なし、プロセスに対する特殊な優先権設定なし)
次のステップ
もちろん、この記事で紹介した事柄だけが最新プレーヤーのパフォーマンス改善点ではありません。他にも、メモリ消費量を減らすための内部データ構造に対する変更や、表示精度を上げるための浮動小数点行列の使用といった、目立たないところでの仕様変更や最適化も施されています。改善点によっては、特定の機能を高速化するものや、新たな機能性をサポートするためにパフォーマンスが犠牲になっているものもあります。しかし、Flash Player 8 に対するパフォーマンス強化と最適化の効果を総合すると、コンテンツやアプリケーションがよりスムーズに、しかも、より高速に表示されるようになっています。
著者について
UCLA MBA 課程在籍中の一時、他の業界への転職を考えたものの、漂白剤の販売業務よりソフトウェア業界に従事する方がはるかに楽しいと考え、現在に至る。
お問い合わせ
不正コピー防止について
著作権と商標について*
当Webサイトをご利用のお客様は、利用規約およびプライバシーポリシー(2009年7月14日更新)にご同意いただいたものとみなされます。
記事のアーカイブ*
ユーザグループの検索*
ユーザグループについて*
これは、当該のコンテンツが潜在的に危険な操作を要求したと判断されたためで、Flash Player 8上でも従来のように閲覧できるようにするには対応が必要です。このドキュメントでは、Flash Player 8 の新しいセキュリティ機能の解説と、変更により影響を受けるローカルファイルを実行するための設定について説明を行います。
新しいセキュリティ制限の影響範囲
変更の影響を受けるコンテンツ
変更の影響を受けないコンテンツ
強化されたローカルファイルに対するセキュリティ
ローカルディスクから読み込まれたSWFに対して、Flash Player 8は、標準ではローカルとインターネット両方へアクセスすることを許可しません。これは、ローカルディスクに配置された悪意のあるSWFが、許可なく外部に情報を送信するといった状況が発生することを防ぐためです。通常、Flash Player 8では、ローカルSWFファイルの動作は、ローカルコンテンツのみのアクセスか、インターネットアクセスのみかのどちらかに制限されています。両方のリソースにアクセスが必要な場合には、該当するSWFファイルを、閲覧者の環境で、信頼できるファイルとして登録する必要があります。なお、この制限はどのバージョンでパブリッシュされたSWFファイルに対しても適用されます。
ローカルSWFファイルのカテゴリー
ローカルアクセスのみが可能なカテゴリーです。ローカルのSWFファイルのデフォルトモードです。Flash 8 以前のバージョンのオーサリング環境でパブリッシュされた、既存のSWFはこのカテゴリーになります。インターネットアクセスのみが可能なカテゴリーです。この設定変更は、SWFファイルがローカルディスクからロードされた場合以外には何も影響しません。ローカルアクセスとインターネットアクセス、JavaScript との通信が可能なカテゴリーです。SWF の閲覧者の環境に設定を行うことで、自由にリソースにアクセスできるようになります。設定方法は以下を参照してください。
信頼できるローカルSWFの設定方法
ローカル SWF ファイルを3つ目の Trusted カテゴリーにするのは、以下のどちらかの方法で行うことができます。インストーラを作成する。
コンテンツの製作者は、信頼できる SWF ファイル、もしくは信頼できるファイルを含むディレクトリを登録するための
cfg ファイルを作り、それを適切な場所に配置するインストーラを提供することができます。cfg ファイルは、パス名やファイル名が記述されただけの単純なテキストファイルです。# これはコメント行です。cfg ファイルを配置する場所は、以下に示す場所のどちらかでなければなりません。
cfg ファイルの名前は任意で、また、複数の
cfg ファイルを置くことが出来ます。1つ目の場所への設定には、管理者権限が必要です。2つ目の場所は、ユーザごとに固有の設定になります。閲覧者が自分で設定する。設定マネージャを使うと、閲覧者は信頼できるローカル SWF ファイルか、それを含むディレクトリ自身を信頼できるものとして登録することができます。このとき、ユーザは対象になるファイルもしくはディレクトリへのパスを知っている必要があります。設定マネージャの詳しい使用方法は、以下の URL をご参照ください。
サンドボックスについて
インターネット上の SWF ファイルには、ドメインごとにそれぞれサンドボックスが用意され、他のドメインの SWF とは自由に通信できないようになっています。また、ローカルリソースへのアクセスも制限されています。ローカルの SWF ファイルについては、3つのカテゴリーごとに個別のサンドボックスが割り当てられます。これにより、異なるカテゴリーの SWF ファイル間の呼び出し、およびインターネットからロードされた SWF との通信はサンドボックスによって制限されています。また、_global オブジェクトもカテゴリーごとに個別になります。
共有オブジェクトについて
これは、他のカテゴリーのローカル SWF ファイルとは共有されないため、Untrusted カテゴリーのローカル SWF ファイルと連携して、ローカルのデータを外部に送信する手段としての使用はできないようになっています。この仕様は、一見不思議に思えるかもしれませんが、外部にデータを送信できるのはTrusted カテゴリーの SWF ファイルだけであることと、Trusted カテゴリーのSWFファイルは自由なリソースアクセスを許されたファイルであることから理解できるかと思います。なお、カメラやマイクの使用許可、ディスクの使用量などその他の設定は、全てのカテゴリーで共有されます。Untrusted ローカルファイルは以下の操作を行うことが出来ません。
HTTPのようなネットワークプロトコルを用いた要求
他のカテゴリーのSWFとのクロススクリプティング
例: 変数、関数の呼び出し、ローカルコネクション
HTML内のスクリプトとのインタラクション
Untrusted ローカルファイルが上記のような処理を行おうとすると、処理が停止され、以下のようなダイアログが表示されます。以下は実行できない処理の例です。また、UntrustedカテゴリーのSWFとのクロススクリプティングやローカル HTML 内のスクリプトの呼び出しも行うことができません。一方、ネットワークアクセスについては、データ送信は自由にできるものの、サーバーからのデータの取得、あるいはネットワーク経由でロードされた SW Fとの通信には明示的な許可が必要になります。このために、新しく「*」(ワイルドカード、全てのドメインの意)によるアクセス許可が設定できるようになりました。
サーバーからのデータ取得
ネットワークからロードされた SWF とのクロススクリプティング
ネットワークからロードされた SWF とのローカルコネクション
なお、上記のように「*」によりドメインを指定すると、すべてのドメインからのアクセスを許可することになります。例えファイアーウォール内でも、重要なデータを管理しているサーバーにこの設定を行う際は、十分に安全性を検討してください。
セキュリティ機能変更により影響を受けるコンテンツの対応
Flash Player 8 のセキュリティ機能変更により、ローカルコンテンツがインターネットにアクセスしたり、JavaScript を呼び出そうとする度に警告が表示されるようになることがあります。この動作はセキュリティをより強化するためのものであり、必要な変更ではありますが、一方で閲覧するユーザにとっては煩わしいものでもあります。そのような場合には以下の方法で対応することが考えられます。SWF ファイルがローカルのファイルを必要としない(SWF ファイルの読み込みを除く)場合で、ネットワークアクセスが原因でセキュリティ警告が表示されたら、SWF ファイルをすべて Local with Network カテゴリーにすることで、これを回避できます。インストーラを作成する。cfg ファイルをインストールするプログラムを配布する方法です。cfg ファイルの名前は任意ですが、他のインストーラが作成したファイルの上書きをする可能性があるため、「会社名+コンテンツ名」のように、重なりにくい名前にすることをお勧めします。また、CD-ROM 等で配布されているコンテンツの場合、リムーバブルディスクへのパスを信頼できるフォルダとして登録すると、ディスクを入れ替えたときにもその設定が有効になるため、潜在的なセキュリティホールになることが懸念されます。
そのため、直接リムーバブルディスクへのパスを登録する代わりに、以下のいずれかの方法をとるようにしてください:
1) コンテンツをすべてハードディスク内のフォルダにコピー、そのフォルダを信頼できるフォルダとして登録
2) リムーバブルディスクからコンテンツを読み込むための SWF ファイルを作成し、ハードディスク内の適切な場所に配置
そのSWFファイルへのパスを信頼できるファイルとして登録
ユーザに設定マネージャをガイドする。配布先が限られている場合、あるいはエンドユーザのコントロールが可能な場合は、設定マネージャを使用して、ユーザ自身に登録を促すことも考えられます。この場合には、登録の必要なファイルあるいはフォルダの情報をユーザに知らせることになります。変更点を含む、Flash player 8 のセキュリティ機能全般についての情報は、以下のドキュメントをご参照ください。
著者について
上条 晃宏: マクロメディアで Flash プラットフォーム上のユーザー体験やアーキテクチャデザインのコンサルティングを担当、数多くの Flash / Flex プロジェクトに携わる。
お問い合わせ
不正コピー防止について
著作権と商標について*
当Webサイトをご利用のお客様は、利用規約およびプライバシーポリシー(2009年7月14日更新)にご同意いただいたものとみなされます。
記事のアーカイブ*
ユーザグループの検索*
ユーザグループについて*
新しく追加されたセキュリティ警告画面
どんなときに、この警告が表示されるのか
なぜ、警告が表示されるのか
この警告が表示されたときの対応は
設定マネージャの使い方
設定マネージャを使うことで、常に信頼できるSWFファイルやフォルダを登録することができます。設定マネージャの画面を表示する。警告ダイアログパネル内の設定をクリックすると、ブラウザ内に[グローバルセキュリティ設定パネル]が表示されます。このパネルは、Flash コンテンツ上で右クリックをして、表示されたパネルの「高度な設定」をクリックして表示されるページ内のナビゲーションからも選択することができます。信頼できるファイルを追加する。」をクリックすると、以下の画面が現れます。
ここで、「追加
」を選択します。すると、以下のポップアップウインドウが表示されます。ここでは、ファイルを信頼する手順を紹介します。
(フォルダのケースも手順は同様になります) 上記の状態で、「ファイルを参照
」をクリックするとファイルを選択するダイアログボックスが現れます。信頼できる SWF ファイルを選択して、「開く」を押すと、以下の画面に戻ります。信頼できるファイルとフォルダのリスト内に、今選択したSWFファイルが含まれていることを確認してください。これで、信頼できる SW Fファイルが登録されました。登録済みの信頼できるファイル名やフォルダ名を編集する。設定マネージャでは、登録済の信頼できるファイル名やフォルダ名を変更することができます。
まず、登録マネージャの「編集
」をクリックすると表示されるプルダウンリストから「編集
」を選びます。すると、以下のポップアップウインドウが表示されます。ポップアップ内のファイル名を編集後、確認を押すと、編集内容が反映されます。登録済みの信頼できるファイル名やフォルダ名を削除する。設定マネージャから、登録済の信頼できるファイル名やフォルダ名を削除する手順は以下のとおりです。
まず、登録マネージャの「編集
」をクリックすると表示されるプルダウンリストから「削除
」を選びます。すると、以下のポップアップウインドウが表示されます。ファイル名を確認してから、確認ボタンを押すと、該当するファイルの登録情報が削除されます。削除後は、リストからファイル名がなくなります。これで登録情報を削除完了です。
お問い合わせ
不正コピー防止について
著作権と商標について*
当Webサイトをご利用のお客様は、利用条件およびプライバシーポリシー(2009年7月14日更新)にご同意いただいたものとみなされます。
記事のアーカイブ*
ユーザグループの検索*
ユーザグループについて*
対策を要する変更
新たに提供されるセキュリティ関連の機能
対策を要する変更
ポリシーファイルの厳格度:フェーズ2
ソケット接続のタイムアウト
アップロードとダウンロードに必要なユーザ操作
システムクリップボードに対するデータ書き込み時のユーザ操作の義務化
ファイルアップロードを含むPOSTでのアップロードセキュリティチェックの義務化
ポリシーファイルの厳格度:フェーズ2
既存のWebサイトへの影響を考慮し、Flash Playerの複数のリリースに分けて段階的に変更が導入されました。5が導入され、ソケットに関するルールのみが強化されました。フェーズ2の導入により、ポリシーファイルのメタポリシーのデフォルト動作が変更されます。メタポリシーとは、ドメインでのポリシーファイルの動作を指示するポリシーです。メタポリシーを使用すると、管理者はドメインのすべてのポリシーファイルを管理しやすくなります。このバージョンでは、メタポリシーのデフォルト値として「all」を使用しました。all 値では,ドメインのすべてのポリシーファイルが有効となり、以前のバージョンのFlash Playerと動作が一貫します。
これにより、すべてのマスターポリシーファイル(ドメインのルートに保存されたポリシーファイルで、 http://example
xmlという名前が付くファイル)は引き続き予期したとおりに動作します。しかし、他の場所に定義された他のすべてのポリシーファイルは、明示的なメタポリシーがなければ動作できなくなります。この変更は、クロスドメインコンテンツにアクセスするSWFファイルに影響する可能性があります。この変更は、Adobe AIRのアプリケーション以外のすべてのコンテンツに影響します。ただし、AIRアプリケーションコンテンツ自体は影響を受けません。
ドメインのメタポリシーを定義します(まだ定義していない場合)
マスターポリシーファイルのみを使用している場合でも、メタポリシーを明示的に定義することをお勧めします。メタポリシーは、site-controlディレクティブの中またはサーバから送られたヘッダを通じてマスターポリシーファイル内に設定できます。ユーザの制御外のドメインに属するコンテンツを使用している場合は、そのドメインの管理者に連絡し、最新のメタポリシーがあることを確認します。
ソケット接続のタイムアウト
つまり、以前は即座に送られたsecurityErrorイベントが、新しいバージョンでは送出までにより時間がかかるようになります。また、以前はネットワークの混雑や停電などの遅延があっても接続が成功しましたが、新しいバージョンでは代わりにsecurityErrorイベントが発生するようになります。timeoutのAPIを使用してタイムアウトを指定することができます。この変更は、Adobe AIRのアプリケーション以外のすべてのコンテンツに影響します。ただし、AIRアプリケーションコンテンツ自体は影響を受けません。明示的なタイムアウトを設定することもできます。タイムアウトを長く設定すると、不安定なネットワーク状態では堅牢性が増しますが、エラーの発見が遅れます。タイムアウトを短く設定すると、エラーの発見は早くなりますが、不安定なネットワーク状態での堅牢性が低下します。
アップロードとダウンロードに必要なユーザ操作
これには、マウスのクリックやキーボード入力などの操作が含まれます。この変更は、Adobe AIRのアプリケーション以外のすべてのコンテンツに影響します。ただし、AIRアプリケーションコンテンツ自体は影響を受けません。downloadを使用して参照ダイアログボックスを起動するコンテンツは更新する必要があります。新しいバージョンでは、参照ダイアログボックスをボタンやショートカットキーなどのユーザ操作を伴うイベントによって起動する必要があります。
システムクリップボードに対するデータ書き込み時のユーザ操作の義務化
ここでいうユーザ操作には、マウスボタンのクリックやキーボードを使用した入力などが含まれます。この変更は、アプリケーション以外のすべてのAdobe AIRコンテンツに影響します。ただし、AIRアプリケーションコンテンツ自体には影響が及びません。
ユーザ操作によってトリガされるイベント以外で、System
setClipboard()メソッドを用いてシステムクリップボードにデータを代入している場合、これらの既存コンテンツはすべて更新する必要があります。クリップボードへのデータ書き込みは、今後、ボタン操作やキーボードショートカットなど、ユーザが行う操作によって発せられるイベントを介して呼び出す必要があります。一部のHTTPサーバでは、次のような応答ヘッダが送信されることがあります。この応答ヘッダは、返されるファイルが、アクティブコンテンツとしてインライン表示されるべきではないことを、クライアントソフトウェア(ブラウザ、Flash Player、電子メールクライアントなど)に指示するためのものです。次のようなケースを考えてみてください。Webベースの電子メールサービスがあり、このサービス上でのメッセージ閲覧中に、添付ファイルを示すリンクをクリックしたとします。つまり、ブラウザに対し、当該ファイルを開く代わりにディスク上への保存を指示することができます。このヘッダはセキュリティ対策として使用されることもあります。例えば、信頼されていないユーザによってアップロードされたファイルをサーバから配信するようなケースでは、「Content-Disposition: attachment」ヘッダを利用することで当該ファイルがサーバドメイン上で実行されることを防止できます。なお、この制約はSWFファイルのみに適用されるものであることに注意してください。画像、サウンド、テキスト、XMLファイル、ポリシーファイルといった、他のタイプのコンテンツには適用されません。2以降で再生されるすべてのバージョンのSWFに影響します。この変更は、アプリケーション以外のすべてのAdobe AIRコンテンツに影響します。ただし、AIRアプリケーションコンテンツ自体には影響が及びません。対象のSWFファイルが配置されたHTTPサーバの設定を調整できる場合は、サーバのドメイン上で当該SWFファイルが実行されることを信頼できるかについて検討します。当該SWFファイルが配置されたHTTPサーバの設定を調整できないケースでは、次の2つの選択肢があります。0が用いられた他のSWFファイル経由でダウンロードするようにします。なお、読み込まれる側のSWFが相対指定のURLを参照していたり、読み込み側のSWFからアクセスできないセキュリティサンドボックス権限に依存しているような場面など、このテクニックが利用できないケースがあることに注意してください。
2からは、上記プロパティのいずれかによって参照されるオブジェクトが別のセキュリティサンドボックス内にあり(対象オブジェクトが他のドメインから供給された別途SWFの一部であるケースなど)、かつ、(Security
allowDomainメソッドを用いて)2つのセキュリティサンドボックス間に相互的な信頼関係が定義されていない場合、このプロパティの値はnullに変更されます。これらのプロパティの値には、ユーザがバックグラウンドでオブジェクトにロールオーバする場合など、あらかじめnullが設定されていることがあります。今回の変更は、null値が発生する新たな局面が現れるということに過ぎません。ここで紹介した制約が原因でSWFファイルにnull値が発生したかどうかについては、新たに用意された次の3つのブール型プロパティをチェックすることで確認できます。2以降で再生されるすべてのバージョンのSWFに影響します。この変更は、アプリケーション以外のすべてのAdobe AIRコンテンツに影響します。ただし、AIRアプリケーションコンテンツ自体には影響が及びません。SWFファイルによっては、引き続き正常に動作するものもありますが、イベントハンドラの動作を検証し、適切な反応があるかどうかを確認するようにします。問題がある場合は、イベント情報の重複が他のどのSWFファイル(ファイル群)との関連で発生しているかを特定します。allowDomainを呼び出す際には、あらかじめこの操作が与える影響を十分に理解するようにしてください。
特に、読者のSWFファイルに対し、任意のスクリプティングを許可する特定のドメインが信頼できないような場面では、Security
ファイルアップロードを含むPOSTでのアップロードセキュリティチェックの義務化
browse は、必ずユーザイベントハンドラ(マウスまたはキーボードイベント)から呼び出されなければならない。
uploadを呼び出したSWFファイルとは異なるドメインのサーバである場合、アップロード先のサーバには必ず当該SWFファイルのドメインを信頼することが記されたポリシーファイルが必要
2からは、サーバがアップロードを含むものと判断しかねないPOSTを実行する、ネットワークAPIが呼び出された際にも、Flash Playerは上記2つのルールを適用します。これらのアップロードの形式は、RFC1867*と呼ばれるものです。この変更の影響は、RFC1867形式のアップロードが含まれたPOSTリクエストを送信する、ネットワークAPIが用いられたSWFファイルに及ぶ可能性があります。2以降で再生されるすべてのバージョンのSWFに影響します。この変更は、アプリケーション以外のすべてのAdobe AIRコンテンツに影響します。ただし、AIRアプリケーションコンテンツ自体には影響が及びません。この制約が原因でSWFコンテンツが意図通りに動作しなくなった場合は、当該SWFファイルを編集し、パブリッシュし直す必要があります。POSTの送信先にあたるサーバの設定を調整できる場合は、SWFとサーバ両方の設定を変更し、他のファイル転送形式を使用するようにするか、単に、multipartフォーマット内で他の構文を使用するようにします。RFC1867構文の使用が義務づけられている場合は、POSTの呼び出しがユーザ操作のハンドラから行われていることを確認するとともに、SWFの供給元サーバとは異なるサーバに向けてPOSTを行う場合、当該サーバに元のSWFのドメインを信頼することが記された、ポリシーファイルを設置するようにします。
一部のWMODEでのカメラおよびマイクの使用制限
2からは、次に示すいずれかの条件が当てはまる状況において、カメラおよびマイクの使用と設定UIの表示が許可されなくなります。2以降で再生されるすべてのバージョンのSWFに影響します。この変更は、アプリケーション以外のすべてのAdobe AIRコンテンツに影響します。ただし、AIRアプリケーションコンテンツ自体には影響が及びません。したがって、パブリッシュ済みの既存SWFコンテンツに「direct」「gpu」モードの制約の影響が及ぶとは考えられません。
お問い合わせ
不正コピー防止について
著作権と商標について*
当Webサイトをご利用のお客様は、利用条件およびプライバシーポリシー(2009年7月14日更新)にご同意いただいたものとみなされます。
記事のアーカイブ*
ユーザグループの検索*
ユーザグループについて*
この記事では、Flash Playerに対するUIAの義務化、つまりUIA要件の適用によって何が制限されるのか、なぜこの制限が必要なのか、そして、どのようにすればこの義務化に対応したコンテンツを作成できるかなど、この最新要件の理解を深めるための情報を紹介していきます。ActionScript APIの特定の機能にUIA要件が課されている場合、当該機能は、マウスクリックやキータッチといったUIAに基づいてのみ呼び出すことができます。UIAに関する今回の制限は、ユーザコンピュータへのファイルのダウンロード、ユーザコンピュータからのファイルのアップロード、フルスクリーンモードの起動、ユーザコンピュータのクリップボードへの書き込みといった、潜在的なリスクを伴う処理が、キータッチやマウスクリックなどのユーザによる意図的な行為なしに実行されることを防ぐためのものです。
UIA要件の適用対象
つまり、キーボードのキーを押す、あるいはマウスのボタンをクリックすることが、UIAにあたります。今回UIA要件が適用されるのは、以下に挙げる操作・処理です。ユーザ操作の義務化による今回の制限は、ユーザコンピュータへのファイルのダウンロード、ユーザコンピュータからのファイルのアップロード、フルスクリーンモードの起動、ユーザコンピュータのクリップボードへの書き込みといった、潜在的なリスクを伴う処理が、キータッチやマウスクリックなどのユーザによる意図的な行為なしに実行されることを防ぐためのものです。
ユーザによる意図的な操作の義務化
つまり、キーボードのキーを押す、あるいはマウスのボタンをクリックすることが、この操作にあたります。ユーザによる意図的な操作が義務づけられる対象には、以下の処理・操作が含まれます。browseメソッドは、UIAの結果として生じるActionScript関数内(つまり、キータッチまたはマウスクリック時のイベントハンドラ)から呼び出された場合に限り、正しく処理されます。この制限により、特定のWebページがユーザの明確な同意なしに、ユーザマシンからファイルをアップロードまたはダウンロードするための呼び出しを行う問題が回避できます。この問題が生じるアプリケーションにおいては、ワークフローの一貫として、UIAを受け付けるためのインタラクティブな手順を追加実装する必要があります。POST APIs: HTTPのPOSTを利用してターゲットサーバへのファイルアップロードにあたる処理を行う場合は、UIAに基づくものに限り、処理が正しく実行されます。このPOSTを介したRFC1867アップロードに対する制限により、SWFがユーザの明確な許可を得ることなく、当該SWFのホスティングされているサーバに無断でデータを送信する問題が回避できます。なお、SWFがPOST経由で、当該SWFのホスティングされているサーバ以外のサーバにファイルをアップロードすることを許可したいケースでは、アップロードを受け取る側のサーバにも適切なクロスドメインポリシーを設置し、クロスドメインのPOSTに対応できるようにする必要があります。(詳しくは、クロスドメインポリシーファイルの仕様を参照してください。システムクリップボードの書き込み時にどちらのAPIを利用するとしても、当該書き込み処理はUIAの結果として生じる必要があります。getDataを使用してシステムクリップボードからデータを読み取る際には、この操作がペーストイベントハンドラの結果として生じない限り、処理が行われません。ペーストイベントハンドラは、マウスを使用してコンテキストメニューを有効化するか(右クリックまたはControl +クリック)、ペースト操作用のキーボードショートカット(Control+VまたはCommand+V)を利用してのみ呼び出すことができます。つまり、ペーストのハンドラ内で実行されるAPIは、必ずUIAの結果として生じるものに該当します。クリップボードに関するこの制限により、SWFがユーザの関知しないところでクリップボードコンテンツを設定できる問題が回避できます。
今後、フルスクリーンモードを有効化できるのは、このStage
displayStateがキータッチまたはマウスクリックのユーザイベントハンドラから呼び出された場面に限定されます。この制限により、ユーザがフルスクリーンモードの有効化に気付くことなく、SWFが、ユーザ画面上の他のコンテンツを妨害できるようになる恐れを軽減できます。上記のいずれかのAPIを利用して新規ウィンドウを開く操作は、ユーザイベント(キータッチまたはマウスクリック)のハンドラから呼び出された場面に限り、正しく処理されます。仮にこれらのAPIがユーザイベントハンドラ以外のActionScriptコードから呼び出された場合、ブラウザは、その環境設定にもよるものの、ポップアップウィンドウの表示を拒否することがあります。なお、ポップアップウィンドウの表示が試行されるかどうかは、Flashプラグインをホスティングするブラウザの種類および環境設定に左右されるため、動作はどのブラウザを使用するかによって異なります。新規ウィンドウが可能な限りすべてのブラウザで正しく開かれるようにしたい場合は、新規ウィンドウをUIAの結果としてのみ、開くようにしてください。ポップアップウィンドウを開く際のこの制限は、ブラウザのポップアップウィンドウ表示設定とFlash Playerの連携性を確保することを目的に設定されています。今回のUIA要件への対応策として肝心なのは、前出の各機能性が、ユーザによるキータッチまたはマウスクリック(つまり、UIA)の結果として発生するイベントハンドラ内で処理されるようにすることです。
ユーザ操作の義務化に向けた対応策
Flash Player 10におけるユーザ操作の義務化に向けて、SWFコンテンツ作者が取り得る(場合によっては、取らざるを得ない)手順はいくつかあります。今回のユーザ操作義務化に対応するためには、前出の各機能性が、ユーザによるキータッチまたはマウスクリックの結果として発生するイベントハンドラ内で処理されるようにすることが重要です。このようにすることで、ユーザはクリップボードへのテキスト書き込み操作を明確に指示できるようになります。つまり、これでUIA要件がクリアされたことになり、書き込み処理が適切に行われるようになります。大半のケースでは、処理がUIAの結果として行われるようにするために、SWFにユーザインターフェイスコントロールを追加しなければならなくなります。例えば、これまでユーザからの入力なしに新規ウィンドウを開いていた場合、今後は新規ウィンドウを開くためのボタンを設置するなどの対策が必要になります。一部のケースでは、他にも対応策として、デザインまたはコードの変更が必要になることもあります。次に示すシナリオがその一例です。あるアプリケーションが特定の処理を実行するためのコマンド(画像ファイルの形式変換など)を送信し、その処理後のデータが、ダウンロードで返されるようになっていたとします。
従来、このようなアプリケーションはサーバでの準備が整い次第、ユーザのインタラクションなしにFileReference
しかし、これからはサーバの準備が整った段階で、「ダウンロードの準備ができたので、こちらをクリックしてダウンロード」といった、追加のインタラクティブUIをアプリケーションが提示する必要があります。つまり、アプリケーションのユーザワークフローに、インタラクティブな手順を追加実装しなければならないことがあります。UIA要件が処理の妨げになっているかどうの判定作業を支援するために、SWFデベロッパーには2種類のデバッグ方法が用意されています。どちらの方法を利用するとしても、SWFデベロッパーの環境にはデバッグ版のFlash Playerがインストールされている必要があります。0例外をキャッチして表示することができます。
0を用いてSWFがオーサリングされている場合、クリップボードへの書き込みがUIAの欠落によって拒否された際には、Clipboard
0例外の処理精度を高めることを目的にしたものです。今回のUIA要件に対応するためには、多くのケースにおいて、(この記事で紹介した)UIコントロールの追加またはワークフローの変更といった対策を講じるためのSWFコード編集を行い、コンテンツを再パブリッシュする必要があります。
次のステップ
デベロッパーの皆さんには、自らのSWFコンテンツが最新のUIA要件を満たしていることを確認するよう、お勧めします。この際、新規コンテンツのみを対象とするのではなく、既存コンテンツの更新も行うように注意してください。
著者について
お問い合わせ
不正コピー防止について
著作権と商標について*
当Webサイトをご利用のお客様は、利用条件およびプライバシーポリシー(2009年7月14日更新)にご同意いただいたものとみなされます。
記事のアーカイブ*
ユーザグループの検索*
ユーザグループについて*
これらの変更が行われた理由、およびサイト所有者として、どうすれば強化された権限制御を利用できるかについて詳しくは、Flash Player 10ベータのセキュリティ変更点についてを参照してください。ポリシーファイルは、どのSWFファイルにサーバとの通信を許可するかと、当該サーバとの通信時にSWFファイルが何をできるかを、サーバ所有者が指定するために用いられるFlash Playerの中核的な権限制御機構です。Webの通例的な権限設定は、すべてが完全に一致するドメイン上に存在する場合に、さまざまな操作を許可することです。ポリシーファイルを利用すれば、このような権限設定を拡充することができ、SWFファイルのWebドメイン外に存在するリソースを用いたパワフルなアプリケーションが開発できるようになります。たとえば、Flickrなどのサイトでは、SWFファイルがパブリックAPIを利用できるよう、任意のユーザがサーバに接続し、自らのSWFファイルにデータを読み込めるようにするためのポリシーファイルを設置しています。ポリシーファイルに関しては、デベロッパーに対するFlash Playerの柔軟性を維持しながら常に最善のセキュリティをユーザおよびサーバに提供できるよう、時間の経過とともに、さまざまな調整・変更が必要とされてきました。本記事では、どのような変更が行われたかの情報と、それらの変更がいつFlash Playerに追加されたかを紹介することにします。Flash Playerの新しいバージョンがリリースされると、どのバージョンのFlashを対象に書き出したかを問わず、新たな要件設定の縛りを受けるユーザが現れると考えられます。Flash Player 10ベータにおけるセキュリティ面での変更は、まだ一般普及しているものではありません。アドビでは、すでに発表されているセキュリティ面での変更がコンテンツに影響を及ぼさないよう、前もって計画をたてるようにすることを推奨しています。
ポリシーファイルに対するバージョン別のセキュリティ変更事項
表1は、既存ユーザに影響を及ぼす可能性がある、ポリシーファイル関連のセキュリティ変更点をまとめたものです。各セクションには、以前のプレイヤーより追加された変更点が記載されています。次の表は、本記事の各セクションで紹介するトピックのクイックリファレンスでもあります。各トピックは、その変更点が盛り込まれたFlash Playerバージョンのセクションで解説することにします。
厳格なXML解析処理
メタポリシーの適用
リダイレクトの制限
ローカルソケットの制限
ソケットポリシーの義務化
メタポリシーの義務化
厳格なXML解析処理
影響度: この変更の影響を受けるデベロッパーは、ごく一部に限られます。ポリシーファイルは有効なXMLである必要があります。XMLが有効ではない場合、ポリシーファイル自体が無視されます。
メタポリシーの適用
影響度: 自らの制御下にはないサーバへのアクセスのためにポリシーファイルを利用している場合は、コンテンツが意図通りに機能することを確認するようにしてください。解説: マスターの位置でHTTPまたはソケットポリシーファイルを処理する際、Flash Playerは、同一サーバ上の他のポリシーファイルを使用または無視するかを判断するために、オプションで設置できるメタポリシーを探します。メタポリシーはHTTPのレスポンスで宣言することも可能ですが、この方法は一般的ではありません。
comへのソケット接続の場合は、マスターポリシーファイルは www
com のポート843のソケット接続から供給されます。他のポリシーファイルを無効化するメタポリシーがマスターポリシーファイルに含まれている場合は、マスター以外の位置のポリシーファイルを用いる際に、データ読み込みに影響が及ぶことがあります。アクセスしようとしているサーバにメタポリシーが用意されていない場合、Flash Playerはマスター以外のポリシーファイルを許容します。マスターHTTPポリシーファイルが存在しない、あるいは他のポリシーファイルを許可するメタポリシーがマスターHTTPポリシーファイル上に存在しない場合、Flash Playerは、当該HTTPサーバ上のマスター以外のポリシーファイルを無視します。
リダイレクトの制限
影響度:サーバリダイレクトを使用している場合は、ポリシーファイルが意図通りに機能することを確認するために、SWFコンテンツの動作を検証することをお勧めします。各種許可は、ポリシーファイルの最終的なURL位置のみをベースに付与されます。当初リクエストしたドメイン以外のポリシーファイルへの再転送に関しては、Flash Playerは従来通りポリシーファイルを無視します。影響度: この変更の影響を受けるデベロッパーは、ごく一部に限られます。ご利用中のWebサーバが高度にカスタマイズ・特化されている場合は、サーバのcontent-type設定を確認することをお勧めします。また、ポリシーファイルに標準的な名前以外を使用している場合は、ポリシーファイルの名前が文字形式のcontent-typeに関連づけられていることを確認するようにしてください。content-typeはWebサーバによって設定されるものであり、ファイルの拡張子に基づいて割り当てられることが一般的です。ポリシーファイルのコンテンツタイプを変更したい場合は、ご利用中のWebサーバのドキュメンテーションを参照するようにしてください。実際にこの変更を行う場合、クロスドメインポリシーファイルの推奨値は以下の通りです。影響度:マスターソケットポリシーサーバが用意されていない場合、ソケットサーバへの接続時に数秒の遅延が発生することがあります。解説:ソケットポリシーファイルによってあらかじめソケット接続が許可されていない場合、Flash Playerは、当該ドメインのマスターソケットポリシーファイルを読み込むためにホストサーバのポート843への接続を試みます。ポート843のソケットポリシーファイルでは、当該ホストへのソケット接続に対するメタポリシーも設定できます。影響度:localhostのソケットに接続している場合は、コンテンツが意図通りに機能することを確認する必要があります。この変更によって、通常のWebコンテンツに影響が及ぶことはありません。解説:ローカルソケット接続の場合、SWFファイルのドメインおよび接続先ポートを問わず、必ずソケットポリシーファイルが必要になります。詳しい情報については、サンプルコードおよび各種オプションの解説が含まれた、ソケットポリシーファイルサーバの設定を参照してください。
ソケット通信のためのHTTPポリシーファイル
影響度: クロスドメインでのソケット通信を利用するデベロッパーの多くが、ソケットポリシーファイルの設定を変更する必要があります。解説:HTTPで提供されるポリシーファイルを、当該サーバへのソケット接続の許可に用いることができなくなりました。この変更に伴い、ソケット接続に対してはソケットポリシーファイルによる許可が必須となります。ソケットポリシーファイルとは、当該ポリシーが含まれたXMLをFlash Playerに送信するために用いられるソケット接続です。ソケットポリシーファイルの読み込みは、メインのソケット接続の確立とは異なる、単独のプロセスです。ソケットポリシーファイルを提供するには、別途サーバが必要となります。詳しい情報については、サンプルコードおよび各種オプションの解説が含まれた、ソケットポリシーファイルサーバの設定を参照してください。
ソケットポリシーファイルの義務化
影響度:この変更点は、ソケットポリシーファイルが用意されていない自らのホストに対してソケット接続を作成しようとする、すべてのコンテンツに影響します。解説:どのポート・ドメインを使用するかを問わず、ソケット通信には必ずソケットポリシーファイルが必要とされるようになりました。以前は、SWFファイルがホスティングされているのと同じホストに限り、ポリシーなしでも1024番を超えるポートに接続することができました。このような接続設定は今後許可されません。影響度:ドメインを超えたネットワークリクエストにおいて、カスタムのHTTPヘッダが送られるようなSWFファイルを開発したデベロッパーは、これらのコンテンツが意図通りに機能することを確認する必要があります。解説:別途ドメインに向けられたネットワークリクエストに、カスタムヘッダを追加するようなSWFコンテンツがある場合、送信される各ヘッダを許可するためのポリシーファイルが必要になります。この変更点は、一方向および双方向のネットワークAPI両方に対して適用されます。以下に、カスタムHTTPヘッダを許可するためのポリシーファイルの例を示します。ドメインにおけるヘッダ使用許可のための、他のポリシーファイル設定例について詳しくは、次のテクニカルノート「一部のヘッダがFlash Playerからリモートドメインへ送信されない」を参照してください。ヘッダとポリシーファイルについて詳しくは、『Flash Player 9 2008年4月付けセキュリティアップデートへの対応の理解』のポリシーファイルの節を参照してください。
メタポリシーの義務化
影響度:今回の変更は、マスター以外のHTTPポリシーファイルを使用するすべてのコンテンツに影響します。また、サーバのルートディレクトリにファイルを配置するのが困難な、コンテンツデリバリネットワーク(CDN)またはそれに類似したホスティング環境からデータを読み込むSWFファイルがある場合は、直ちに準備を進める必要があります。
解説:他のドメインのSWFファイルに対してデータの読み込みを許可するサーバには、必ず、所定のマスター位置(/crossdomain
xml)にポリシーファイルが配置されている必要があります。引き続き、サーバ上の他のポリシーファイルを使用することは可能ですが、この場合、必ずマスターポリシーファイルのメタポリシー設定を通じて、これらの使用が許可される必要があります。マスターポリシーファイルが所定のマスター位置にない場合、マスターポリシーファイルにメタポリシーが含まれていない場合、あるいはマスターポリシーファイルの設定がmaster-onlyになっている場合、Flash Playerは当該ドメイン上の他のポリシーファイルを無視します。所定のマスター位置にポリシーファイルを作成するのが困難または望ましくない場合は、HTTPレスポンスヘッダを利用してメタポリシーを定義することも可能です。ポリシーファイルをディレクトリ単位で管理することを希望する場合は、メタポリシーだけを定義するマスターポリシーファイルを設置することができます。こうすれば、マスターポリシーファイル自体で各種権限を定義することなく、他のポリシーファイルを使用することが可能です。以下に、この設定に関するいくつかの例を示します。サーバから提供されるすべてのコンテンツを完全に制御でき、しかも、ユーザまたは予期せぬコンテンツ提供者が当該サーバ上にポリシーファイルを作成するのが不可能な場合は、サーバ上のすべてのファイルがポリシーファイルとして使用されることを許可するために、meta-policyの値としてallが使用できます。このポリシーファイルの例を以下に示します。この設定例を以下に示します。
次のステップ
このバージョンのFlash Playerには、本記事で紹介したセキュリティ変更がすべて含まれているとともに、Flash Player 10ベータで発表済みの、他のセキュリティモデル変更が盛り込まれています。また、Flash Playerのログ保存機能を有効化することで、ポリシーファイルの変更に伴って発生したエラーの一覧が確認できます。ログ保存機能を有効化する方法について詳しくは、『Flash Player 9におけるポリシーファイルの変更』のログ保存の節』を参照してください。メタポリシーは、サーバ上のポリシーファイルの使用・不使用を制御するための重要な要素です。コンテンツデベロッパーおよびサーバ管理者の方々には、用意されているさまざまなオプションに慣れ親しむことをお勧めします。さらに詳しい解説、およびこれらがHTTPまたはソケットポリシーにどのように適用されるかについて詳しくは、『Flash Player 9におけるポリシーファイルの変更』のメタポリシーの節を参照してください。
著者について
でFlashプラットフォームマネージャーとして、同社を取り巻く資産を活用してリッチインターネットアプリケーション開発に適したオプションを検討する仕事をしていました。
お問い合わせ
不正コピー防止について
著作権と商標について*
当Webサイトをご利用のお客様は、利用規約およびプライバシーポリシー(2009年7月14日更新)にご同意いただいたものとみなされます。
記事のアーカイブ*
ユーザグループの検索*
ユーザグループについて*
即時かつ厳密な対処のための動作の変更点
付録A: ブラウザへの依存性
付録B: ログメッセージの解説
印刷用に表示
xx)について解説します。注: この記事は2008年7月に更新されています。更新前のバージョンの記事を閲覧したユーザにとって重要な変更点は、次の3点です。
0には、ソケット接続に対する完全に厳密な制限動作(フェーズ1
5)が実装されています。0からは、この新しい制限のフェーズ2が実装されています。2003年に、Flash Player 7ソフトウェアでは、ポリシーファイルによるドメイン間の直接データロード許可というクライアントとサーバ間の通信チャネルがWebの新機能として導入されました。ポリシーファイルが導入される前、Webコンテンツで実行できたのは、ランタイム設定やページをリロードしないトランザクションなど、ホストサーバとの双方向通信のみでした。ポリシーファイルにより、サーバは他のドメイン(つまり、通常は任意の場所)のクライアントコンテンツにデータを選択的に開放できるようになりました。ポリシーファイルの導入により、リッチなインターネットアプリケーションの作成者にとってドメイン境界は大きな障害ではなくなりました。ほとんどの新しいテクノロジと同様に、ポリシーファイルは最初の導入時には完全なものではありませんでした。導入から4年が経過し、ポリシーファイルには、インターネットセキュリティ上の問題点が2点あることが判明しました。これらの問題についてはこの記事で追って説明します。ポリシーファイルの基本前提は今でも有効であり、Flash開発者はFlash 6以降と同じように引き続きポリシーファイルを使用できます。ただし、新たに見つかった問題点に対応するために、アドビではポリシーファイルの使用についていくつかの厳密なルールを定めています。また、ポリシーファイルを便利で使いやすいものにするために、様々な改善も行われています。これらの変更が行われた理由をわかりやすく簡単に説明します。この記事では、読者がポリシーファイルに関してある程度知識をお持ちであることを前提としています。また、この記事では取り上げていない、ポリシーファイルのHTTPヘッダ送信権限について詳しくは、別途記事の「2008年4月のFlash Player 9のセキュリティアップデートについて」を参照してください。
Webサイトにおいて必要な対策
厳密なルールに準拠するために、ポリシーファイルを提供するWebサイトにはいくつかの小さな変更が必要になります。これらの変更は、主にサイト自体を保護するためのものであり、基本的には、ポリシーファイルに関する新しいセキュリティ上のベストプラクティスになります。ほとんどのサイトでは、変更は困難ではないと予想されますが、影響が及ぶサイトが多数あるため、アドビではFlash Playerの厳密な要件を3段階のフェーズで導入しています。0から開始)では、少数の厳密なルールは直ちに強制されますが、ルールに違反しても、ほとんどの場合はFlash Playerのデバッグバージョンで警告が表示されるだけです。0から開始)では、ソケット接続の場合に限りフェーズ1の警告がエラーになるようになりました。0から開始)では、フェーズ1のすべての警告がエラーとなり、厳密なルールが完全に適用されるようになります。Webサイトの管理者は次の手順に従うことをお勧めします。即時: 即時かつ厳密な対処に関する節を読んだ後、即時解決を要する問題を診断および修正するためのワークフロー手順を実行します。この手順を追うことで、フェーズ1の影響に対処できます。即時: ソケットポリシーファイルに関する節を読んだ後、ソケットポリシーファイルを設定するためのワークフロー手順を実行します。この手順は主に、既にソケットポリシーファイルを提供しているサイトが適用の対象となりますが、ポリシーファイルまたはSWFファイルがないサイトの防御策としても役立ちます。
この手順を追うことで、フェーズ1
5の影響に対処できます。時間がある場合:メタポリシーに関する節を読んだ後、メタポリシーを選択および設定するためのワークフロー手順を実行します。この手順は主に、既にポリシーファイルを提供しているサイトが適用の対象となりますが、ポリシーファイルまたはSWFファイルがないサイトの防御策としても役立ちます。この手順を追うことで、フェーズ2の影響に対処できます。
対応済みの問題
厳密なポリシーファイルルールは、次の2つの問題に対応しています。ポリシーファイルではないと思われるサーバ上のファイルが、ポリシーファイルとして使用されている可能性があります。例えば、サーバでユーザによるアップロードが許可されているが、クロスドメインアクセス用にデータが開かれることが意図されていない場合、ユーザが意図的にポリシーファイルを作成し、ポリシーファイルを別の種類のファイル(普通のテキスト、XML、HTMLなどのファイル)、またはバイナリファイル(PNGやJPEGなどのイメージファイル)と偽装する可能性があります。この偽装されたポリシーファイルをアップロードしたユーザが、偽装されたポリシーファイルを利用してサーバのドメインの外部からデータをロードするSWFファイルを作成する可能性があります。同様に、権限が制限されているサイトの保守担当者が、管理者の意に反してサイトにポリシーファイルを追加したり、意図しないポリシーファイルを誤って作成したりする可能性もあります。これは基本的に、サーバ上に配置することが許可されるポリシーファイルの管理方法に関する問題です。サーバ管理者は、ポリシーファイルでサーバ全体のポリシー(メタポリシーと呼びます)を設定し、サーバ上のすべてのポリシーファイルを簡単に検索して、サーバに存在するすべてのクロスドメイン許可を監査できる必要があります。Flash Playerの厳密なポリシーファイルルールにより、サーバ管理者によるメタポリシーの宣言が可能になり、ポリシーファイルが正常かどうかをチェックして、適切な形式かどうかを確認できます。DNSリバインディングと呼ばれる種類のクロスサイトスクリプティング攻撃は、Flash Player以外に、ブラウザ、仮想マシン、およびその他のユーザエージェントプログラムを対象とする可能性があります。この攻撃では、特定のインターネットドメインのコンテンツが、明示的な許可なしでそのドメイン内の他のリソースをロードしたり、それらのリソースと通信したりすることが許可されます。独自のドメインを管理し、独自のDNSサーバを実行している攻撃者は、そのDNSサーバを動的に再設定して、特定のドメイン名が自分の管理下にあるIPアドレス(悪意のあるSWFファイルやその他のコンテンツの提供に使用される可能性があります)にいったん解決された後で、自分の管理下にない別のIPアドレスに解決されるようにする可能性があります。ユーザエージェントプログラムでIPアドレスの変更が検出されない場合、同一生成元ポリシーにより、2番目のホストからの許可がなくても、攻撃者のコンテンツが2番目のIPアドレスにアクセスすることが許可されます。Flash Playerはブラウザに依存してHTTPネットワークを提供しているため、HTTPのみに関連するリバインディングの脆弱性はブラウザで解決する必要があります。0の厳密なポリシーファイルルールにより、ソケットに関連する場合はDNSリバインディングの脆弱性を緩和できます。特に、厳密なルールにおいては、接続しているSWFファイルの送信元ドメインがソケットサーバと同じと思われる場合でも、ソケット接続を確立するために、常にソケットポリシーファイルからの許可が必要です。0以降では、ドメイン名だけでなくIPアドレスに基づいて、ソケット接続を対応するソケットポリシーファイルと照合しています。
その他の改善点
上記の問題に対応すると同時に、ポリシーファイルをより便利に簡単に使うための新機能も追加されました。
Flash Playerのデバッグバージョンからのポリシーファイルイベントの詳細ログ
ポリシーファイルのロードと処理、およびそのポリシーファイルに依存する操作が失敗したか正常に終了したかは、すべて報告されます。これは、厳密なルールへの移行だけでなく、ポリシーファイル展開に関連する問題の検出や解決にも役立ちます。
固定されたソケットマスターポリシーファイルポート(TCPポート843)
ソケットポリシーファイルの検出時にデフォルトで参照されます。これにより、以前に使用されていた「任意のポートを選択する」システムではなく、標準的な方法でソケットポリシーファイルを提供できます。
ローカルソケットの強力なクライアント認証を必要とするオプション
これにより、オンラインのFlashコンテンツをネイティブのローカルアプリケーションと結び付ける、安全なハイブリッドアプリケーションが実現します。
著者について
Deneb は自ら現在問題になっているセキュリティの変更を実装しました。セキュリティの問題では深い自責の念に駆られましたが、Deneb 自身その 10 倍以上大変だったことは間違いありません。最近は、週末をサンフランシスコのベイエリアでハンググライダーに乗って過ごすようになりました。
お問い合わせ
不正コピー防止について
著作権と商標について*
当Webサイトをご利用のお客様は、利用規約およびプライバシーポリシー(2009年7月14日更新)にご同意いただいたものとみなされます。
記事のアーカイブ*
ユーザグループの検索*
ユーザグループについて*
即時かつ厳密な対処のための動作の変更点
付録A: ブラウザへの依存性
付録B: ログメッセージの解説
URLによるネットワーク接続は、URLポリシーファイルによって承認されますが、ActionScriptのソケットレベル接続は、ソケットポリシーファイルによって承認されます。0では、ソケットポリシーファイルの機能が、部分的に変更されています。これらの変更は、主にDNS強化という目標を達成するためのもので、ActionScriptを利用したDNSリバインディング攻撃によって、不正なソケット接続が行われないようにすることを目的としています。有効なソケットポリシーファイル構成をホストに実装するための簡単な手順については、ソケットポリシーファイルのワークフローを参照してください。ただし、サーバホストの管理者は、先にこの概要の節に目を通すことをお勧めします。管理対象のホストでFlash Player互換コンテンツを提供する予定がない場合でも、一読することをお勧めします。そのようなホストでも、ソケットベースのDNSリバインディング攻撃を受ける可能性はあります。ここでは、メタポリシーの節の内容を前提としているため、必ずメタポリシーの節を先にお読みください。
ソケットポリシーファイルの背景
0でソケットポリシーファイルが導入されたときから変更されていない情報を示します。ソケットポリシーファイルの目的は、URLポリシーファイルと同様、 クライアントコンテンツからの接続を承認することです。URLポリシーファイルは、提供元のHTTP、HTTPS、またはFTPの各サーバからのデータロードの承認に使用されますが、ソケットポリシーファイルは、提供元のホストへのソケット接続の承認に使用されます。すべてのポリシーファイルには、許可(接続を承認するドメインのリスト)、およびスコープ(アクセス許可の対象となる一連のリソース)の2つの必須属性が含まれます。ソケットポリシーファイルは、許可に関してはURLポリシーファイルと同様に機能しますが、スコープに関してはURLポリシーファイルとは仕組みが異なります。URLポリシーファイルのスコープは、ポリシーファイルの場所によって決まりますが、ソケットポリシーファイルのスコープは、ファイルの内容によって決まります。ソケットポリシーファイルは、ホスト上の任意のTCPポートから提供できますが、ポート1024以上のポートからロードされるソケットポリシーファイルでは、ポート1024以上のポートに対する接続のみ承認できます。1024より小さい番号のポートから読み込まれるソケットポリシーファイルでは、ホスト上の任意のポートに対する接続を承認できます。ソケットポリシーファイルは、メイン接続(ActionScriptによって行われるソケット接続で、ソケットポリシーファイルによって承認される)と同じポートから提供することも、メイン接続とは別のポートから提供することもできます。ソケットポリシーファイルをメイン接続と同じポートから提供する場合は、そのポートをリッスンしているサーバがソケットポリシーファイル要求を認識し(Flash Playerから<policy-file-request/>で転送を指定)、ポリシーファイル要求とメイン接続要求を区別して応答できるようにする必要があります。通常は、ソケットポリシーファイルを別のポートから提供する方が簡単です。これにより、ホストのソケットポリシーを1か所で集中管理できます。また、ほとんどのサーバには、自身のソケットポリシーファイルを提供する機能が備わっていません。xml をURLポリシーファイルのマスター場所として認識していました。
しかし、バージョン9
0より前のFlash Playerでは、ソケットポリシーファイルの固定のマスター場所を認識していませんでした。0では、ソケットマスターポリシーファイルという概念を導入し、このファイルを固定のTCPポート番号843から提供します。ソケットマスターポリシーファイルを使用することにより、次のような様々なニーズに対応できます。ポート番号を固定することで、ソケットポリシーをホストから提供するための標準的な方法が確立されます。以前は、各ホストの管理者が自分でソケットポリシーファイルの提供ポートを決定する必要がありました。固定のポート番号が与えられたことで、スタンドアロンのソケットポリシーファイルサーバをポート843にデフォルトでバインドできるため、管理者は慣れないコンピュータでもソケットポリシーを簡単に見つけることができます。マスター場所が決定されたことで、ソケットメタポリシーを宣言できるようになりました。ソケットメタポリシーは、以前説明したURLメタポリシーと同様、ホスト上に配置できるソケットポリシーファイルの種類を制御するためのものです。これについては、後述のソケットメタポリシーに関する節で詳しく説明します。ソケットポリシーファイルをポート843から提供することで、Flash Playerのフェーズ1バージョンでも、ホスト管理者が新しいソケットルールの使用を選択できるようになります。これについては、後述の「厳密なソケットルールの使用」の節で詳しく説明します。注:アドビでは、ソケットポリシーファイルサーバに関する情報ページ*を公開する予定です。このページでは、ソケットポリシーファイルの提供だけを行うサーバを作成するための手順やサンプルコードを紹介します。これには時間がかかることが予想されますが、その間にポート843の使用目的に関する文書をできる限り広く公開したいと考えています。ポート番号843は1024よりも小さいため、ソケットマスターポリシーファイルでは、ホスト上の任意のポートに対するアクセスを承認できます。Unixスタイルのホストでは、通常、サーバを1024未満のポートにバインドするにはルートアクセス(管理者権限)が必要なため、1024の境界は重要な意味を持ちます。つまり、Unixスタイルのホストでソケットマスターポリシーファイルをセットアップするには、通常はルートアクセスが必要になるため、ホストを有効に保護できます。ソケットマスターポリシーファイルをファイアウォール経由で提供する場合は、ファイアウォールのトラバースに関する問題についての節を参照してください。ソケットメタポリシーは、URLメタポリシーと同様の機能を果たします。ただし、次のような違いがあります。ソケットメタポリシーは、URLポリシーファイルではなく、ソケットポリシーファイルを対象としています。ソケットメタポリシーは、1つのURLサーバだけではなく、ホスト全体を対象としています。ソケットメタポリシーは、ソケットマスターポリシーファイル内でのみ宣言できます。ソケットメタポリシーは、HTTPとは無関係なため、HTTP応答ヘッダでは宣言できません。ソケットメタポリシーでは、URLメタポリシーとして使用できるメタポリシーのセットとは異なるメタポリシーのセットを使用します。また、ソケットメタポリシーとURLメタポリシーでは、デフォルト値が異なります。有効なソケットメタポリシーは次のとおりです。all: このホストでは、任意のポートからソケットポリシーファイルを提供できます。このメタポリシーは、ログイン信用情報を必要とするコンテンツを提供しないインターネット上のホストにのみ適用できます。none: このホストでは、ソケットポリシーファイルを提供できません。このメタポリシーをマスターポリシーファイル内で宣言すると、そのマスターポリシーファイルは、このメタポリシーを宣言する目的でのみ存在することになり、<allow-access-from>ディレクティブが含まれていても無視されます。デフォルトのソケットメタポリシーはallです。Flash Playerでは、ソケットマスターポリシーファイル内でソケットメタポリシーが宣言されていないすべてのホストについて、メタポリシーがallであるものと見なされます。この点は、URLポリシーファイルとは異なります。このように、ソケットポリシーファイルのデフォルトのメタポリシーは、URLポリシーファイルほど厳密ではありません。これは、ソケットでは、URLサーバと比べて、不正ポリシーファイルが使用される危険性が非常に低いためです。例えば、HTTPサーバでは、ユーザが作成したコンテンツ(サーバ管理者以外の人が作成したコンテンツ)が提供されることが珍しくないため、フェーズ2でデフォルトのURLメタポリシーをmaster-onlyにすることによって、誰かがポリシーファイルを作成する前に、管理者が事前にポリシーファイルを使用できるようにしておくことは、有効な手段です。一方、ホストで認証を受けていないユーザがインストールを実行したり、TCPポートをリッスンするサーバ全体を変更したりすることが許可されることはめったにないため、デフォルトのソケットメタポリシーをallにすることによって、管理者が明示的に禁止しない限り、ホスト上の任意の場所にソケットポリシーファイルを作成できるようにしておくことも重要です。
厳密なソケットルール
0で行われた主な変更は、厳密なソケットルールの導入です。厳密なソケットルールとは、次の2つです。ソケットポリシーファイルがない場合、SWFファイルから自身のドメインにソケット接続を行うことができなくなりました。0より前のバージョンでは、ポリシーファイルがなくても、SWFファイルから自身のドメインの1024以上のポートに対してソケット接続を行うことが許可されていました。ソケット接続の承認にHTTPポリシーファイルを使用できなくなりました。xml から提供)を使用して、同じホスト上の1024以上のポートに対するソケット接続を承認することができました。これら2つのルールを簡単な表現にまとめると、「厳密なソケットルールでは、すべてのソケット接続にはソケットポリシーファイルによる許可が必要である」ということになります。Flash Player9のほとんどのポリシーファイルに関する変更と同様、厳密なソケットルールは、2段階のフェーズに分けて導入されました。0から開始)では、厳密なポリシーファイルルールに従っていなくても、Flash Playerのデバッグバージョンで警告が表示されるだけでした。0から開始)では、これらの警告がエラーとなり、以前のルールに従って作成されたSWFファイルが意図通りに機能しなくなる恐れがありました。ホスト管理者に対しては、Flash Playerのフェーズ1バージョンを使用しているユーザについてもDNSリバインディング攻撃からサイトを保護できるよう、厳密なルールの適用がフェーズ1の段階から選択肢として提供されていました。ソケットポリシーファイルのワークフローでは、厳密なソケットルールの導入によって発生する問題を発見および解決するための詳細な方法が示されています。要約すると、上記2つのうちいずれかの状況でソケット接続を行うSWFファイルを管理している場合、接続先のホストでソケットポリシーファイルが提供されている必要があります。ソケットポリシーファイルを提供するには、通常、ポート843にソケットマスターポリシーファイルサーバをセットアップしますが、これ以外の方法については、ワークフローに関する節を参照してください。
厳密なソケットルールの使用
Flash Playerのフェーズ1バージョンでは、次のように構成することにより、ホストで厳密なソケットルールが使用されるようになります。これは、ホスト管理者とSWFファイルの保守担当者の両者にとって重要な情報です。ホスト管理者は、この情報に従って、より安全なルールを管理対象のホストに適用することを選択でき、SWFファイルの保守担当者は、このような構成によって、保守対象のSWFファイルがソケット接続を行うことができるかどうかにどのような影響があるのかを理解する必要があるからです。ホストが、ポート843からソケットポリシーファイルを提供する場合(ソケットマスターポリシーファイル)、厳密なソケットルールがホスト全体に適用されます。これは、ポリシーファイルの内容に関係なく実行されます。ソケットマスターポリシーファイルが空である場合や、メタポリシーallが宣言されている場合でも、ホストでは厳密なソケットルールが使用されます。このホストにソケット接続を行うには、必ずソケットポリシーファイル(多くの場合、厳密なソケットルールへの移行の原因となったソケットマスターポリシーファイルと同じポリシーファイル)による許可が必要になります。これは、ホスト管理者が厳密なソケットルールの適用を選択する場合に使用する一般的なメカニズムです。xml)で宣言している場合、そのマスターHTTPポリシーファイルでは、同じホストへのソケット接続に対する承認が行われません。この構成では、2つの厳密なソケットルールのうち、1つだけがホストに適用されます。SWFファイルによる同じホストへの接続に関するルールは、適用されません。マスター以外のソケットポートからソケットポリシーファイルを提供する場合、厳密なソケットルールは、そのポートにのみ適用されます。このポートにソケット接続を行うには、必ずソケットポリシーファイル(多くの場合、このポートから提供されているソケットポリシーファイルと同じポリシーファイル)による許可が必要になります。このルールによって発生する可能性のある意図しない影響については、即時に適用される厳密なソケットに関する節で説明しています。
その影響とは、1024以上のソケットポートから提供されるソケットポリシーファイルのリストに自身のドメインが含まれていない場合、そのドメインのSWFファイルが接続できなくなることです(以前はポリシーファイルがなくても接続できました)
安全なドメインのリスト
これにより、HTTPSサーバのデータを保護することができ、取得元を正確に認証できないSWFファイルにデータが渡されることがなくなります (HTTPSにはドメイン認証と耐タンパー性のテクノロジが組み込まれているため、HTTPS経由で取得されるSWFファイルは、HTTP経由で取得されるSWFファイルよりも、偽造の可能性が低いと言えます)
つまり、ローカルソケット(Flash Playerと同じコンピュータから実行されているソケットサーバ)で提供されるソケットポリシーファイルでもサポートが開始されます。この機能を使用したローカルソケットポリシーファイルの例を次に示します。
このようなポリシーファイルで許可されるのは、HTTPS経由でmy
comから読み込まれたSWFファイルが、ポート3050に接続する場合のみです。comからHTTP経由でロードされたSWFファイルには、このポリシーファイルではアクセス許可が与えられません。secure="true"宣言と共にリストに記載されたドメインは、安全なドメインのリストと呼ばれます。ローカルソケットポリシーファイルの安全なドメインのリストは、オンラインとオフラインの両方で使用するアプリケーションで役立つ可能性があります。
あるアプリケーションで、ユーザのマシンにネイティブのローカルコンポーネントをインストールして、Webブラウザ経由でオンラインのSWFインターフェイスを提供し、ActionScriptソケット接続を使用してWeb上のSWFとローカルコンポーネントとの間で通信する場合を考えてみましょう
このシナリオでは、アプリケーション開発者は、特定のSWFファイルだけがローカルコンポーネントと通信できるようにする必要があります。そうしなければ、Web上の他のSWFファイルが、ローカルコンポーネントのネイティブな機能を乱用する可能性があるからです。
このアプリケーションの開発者が、すべてのSWFファイルをmy
comのHTTPSサーバに登録し、secure="true"宣言を含む前述のソケットポリシーファイルをローカルコンポーネントから提供すれば、その開発者が登録したSWFファイル以外のすべてのSWFファイルは、ローカルコンポーネントに接続できなくなります。
ローカルアプリケーションの開発者が安全なドメインのリストを利用するには、アプリケーションのユーザがバージョン9
ただし、ローカルソケット(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"をローカルソケットポリシーファイルで宣言した場合は、ソケットポリシーファイルをサーバからFlash Playerに転送するときに、ホストの外部でネットワーク接続が行われることはありません。
アドレスを基準としたソケットポリシーファイルのスコープ
0で行われたソケットポリシーファイルに対する変更の1つは、ActionScriptには影響せず、その内容も変更されません。
comからのソケットポリシーファイルを検出すると、そのポリシーファイルがa
comに対するすべてのソケット接続の承認に使用されていました。
この方法では、DNSリバインディングにより、ソケット接続時にa
comの参照先がポリシーファイルの取得時とは異なるホストに設定される可能性があります。つまり、あるホストが別のホストに対するアクセス権を指定することになります。0からは、ソケット接続を許可する前に、ソケットポリシーファイルが接続先のホストと同じIPアドレスから取得されたものであるかどうかが、常にチェックされます。
ソケットポリシーファイルの動作によるサーバホストへの影響
0では、ホストで通常とは少し異なるトラフィックが発生する場合があるため、その調整が行われます。トラフィックの相違点は、次のとおりです。SWFファイルがソケット接続を実行しようとすると、それが自身のドメインに対してであっても、Flash Playerではまずポート843にアクセスして、ホストでソケットマスターポリシーファイルが提供されているかどうかを確認します。0のソケット接続で実行されるポリシーファイルの確認に関するデフォルトの動作は変更されません。
0のソケット接続では、メイン接続と同じポートに対するチェックがデフォルトで行われていました)
Flash Playerによって自動的に要求されるソケットポリシーファイルについて、ホストが3秒以内に応答せず、接続試行も拒否しない場合、Flash Playerは、その場所にポリシーファイルが存在しないものと判断してその試行を中止し、ポリシーファイルログに警告を記録して、ソケットポリシーファイルによる承認の次の段階へ移行します。このタイムアウト動作により、Flash Playerが成功する可能性のないソケット接続を長時間待機することがなくなりますが、一時的なネットワークの停止や、低速な接続、サーバに過剰な負荷がかかっている状況などに対する柔軟性が、若干損なわれることになります。このような状況がなければ自動的に取得されるソケットポリシーファイルが存在することがわかっている場合は、SWFファイルから明示的にloadPolicyFileを呼び出し、そのソケットポリシーファイルのURLを指定することにより、3秒のタイムアウト動作が実行されないようにすることができます。これにより、そのポリシーファイルの取得待機時間を長くすることができ、TCPのタイムアウト(2分間)が経過するまで、次の段階に移行しないようにすることができます。
ファイアウォールのトラバースに関する問題とソケットポリシーファイル
ソケットマスターポリシーファイルの欠点は、クライアントがポート843にアクセスできなければならないことです。アウトバウンド通信を制限するファイアウォールの内側にいるユーザの中には、これができない人もいます。しかし、アウトバウンド通信を制限するファイアウォールでも、ポート843へのアクセスを許可することは有効です。これにより、Flash Playerにおいて、ホスト管理者が宣言したセキュリティポリシーを適用できるようになります。また、ポート843の目的を標準化することができれば、他の種類のサーバがこのポートに関連付けられることがなくなります。しかし、ソケットマスターポリシーファイルは新しい概念であり、ファイアウォールのルールセットにポート843へのアクセスが組み込まれるようになるまでには、まだ時間がかかります。ここでも、ポート843へのアクセスを許可するかどうかについては、ファイアウォール管理者個人の裁量に委ねられます。以降では、この問題がFlash Playerユーザやサーバホストに深刻な問題を引き起こすことがない理由を説明します。ポート843にアクセスできないことによる影響は、次のとおりです。ソケットメタポリシーが遵守されません。
すべてのソケットポリシーファイルによるアクセス許可の付与が認められます(ただし、ファイアウォールの内側にいるユーザについてのみ)
Flash Playerのフェーズ1バージョンでは、ホストでソケットマスターポリシーファイルの採用によって新しいルールの使用を選択している場合、その選択がFlash Playerに認識されません。ファイアウォールの内側にいるユーザは、依然として1024以上のソケットポートを対象としたDNSリバインディング攻撃の媒介者となる可能性があります。ホストでソケットマスターポリシーファイルを使用してソケット接続の承認を行っている場合、ファイアウォールの内側にいるユーザは、このような接続を確立できません。このような影響により、細かい問題が発生する場合もありますが、大きな問題にはなりません。その理由は次のとおりです。ユーザがファイアウォールの内側におり、ポート843にアクセスできない場合、対象のポートにもアクセスできない可能性があるため、上記3つのデメリットが実質的に問題にならなくなります。ファイアウォールで常に接続が許可されているポートにはいくつかありますが(HTTPの80など)、多くのポートへのアクセスは許可されておらず、1024以上のほとんど、またはすべてのポートへのアクセスも許可されていない可能性が高いと言えます。この最後の点により、特に問題2が発生することはほとんどないと考えられます。ファイアウォールの内側を対象としたDNSリバインディング攻撃で、ポート843へのアクセスが問題になることは少ないと考えられます。これは、ファイアウォールでその内側にあるサーバのすべてのポートへのアクセスがブロックされることはめったにないからです。上記の問題1について、ソケットメタポリシーによる制限を回避しようとする攻撃者(そのような攻撃者自体がほとんどいない)が、アウトバウンド通信を制限するファイアウォールの内側にいるユーザを特に媒介者として利用しようとする可能性は低いと考えられます。
対策が必要な理由
ホストでソケットポリシーファイル(多くの場合ポート843のソケットマスターポリシーファイル)を提供する理由は、次の2つです。
• ホストにソケット接続を行うSWFファイルを管理しており、現在はソケットポリシーファイルを使用せずに接続を行っている場合(接続先が自身のドメインであるため、またはHTTPポリシーファイルを使用しているため)、Flash Playerのフェーズ1
0またはそれ以降)をインストールするユーザについては、このようなSWFファイルからソケット接続を行うことができません。ホストでソケットポリシーファイルを提供する予定がない場合、またはFlash Player互換のコンテンツをまったく提供する予定がない場合でも、悪意ある攻撃者がDNSリバインディング攻撃によってホストに不正なソケットレベルの接続を行おうとする可能性があります。ソケットマスターポリシーファイルを提供することによって厳密なソケットルールの使用を選択すると、Flash Playerのフェーズ1バージョンのユーザが、そのような攻撃の媒介者になることがなくなります。ソケットポリシーファイルの構成のワークフローでは、マスターソケットポリシーファイルをホストから提供するために必要な手順を示します。
お問い合わせ
不正コピー防止について
著作権と商標について*
当Webサイトをご利用のお客様は、利用規約およびプライバシーポリシー(2009年7月14日更新)にご同意いただいたものとみなされます。
記事のアーカイブ*
ユーザグループの検索*
ユーザグループについて*
即時かつ厳密な対処のための動作の変更点
付録A: ブラウザへの依存性
付録B: ログメッセージの解説
0の変更点に関連する問題にすばやく対処できるようになります。この記事の前半にある、変更点に関する概要の節を読んでから、この節を参照することをお勧めします。0では、ポリシーファイルログという新機能が導入されました。ポリシーファイルログには、ポリシーファイルの取得、ポリシーファイルの処理が正常に終了したか失敗したか、ポリシーファイルに依存する要求の結果など、ポリシーファイルに関連するすべてのイベントのメッセージが表示されます。ポリシーファイルログに表示されるメッセージの一覧については、付録Bを参照してください。ポリシーファイルログを使用するには、次の手順を実行します。0以降のデバッグバージョンをインストールします。cfg構成ファイルの場所を探します。これは、デバッグバージョンのFlash Playerが起動時に読み取る一般的なデバッグ構成ファイルです。cfgは「ホーム」ディレクトリにあります。一般的な例を次に示します。cfgが存在しない場合は作成し、次の行の1つまたは両方を追加します。PolicyFileLogAppendが有効になっている場合は、ログファイルの前の内容が常に保持され、最終的にはログファイルが大きくなります。ただし、PolicyFileLogAppendを有効にした場合は、適宜手動でログファイルの名前を変更するか、またはログファイルを削除する必要があります。この作業を行わないと、ログファイルが非常に大きくなり、前の出力が終了した場所と新しい出力が開始された場所を見つけるのが難しくなります。txtというポリシーファイルログが書き込まれる場所を探します。このログは必ずしも存在しているとは限りません。txtは次の場所にあります。最新の変更時刻であることを確認します。メッセージが表示されている場合、ポリシーファイルログは機能しています。テストする必要があるすべてのSWFコンテンツにアクセスします。ポリシーファイルの取得を伴うシナリオを使用して、コンテンツを実行します。
テストの実行中にポリシーファイルで行われた処理の詳細について、policyfiles
不明なメッセージがある場合は、付録Bを参照してください。txt以外に変更するか、別のディレクトリに移動して、次にFlash Playerを実行したときにログが上書きされないようにします。
即時解決を要する問題の検出と修正
0のいくつかの変更点は、SWFコンテンツに直ちに影響するため、ごく一部のSWFファイルで問題が発生する可能性があります。現状のSWFコンテンツを保持する場合は、早急に次の手順を実行する必要があります。0以降のデバッグバージョンをインストールします。ブラウザベースバージョンのFlash Playerを使用して、本番環境をシミュレートします。ActiveXプレーヤーまたはプラグインプレーヤーを使用できます。どちらを使用しても結果は同じになります。これにより、即時解決を要する問題に対する完全なテストを実施できるようになります。この要件を満たすブラウザの詳細については、付録Aを参照してください。上記のように、ポリシーファイルログを有効にします。SWFコンテンツをテストします。できるだけ多くのコンテンツを実行するようにします。ポリシーファイルログで、[strict]というラベルを含むメッセージを探します。このラベルは、即時解決を要する問題の可能性があることを示しています。期待どおりに機能していないコンテンツの状況をメモします。そのようなコンテンツは、デバッグが必要な問題を示している可能性があります。0での動作と異なることを確認します。古いバージョンと新しいバージョンのFlash Playerの間で動作に違いがない場合は、ポリシーファイルの厳密な対処に関連する問題ではありません。ActiveXコントロールのセキュリティ機能により、次の「/clean」コマンドを使用してアンインストーラを実行する必要があります。ポリシーファイルログで見つかった[strict]メッセージを分類します。メッセージの内容は次のとおりです。不正な形式のポリシーファイルは無視されているため、クロスドメインアクセスが拒否される可能性があります。このログメッセージの説明、および不正な形式のポリシーファイルについての節を参照してください。ポリシーファイルのリダイレクトによって、ポリシーファイルのスコープが変更される可能性があり、その結果、クロスドメインアクセスが拒否される可能性があります。このログメッセージの説明、およびドメイン内のリダイレクトについての節を参照してください。サーバで宣言された必須のテキストのContent-TypeがないHTTPポリシーファイルが受信されましたが、無視されます。クロスドメインアクセスが拒否される可能性があります。このログメッセージの説明、およびContent-Typeのホワイトリストについての節を参照してください。サーバで宣言された必須のテキストのContent-TypeがないHTTPポリシーファイルが受信されましたが、無視されます。クロスドメインアクセスが拒否される可能性があります。このログメッセージの説明、およびContent-Typeのホワイトリストについての節を参照してください。SWFコンテンツは、ローカルホスト上にあると思われるソケットに接続しようとしましたが、ホストがlocalhostとして指定されていませんでした。厳密なソケットルールが直ちに適用され、アクセスが拒否されます。このログメッセージの説明、および即時に適用される厳密なソケットについての節を参照してください。
URLメタポリシーの設定
メタポリシーの節で説明したように、HTTPサーバ、HTTPSサーバ、またはFTPサーバでメタポリシーを選択および宣言するのは2つの理由があります。0以降)をインストールするユーザには適用されなくなります。メタポリシーを設定することで、サーバのポリシーファイルがフェーズ2バージョンのFlash Playerのユーザ向けにスムーズに移行されます。サーバがポリシーファイル、またはFlash Player互換コンテンツを意図的に提供するかどうかに関係なく、サーバでテキストファイルを作成できるユーザはポリシーファイルを作成できます。このポリシーファイルを使用すると、サーバまたはユーザ(あるいはその両方)のプライベートなデータを取得できます。メタポリシーの宣言により、フェーズ1バージョンのFlash Playerのユーザには、デフォルトのメタポリシーallは適用されなくなります。管理していないサーバ上のサイトを操作している場合は、ホストされるサービスのユーザ向けの考慮事項についての節を参照してください。管理しているサーバ上のメタポリシーを設定するには、次の手順を実行します。まず、メタポリシーの基本をよく理解します。使用可能なメタポリシーのリストを確認します。サーバに最も適したメタポリシーを決定します。
HTTPサーバおよびHTTPSサーバ向けのガイドラインを次に示します(FTPサーバ向けのガイドラインも似ていますが、詳細が若干異なります)
サーバでポリシーファイルを提供しない場合は、メタポリシーnoneを選択します。サーバがユーザ定義コンテンツを提供する場合は、ユーザがポリシーファイルを作成できないようにするメタポリシー方針を選択します。これは基本的に、allを選択しないことを意味します。サーバへのアップロード権限を持つユーザが、ポリシーファイルを簡単に作成できるようにするには、メタポリシーallを選択します。xmlにあるマスターポリシーファイルの内容を変更できるようにします。これを実行するためのApache*設定スニペットの例を次に示します。ポリシーファイルの生成を許可したくないスクリプトをサーバがホストしている場合、このようなスクリプトの出力に特別なメタポリシーnone-this-responseを追加します。これを実行するためのApache*設定スニペットの例を次に示します。
マスターポリシーファイルとHTTP応答ヘッダのどちらを使用してメタポリシーを宣言するかを決定します (FTPサーバはマスターポリシーファイルを使用する必要があります)
各方法の長所と短所について、メタポリシーの指定方法に関する節を確認してください。xmlにあるマスターポリシーファイルに書き込みます。次に例を示します。これを実行するためのApache*設定スニペットの例を次に示します。
ホストされるサービスのユーザ向けの特別な考慮事項
ホストされるサービス上のサイト、または完全には管理していないサーバを操作していて、ポリシーファイルを提供する場合は、以下の点を考慮します。0の動作が停止した場合は、即時解決を要する問題に対するワークフローを実行します。サーバ管理者が対応しなくても、見つかったほとんどの問題を修正できるようになる必要があります。0がリリースされるまでに、ポリシーファイルが機能するようにするために、メタポリシーを設定する必要があります。サービス利用者の問題を解決するためには、サーバ管理者にサービス全体を変更してもらう必要があります。サービスプロバイダに連絡し、この記事を案内して変更の検討を依頼することもできます。(サイトを不正な ポリシーファイルから守るなどの目的で)メタポリシーをすぐに設定する場合、またはサービスプロバイダがサービス全体の修正を行っていない場合、サイトのルートディレクトリへのアクセス権があれば、 自分で問題を修正できます。URLメタポリシーを設定するためのワークフローを実行します。HTTP応答ヘッダに影響を及ぼすことはできないため、オプションは限定される可能性があります。適切なオプションは次のとおりです。サイトで1つのポリシーファイルを使用する場合は、次のオプションを使用します。サイトでのポリシーファイルの作成を制限しない場合は、次のオプションを使用します。
ソケットポリシーファイルの設定
ソケットポリシーファイルについての節で説明したように、ホスト上のポート843からソケットマスターポリシーファイルを提供するのには2つの理由があります。
• ホ ストにソケット接続を行うSWFファイルを管理しており、現在はソケットポリシーファイルを使用せずに接続を行っている場合(接続先が自身のドメインであ るため、またはHTTPポリシーファイルを使用しているため)、フェーズ1
0またはそれ以降)をインストールするユーザについては、このようなSWFファイルからソケット接続を行うことができません。
ソケットマスターポリシーファイルを提供することで、ホストへのソケット接続が、フェーズ1
5バージョンのFlash Playerのユーザ向けにスムーズに移行されます (特定のSWFコンテンツがソケットポリシーファイルなしでホストへの接続を確立するかどうかわからない場合は、ポリシーファイルログを使用してコンテンツをテストし、非推奨のソケット設定に関する警告を探します)
ホストでソケットポリシーファイルを提供する予定がない場合、またはFlash Player互換のコンテンツをまったく提供する予定がない場合でも、悪意ある攻撃者がDNSリバインディング攻撃によってホストに不正なソケットレベルの接続を行おうとする可能性があります。ソケットマスターポリシーファイルを提供することによって厳密なソケットルールの使用を選択すると、Flash Playerのフェーズ1バージョンのユーザが、そのような攻撃の媒介者になることがなくなります。ソケットマスターポリシーファイルの提供は、これらの問題に対処する唯一の方法ではありませんが、最も簡単かつ一貫性のある方法です。何らかの理由でポート843からマスターソケットポリシーを提供できない場合は、ポート単位でこれらの問題に対処し、個別のポートからマスター以外のポリシーファイルを提供します。ただし、ソケットマスターポリシーファイルはホスト全体に同時に対応する必要があります。ソケットマスターポリシーファイルを提供するには、次の手順を実行します。使用可能なソケットメタポリシーのリストを確認し、ホストに適したソケットメタポリシーを決定します。ソケットマスターポリシーファイルを作成し、目的のソケットメタポリシーと付与するアクセス許可を宣言します。次に例を示します。ソケットポリシーファイルサーバの情報ページ*にアクセスし、ソケットポリシーファイルサーバの設定方法を決定します。ホストでソケットポリシーファイルサーバを実行し、作成したソケットマスターポリシーファイルを提供します。
お問い合わせ
不正コピー防止について
著作権と商標について*
当Webサイトをご利用のお客様は、利用条件およびプライバシーポリシー(2009年7月14日更新)にご同意いただいたものとみなされます。
記事のアーカイブ*
ユーザグループの検索*
ユーザグループについて*
即時かつ厳密な対処のための動作の変更点
付録A: ブラウザへの依存性
付録B: ログメッセージの解説
付録B:ログメッセージの解説
xml)に記録されるメッセージについて説明します。ログ記録に関する節で詳述したとおり、これらのメッセージの一部には、識別子[strict]が接頭辞として付加されています。この識別子は、フェーズ2の近い将来発生する可能性のある問題の警告ではなく、フェーズ1での即時解決を要する問題であることを示します。詳細については、即時解決を要する問題の節を参照してください。最上位のSWFファイルが、示されたURLからロードされました。通常、これはログの最初のメッセージです。追加モードのログ記録を有効にした場合は、複数回表示されることがあります。このメッセージにより、後のメッセージのコンテキストがわかり、ログを生成したFlash Playerセッションを開始したSWFファイルを確認することができます。
ポリシーファイルに依存する要求
SWFファイルが、ポリシーファイルからのデータ読み込み許可が必要な操作を実行しようとしたため、ポリシーファイルの検出処理が開始されます。このメッセージのURLは、SWFファイルのロード元と、SWFファイルがどのリソースを要求したかを示します。SWFファイルが、ポリシーファイルからのヘッダ送信許可が必要とされる、カスタムリクエストヘッダを伴うHTTP操作を実行しようとしたため、当該ポリシーファイルの検出処理が開始されます。このメッセージのURLは、SWFファイルのロード元と、SWFファイルがどの送信先にカスタムHTTPリクエストヘッダを送信しようとしているかを示します。(URL) のリソースに対する、(URL) の要求者からの要求は、ポリシーファイルのアクセス権がないため拒否されました。SWFファイルが、ポリシーファイルによる許可が必要な操作を実行しようとしましたが、この操作を許可した有効なポリシーファイルが見つかりませんでした。このメッセージのURLは、SWFファイルがどのリソースを要求したか、およびSWFファイルのロード元を示します。このメッセージは様々な理由で発生します。発生した特定の問題を示すのではなく、実行できなかった必要な手順を示します。場合によっては、このメッセージが表示される前に、より具体的な別のメッセージが表示され、この最終的なエラーメッセージの前に多くの情報が提供されることがあります。考えられる原因は次のとおりです。操作を許可するために適用できるポリシーファイルが存在しません。リソースが存在するサーバを管理している場合は、そのサーバにポリシーファイルを追加する必要があります。それ以外の場合、SWFファイルのホストサーバを通じて操作を委任する必要があります。適用できるポリシーファイルは存在しますが、ポリシーファイルとリソースの両方が存在するサーバにその時点で到達不能でした。サーバホストにpingして、到達可能かどうかを確認します。
ソケット接続の場合は、この状況で、前に示したメッセージ(「
適用できるポリシーファイルは存在しますが、SWFファイルの特定のドメインによるアクセスに対する許可が付与されていません。既存のポリシーファイルにリストされたSWFファイルのドメインを取得するか、既存のポリシーファイルによって許可されたドメインにSWFを移動するか、新しいポリシーファイルを追加するか、またはSWFファイルのホストサーバを通じた要求の委任を試行してください。適用できるポリシーファイルは存在しますが、デフォルト以外の場所に存在するため、操作を試行したSWFファイルがallowDomainを呼び出してポリシーファイルの場所をFlash Playerに通知しませんでした。適用できるポリシーファイルは存在しますが、何らかの理由で無効になっています。この場合、このメッセージの前に、ポリシーファイルのURLと検出された問題を示す、より具体的なメッセージが表示されます。詳細については、ポリシーファイルのロードエラーの節を参照してください。SWFファイルがそれ自体のドメイン外でソケット接続の確立を試行しましたが、接続を許可する唯一のポリシーファイルは同じホストのHTTPマスターポリシーファイルでした。ソケット接続を許可するHTTPポリシーファイルの構成は、フェーズ1で非推奨となっています。この特定のHTTPポリシーファイルはメタポリシーを宣言しています。つまり、サーバは、HTTPポリシーファイルによってソケット接続が許可されることのない、フェーズ2のルールを選択します。詳細については、厳密なソケットルールの節を参照してください。接続先のホストを管理している場合は、ポート843にソケットマスターポリシーファイルを追加するか、メイン接続のサーバがソケットポリシーファイルも提供するようにしてみてください。これらの処理のいずれも実行できない場合、SWFのホストサーバを通じてソケット接続を委任してください。ソケットポリシーファイルがない場合、ローカルソケット接続による(host) のホストは許可されません。SWFファイルがFlash Playerを実行しているコンピュータに属するIPアドレスへのソケット接続を確立しようとしましたが、この操作を許可するソケットポリシーファイルが見つかりませんでした。厳密なポリシーファイルルールでは、ソケット接続を確立するには、ソケットポリシーファイルの許可が必要です。フェーズ1では、ほとんどのソケット接続の場合、この変更によって単に警告が表示されるだけですが、ローカルIPアドレスへの接続の場合は、フェーズ1でも厳密なルールが有効です。詳細については、「厳密なソケットルールの使用」の節を参照してください。この問題に対処するには、ローカルマシンにソケットポリシーファイルサーバを追加するか、ActionScriptでソケット接続を確立するときに、別の名前を指定するのではなく、ローカルマシンのアドレスを"localhost"として明示的に指定するようにSWFファイルを変更します。したがって、可能な場合は、ローカルソケットポリシーファイルサーバを手配することをお勧めします。
フェーズ1で非推奨となった設定
ドメイン(domain) にはメタポリシーが指定されていません。デフォルトのメタポリシー 'all' を適用しますが、この設定は推奨されていません。0が最初にリリースされた時点では、メタポリシーがそれ以前には存在していなかったため、このメッセージがほとんどすべてのサーバで表示 されます。0)がリリースされるまでにこのサーバがメタポリシーを選択する必要があり、選択しないと、Flashのコンテンツが意図したとおり動作しなくな ることを通知するものです。詳細については、メタポリシーの節を参照してください。
5で禁止された設定
ポリシーファイルがないと、(URL) の SWF はドメイン内のソケットに接続接続できません。SWF ファイルがそれ自体のドメインへのソケット接続を開始しましたが、この操作を許可するポリシーファイルが見つかりませんでした。厳密なポリシーファイルルールでは、ソケット接続を確立するには、SWFファイル自体のドメインに対する接続の場合でも、ソケットポリシーファイルからの 許可が必要です。詳細については、ソケットポリシーファイルの節を参照してください。推奨されるアクションは、ソケットマスターポリシーファイルサーバをポート843に追加することです。ソケットへの接続を許可していますが、この設定は推奨されていません。SWFファイルがソケット接続を開始しましたが、この操作を許可する唯一のポリシーファイルは、ソケットサーバと同じドメインのHTTPポリシーファイルでした。厳密なポリシーファイルルールでは、ソケット接続を確立するには、ソケットポリシーファイルの許可が必要です。ただし、フェーズ1では、ソケット接続を許可するHTTPポリシーファイルの古いシステムが引き続き許可されますが、この警告が表示されます。フェーズ2に移行できるようにするには、ソケット接続と同じホスト名でソケットポリシーファイルサーバを利用できるようにする必要があります。詳細については、ソケットポリシーファイルの節を参照してください。推奨されるアクションは、ソケットマスターポリシーファイルサーバをポート843に追加することです。
プラットフォームの警告
このプラットフォームでは HTTP レスポンスヘッダを使用できません。ポリシーファイルの厳密な規則を適用できません。サーバからのメタポリシー情報は一切利用できなくなります。厳密な影響の一覧と、この動作が予想されるブラウザの設定の一覧については、ブラウザの依存性についての付録を 参照してください。この警告は、以前に動作していたコンテンツが動作しなくなることを示すものではありません。新しい、より厳密なルールを適用できないため、サーバおよび ユーザのセキュリティが低下する可能性があることを示すものです。多くの一般的なブラウザの最新バージョンでは、Flash PlayerがHTTP応答ヘッダを確認できるため、一般に、ブラウザをアップグレードすると、このメッセージは表示されなくなります。
ポリシーファイルの正常なロード
ポリシーファイルが指定したURLから正常にロードされ、すべての有効性チェックに合格し、Flash Playerによって受け入れられました。このポリシーファイルは、SWFファイルでloadPolicyFileを呼び出して明示的に要求することによりロードされたか、Flash Playerのデフォルトのポリシーファイルルールによって自動的に検出された可能性があります。
ポリシーファイルのロード中の警告
(URL) から要求されたポリシーファイルは(URL) にリダイレクトされました。スコープの判断には最終 URL が使用されます。Flash PlayerがHTTPポリシーファイルを要求し、元の要求が同じドメインの別の場所にリダイレクトされました。
リダイレクトについての節に記載されているとおり、バージョン9
0より前のバージョンのFlash Playerでは、リダイレクトされたポリシーファイルを最初に要求したURLから取得したものとして扱っていましたが、バージョン9
0以降のFlash Playerでは、リダイレクトされたポリシーファイルを、リダイレクト後の最終的なURLから取得したものとして扱います。この相違は、これらのポリシーファイルのスコープ、つまりアクセス可能な一連のリソースに影響する可能性があります。この警告が表示された場合は、ログを詳細にチェックして、このポリシーファイルに依存するすべての要求が正常に実行されているかどうかを確認します。要求が正常に実行されていない場合は、元の要求されたURLに、リダイレクトされたものではないポリシーファイルを追加する必要があります。また、別のURLに、リダイレクトされたものではないポリシーファイルを配置することもできます。いずれの場合も、ポリシーファイルのデバッグが困難になる可能性があるため、ポリシーファイル要求のリダイレクトを回避することを検討してください。
ドメイン(domain) にはメタポリシーが明示的に指定されていませんが、Flash Playerが、示されたURLからHTTPポリシーファイルを取得し、HTTPヘッダとこのドメインのマスターポリシーファイルでメタポリシーを探しましたが、メタポリシーが見つかりませんでした。詳細については、メタポリシーの指定の節を参照してください。わかりやすくするために、この暗黙的なメカニズムに依存するのではなく、このサーバがメタポリシーを明示的に宣言することを推奨します。
ソケットポリシーファイルの待機中に(URL) がタイムアウトしました (3 秒間)
Flash Playerがデフォルトで(ポート843または接続を試行したのと同じポートから)ソケットポリシーファイルを要求しましたが、ソケットポリシーファイ ル要求が成功せず、検出可能なエラーも発生しませんでした。これは、サーバが予期しないポリシーファイル要求を受信したか、クライアントとサーバ間のネットワークの問題による可能性があります。Flash Playerがデフォルトでソケットポリシーファイルを要求した場合、サーバリソースの占有または問題のクライアント側への通知の遅延を回避するために、 3秒間だけ応答を待機します。詳細については、ソケットポリシーファイルの 節を参照してください。通常、この警告は次の2つのいずれかを意味します。これにより、限界ネットワーク条件でのアプリケーションの信頼性を確保することができます。このため、デフォルトのソケットポリシーファイルの場所であっても、loadPolicyFileを呼び出して、ソケットポリシーファイルサーバが応答するまでFlash Playerが単に待機するよう要求することは有効と言えます。
ポリシーファイルのロードエラー
ポリシーファイルを(URL) から読み込めませんでした。この問題の原因としては、ネットワークの問題、この場所でサーバが実行されていない、またはサーバが実行されているが、要求された場所が認識されなかった(HTTP 404エラーなど)などが考えられます。構文が正しくないため、(URL) のポリシーファイルは無視されます。Flash Playerが、示されたURLからポリシーファイルを取得しましたが、このポリシーファイルに無効なシンタックスが含まれていました。ポリシーファイルは無視され、一切の操作は許可されません。正しいシンタックスが適用される理由、およびどのような一般的な種類の正しくないシンタックスがこのエラーを発生させるかについての詳細は、不正な形式のポリシーファイルに関する節を参照してください。このポリシーファイルを管理する責任者は、正しくないシンタックスをできるだけ早く修正する必要があります。このサーバを保護するために、このポリシーファイルは無視され、一切の操作は許可されません。このポリシーファイルを管理する責任者は、不適切なContent-Typeをできるだけ早く変更する必要があります。(URL) へのクロスドメインリダイレクトが発生したため、(URL) から要求されたポリシーファイルは無視されます。Flash Playerが、示された最初のURLからポリシーファイルを取得しようとしましたが、別のドメインにある、示された2番目のURLにリダイレクトされました。この処理は禁止されています。このポリシーファイルは無視され、一切の操作は許可されません。示されたメタポリシーは、このファイルをポリシーファイルとして有効にすることを明確に禁止しています。このため、このポリシーファイルは無視され、一切の操作は許可されません。このメッセージ自体は必ずしも問題を示すものではありませんが、このポリシーファイルを有効にしようとする場合は、そのContent-TypeまたはFTPファイル名を変更するか、メタポリシーを変更する必要があります。(URL) のポリシーファイルは無視されます。これは、このHTTP応答はポリシーファイルとして使用することが許可されていないことを示すサーバからの指示です。通常、このヘッダはサーバスクリプトによるポリシーファイルの生成を防止するために使用されます。詳細については、ソケットメタポリシーの節を参照してください。このポリシーファイルは無視され、一切の操作は許可されません。このサーバを管理していて、このポリシーファイルにより操作を許可する必要がある場合は、サーバ設定を変更して、none-this-responseヘッダが生成されないようにする必要があります。(URL) のソケットポリシーファイルは、サイズが大きすぎるため無視されます。ソケットポリシーファイルのサイズは、20 KB 以下であることが必要です。Flash Playerが、示された場所からソケットポリシーファイルを取得するプロセスを開始しましたが、受信するデータが大きすぎてダウンロードが中断されました。このポリシーファイルは無視され、一切の操作は許可されません。この中断はサーバを保護するために行われたものです。Flash Playerはポリシーファイルのサイズが大きいことを想定していないため、サイズの大きなポリシーファイルのダウンロードを中断して、エラー状況と思われるファイルがサーバにロードされないようにします。このファイルが有効なソケットポリシーファイルである場合は、20KB以下になるようにサイズを縮小してみてください。
メタポリシーの誤った設定
このメタポリシーは無視されました。これは、誤った設定であり、サーバ上で修正する必要があります。詳細については、メタポリシーの節を参照してください。
このメタポリシーは無視されましたが、ポリシーファイル自体は必ずしも無視されません(無視される場合は、追加のエラーメッセージが表示されます)
このポリシーファイルの内容を管理する責任者は、有効なメタポリシー名が含まれるように、<site-control>タグを修正する必要があります。詳細については、メタポリシーの節を参照してください。サーバから受信したとおりの、メタポリシーストリング全体が表示されます。Flash Playerは、このストリングで検出された最も厳しいメタポリシーを適用しました。これは、誤った設定であり、サーバ上で修正する必要があります。通常、複数のメタポリシーをHTTP応答ヘッダに指定することは無効です。詳細については、メタポリシーの節を参照してください。Flash Playerはこのサーバから検出された最も厳しいメタポリシーを適用しましたが、比較的厳しくないメタポリシーが最初に見つかった場合は、後で矛盾が見つかるまで、この比較的厳しくないメタポリシーが有効になります。これは、誤った設定であり、サーバ上で修正する必要があります。詳細については、メタポリシーの節を参照してください。上記のエラーに似ていますが、HTTPヘッダではなく<site-control>タグで競合するメタポリシーファイルが見つかりました。このタグは、マスターポリシーファイルでのみ使用できます。示されたURLからのポリシーファイル内に<site-control>タグを見つかりましたが、このポリシーファイルはマスターポリシーファイルではありませんでした。
この<site-control>タグは無視されましたが、ポリシーファイル自体は必ずしも無視されません(無視される場合は、追加のエラーメッセージが表示されます)
xml、 またはポート843からのソケットポリシーファイル)内のみです。このサーバを管理する責任者は、このポリシーファイルから<site-control>タグを削除し、このサーバが他の方法(マスターポリシーファイルまたはHTTP応答ヘッダ)で有効なメタポリシーを宣言していることを確認します。詳細については、メタポリシーの節を参照してください。
この<site-control>タグは無視されましたが、ポリシーファイル自体は必ずしも無視されません(無視される場合は、追加のエラーメッセージが表示されます)
このサーバを管理する責任者は、このサーバの有効なメタポリシーを選択する必要があります。詳細については、メタポリシーの節を参照してください。このサーバを管理する責任者は、このサーバの有効なメタポリシーを選択する必要があります。詳細については、メタポリシーの節を参照してください。
この<site-control>タグは無視されましたが、ポリシーファイル自体は必ずしも無視されません(無視される場合は、追加のエラーメッセージが表示されます)
これは、HTTPサーバが、サーバスクリプトによるポリシーファイルの生成を防止するためのメカニズムとしてのみ使用されます。このサーバを管理する責任者は、このサーバの有効なメタポリシーを選択する必要があります。詳細については、メタポリシーの節を参照してください。宣言されたメタポリシーnoneが、このサーバに対して適用されます。つまり、このサーバでは、ポリシーファイル(マスターポリシーファイル自体を含む)は許可されません。マスターポリシーファイルは、メタポリシーを宣言する目的でのみ存在することが許可されます。マスターポリシーファイルには<allow-access-from>ディレクティブが含まれているため、これらのディレクティブは無視されます。詳細については、メタポリシーの節を参照してください。
ポリシーファイルの誤った設定
このルールは、最初にポリシーファイルが導入されたときから適用されています。このサーバを管理する責任者は、このポリシーファイルからsecure属性を削除する必要があります。ホスト(host) はローカルコンピュータを参照していないようです。安全でない可能性があります。secure属性は指定されたとおりに適用されますが、このソケットポリシーファイルが実際にはローカルマシン以外の場所から提供されたものである場合は、セキュリティで保護されていない設定が使用されている可能性があります。これは、man-in-the-middle攻撃によって別のポリシーファイルに置き換えられる可能性のあるネットワーク伝送がないためです。Flash Playerでは、セキュリティで保護されたチャネルを介してソケットポリシーファイルを取得する方法がまだ用意されていません。詳細については、ソケットポリシーファイルの節を参照してください。
ポリシーファイルの解析エラー
このストリングは有効なドメインとして認識されませんでした。この特定の<allow-access-from>ディレクティブは無視されますが、同じポリシーファイル内の他のディレクティブは有効となり、受け入れられる可能性があります。このポリシーファイルを管理する責任者は、この無効なドメインを修正する必要があります。このストリングは有効なポート範囲として認識されませんでした。ポート範囲には、ワイルドカード*、個別のポート番号、ダッシュで区切られたポート範囲、または個別の番号および範囲のカンマ区切りのリストを含めることができます。この特定の<allow-access-from>ディレクティブは無視されますが、同じポリシーファイル内の他のディレクティブは有効となり、受け入れられる可能性があります。このポリシーファイルを管理する責任者は、この無効なポート範囲を修正する必要があります。
お問い合わせ
不正コピー防止について
著作権と商標について*
当Webサイトをご利用のお客様は、利用条件およびプライバシーポリシー(2009年7月14日更新)にご同意いただいたものとみなされます。
記事のアーカイブ*
ユーザグループの検索*
ユーザグループについて*
フルスクリーンモード用のHTML
パブリッシュとテスト
印刷用に表示
ブロードバンドの普及により、Webにおけるビデオの使用は驚異的に伸びました。4%)が、ビデオをオンラインでストリームしたことがあるそうです。この傾向を推進するFlashビデオは、新しい種類の統合インタラクティブビデオコンテンツとアプリケーションを配信し、Webでビデオの新しいビジネスモデルを実現するために使用されています。現在のFlash PlayerとFlashビデオでも「没頭できる」ビデオ体験が可能ですが、ビデオを投稿している多くの人々が視聴者に提供したいと願う完全没入型の体験を提供できるまでには至っていません。この没入感をさらに高め、視聴者がブラウザのフレームを超えてコンピュータの全画面にコンテンツを表示できるようにするために、Adobe Flash Player 9のフルスクリーンモードを活用することができます。フルスクリーンモードはあらゆる種類のFlashアプリケーションで使用することが可能ですが、この初期実装でFlash Playerチームが力を入れた主な用途はFlashビデオアプリケーションでした。したがって、フルスクリーンモードには多くのセキュリティ上の制約(詳細は次のセクションで説明)があり、そのために完全にインタラクティブなFlashアプリケーション、またはゲームの利点が制限されることがあります。これらの制限については、Flash Playerの今後のバージョンでこの機能の開発を続けながら対応していきたいと思います。
フルスクリーンモードの仕組み
フルスクリーンモードは、以前のバージョンのFlashスタンドアローンプレイヤーとプロジェクタですでにサポートされており、その実装は変更されていません。Flash Playerの最新バージョンをインストールしている場合は、ステージのどの部分を画面全体に表示するかを指定することもできます。フルスクリーンモードに移行する前にfullScreenRectに値を割り当てると、ハードウェアスケーリングによってビデオを表示できるようになり、ビデオの再生パフォーマンスをさらに向上することができます。ただし、ハードウェアスケーリングで表示するには、ユーザのビデオカードの機能を使用する必要があるため、ビデオカードでこの機能がサポートされていない場合は、元のソフトウェア描画によるフルスクリーン表示が使用されます。また、ユーザの選択により、ハードウェアスケーリングをオフにして、元のソフトウェア描画によるフルスクリーンモードで表示することもできます。フルスクリーンモードは、wmodeがウィンドウなしの不透明、または透明の場合にはサポートされていませんでしたが、Flash Playerの最新バージョンからはサポートされるようになりました。ユーザが複数のモニタを持っている場合、Flash Playerはメトリックを使用してFlashムービーの割合が一番大きいモニタを判別し、このメインモニタをフルスクリーンモード用に使用します。0以上をインストールしている必要があります。エンドユーザのセキュリティはこの機能を実装する際の重要な考慮事項です。そのため、開発者は次のエンドユーザ、およびセキュリティ関連の制限とデザインコンテンツを理解している必要があります。このパラメータのデフォルト値はfalseで、フルスクリーンは使用できません。ムービーがフルスクリーンモードに移行すると、このモードの終了および通常モードへの復帰の方法を指示するオーバーレイダイアログボックスが表示されます。ダイアログボックスは数秒間表示された後、消えます。フルスクリーンモードを開始するActionScriptは、マウスクリックまたはキー入力への応答としてのみ呼び出すことができます。ユーザーは、フルスクリーンモードの間はテキスト入力フィールドにテキストを入力できません。フルスクリーンモードでは、視聴者がフルスクリーンモードを終了するためのキーボードショートカットを除き、キーボード入力やキー関連のActionScriptはすべて無効になります。cfgに設定を追加することによって、すべてのFlashムービーでフルスクリーンモードを無効にすることができます。cfgファイルに追加して、フルスクリーンモードを無効にします。これらの制限はFlashプラグインとActiveXコントロールに適用されますが、FlashスタンドアローンプレイヤーやFlashプロジェクタには適用されません。このチュートリアルを完了するには、次のソフトウェアおよびファイルがインストールされている必要があります。264をサポートする新しいビデオ再生コンポーネントを含むアップデートをご用意しています。
著者について
また、カマキリカンフー(螳螂拳)の武芸者で、数学修士号も持っているので、彼女に盾突いたら大変です。
お問い合わせ
不正コピー防止について
著作権と商標について*
当Webサイトをご利用のお客様は、利用条件およびプライバシーポリシー(2009年7月14日更新)にご同意いただいたものとみなされます。
記事のアーカイブ*
ユーザグループの検索*
ユーザグループについて*
フルスクリーンモード用のHTML
パブリッシュとテスト
フルスクリーンモードを開始または終了するための新しいActionScriptメソッド、およびフルスクリーンモードが開始または終了したときにムービーを通知する対応イベントが、ActionScript 2
0に追加されました。前述したとおり、フルスクリーンモードを開始するActionScriptは、マウスクリック、またはキー入力に反応する形でのみ動作します。このプロパティは取得と設定が可能です。有効な値は次のとおりです。このプロパティは、ムービーの現在の状態をチェックしたり、フルスクリーンモードを開始または終了したりするのに使用されます。Stageオブジェクトのイベントリスナーは、ムービーがフルスクリーンモードを開始または終了するときに通知を行います。このメソッドは、ムービーがフルスクリーンモードを開始または終了するときに呼び出されます。この関数に対するブール値引数は、ムービーがフルスクリーンモードを開始した(true)か、終了した(false)かを示します。このプロパティを使用すると、ステージのどの部分を画面全体に表示するかを指定できます。このプロパティを指定すると、ハードウェアスケーリングモードも有効になります。このプロパティは、ステージ内外のどこにでも設定できる矩形です。フルスクリーンモードに移行する前に指定する必要があります。また、指定した矩形の縦横比がユーザのモニターの縦横比と異なっている場合は、必要に応じて両脇に「バー」が追加されます。このバーの色は、そのSWFの背景色、またはHTMLで設定されたSWFの背景色と同じです。このプロパティは取得と設定が可能です。このプロパティは、ムービーの現在の状態をチェックしたり、フルスクリーンモードを開始または終了したりするのに使用されます。Stageオブジェクトのイベントリスナーは、ムービーがフルスクリーンモードを開始または終了するときに通知を行います。このプロパティは、ムービーがフルスクリーンモードを開始した(true)か、終了した(false)かを示します。このプロパティを使用すると、ステージのどの部分を画面全体に表示するかを指定できます。このプロパティを指定すると、ハードウェアスケーリングモードも有効になります。このプロパティは、ステージ内外のどこにでも設定できる矩形です。フルスクリーンモードに移行する前に指定する必要があります。また、指定した矩形の縦横比がユーザのモニターの縦横比と異なっている場合は、必要に応じて両脇に「バー」が追加されます。このバーの色は、そのSWFの背景色、またはHTMLで設定されたSWFの背景色と同じです。何もする必要はありません。0クラスファイルに新しいActionScriptプロパティが含まれているので、エラーは発生しません。以前のバージョンのFlashとしてパブリッシュする場合は、多少不恰好な構文を使用することができます。ただし、次の構文の方が簡単です。ソフトウェア描画によるフルスクリーンモードの拡大/縮小動作は、ムービーのscaleMode設定によって決定されます。この設定ではフルスクリーンモードでムービーが画面のサイズに拡大されますが、その縦横比は維持されます。この場合、ムービーは拡大されませんが、ステージの幅と高さのプロパティがフルスクリーンモードで新しいステージサイズを示すように更新され、ステージのサイズ変更イベントハンドラが呼び出されます。fullScreenSourceRectを指定してハードウェアスケーリングによるフルスクリーンモードを使用している場合は、SWFの拡大/縮小によってフルスクリーンモードの機能が影響を受けることはありません。
お問い合わせ
不正コピー防止について
著作権と商標について*
当Webサイトをご利用のお客様は、利用条件およびプライバシーポリシー(2009年7月14日更新)にご同意いただいたものとみなされます。
記事のアーカイブ*
ユーザグループの検索*
ユーザグループについて*
ブロードバンドの普及により、Webにおけるビデオの使用は驚異的に伸びました。4%)が、ビデオをオンラインでストリームしたことがあるそうです。この傾向を推進するFlashビデオは、新しい種類の統合インタラクティブビデオコンテンツとアプリケーションを配信し、Webでビデオの新しいビジネスモデルを実現するために使用されています。現在のFlash PlayerとFlashビデオでも「没頭できる」ビデオ体験が可能ですが、ビデオを投稿している多くの人々が視聴者に提供したいと願う完全没入型の体験を提供できるまでには至っていません。この没入感をさらに高め、視聴者がブラウザのフレームを超えてコンピュータの全画面にコンテンツを表示できるようにするために、Adobe Flash Player 9のフルスクリーンモードを活用することができます。フルスクリーンモードはあらゆる種類のFlashアプリケーションで使用することが可能ですが、この初期実装でFlash Playerチームが力を入れた主な用途はFlashビデオアプリケーションでした。したがって、フルスクリーンモードには多くのセキュリティ上の制約(詳細は次のセクションで説明)があり、そのために完全にインタラクティブなFlashアプリケーション、またはゲームの利点が制限されることがあります。これらの制限については、Flash Playerの今後のバージョンでこの機能の開発を続けながら対応していきたいと思います。
フルスクリーンモードの仕組み
フルスクリーンモードは、以前のバージョンのFlashスタンドアローンプレイヤーとプロジェクタですでにサポートされており、その実装は変更されていません。Flash Playerの最新バージョンをインストールしている場合は、ステージのどの部分を画面全体に表示するかを指定することもできます。フルスクリーンモードに移行する前にfullScreenRectに値を割り当てると、ハードウェアスケーリングによってビデオを表示できるようになり、ビデオの再生パフォーマンスをさらに向上することができます。ただし、ハードウェアスケーリングで表示するには、ユーザのビデオカードの機能を使用する必要があるため、ビデオカードでこの機能がサポートされていない場合は、元のソフトウェア描画によるフルスクリーン表示が使用されます。また、ユーザの選択により、ハードウェアスケーリングをオフにして、元のソフトウェア描画によるフルスクリーンモードで表示することもできます。フルスクリーンモードは、wmodeがウィンドウなしの不透明、または透明の場合にはサポートされていませんでしたが、Flash Playerの最新バージョンからはサポートされるようになりました。ユーザが複数のモニタを持っている場合、Flash Playerはメトリックを使用してFlashムービーの割合が一番大きいモニタを判別し、このメインモニタをフルスクリーンモード用に使用します。0以上をインストールしている必要があります。エンドユーザのセキュリティはこの機能を実装する際の重要な考慮事項です。そのため、開発者は次のエンドユーザ、およびセキュリティ関連の制限とデザインコンテンツを理解している必要があります。このパラメータのデフォルト値はfalseで、フルスクリーンは使用できません。ムービーがフルスクリーンモードに移行すると、このモードの終了および通常モードへの復帰の方法を指示するオーバーレイダイアログボックスが表示されます。ダイアログボックスは数秒間表示された後、消えます。フルスクリーンモードを開始するActionScriptは、マウスクリックまたはキー入力への応答としてのみ呼び出すことができます。ユーザーは、フルスクリーンモードの間はテキスト入力フィールドにテキストを入力できません。フルスクリーンモードでは、視聴者がフルスクリーンモードを終了するためのキーボードショートカットを除き、キーボード入力やキー関連のActionScriptはすべて無効になります。cfgに設定を追加することによって、すべてのFlashムービーでフルスクリーンモードを無効にすることができます。cfgファイルに追加して、フルスクリーンモードを無効にします。これらの制限はFlashプラグインとActiveXコントロールに適用されますが、FlashスタンドアローンプレイヤーやFlashプロジェクタには適用されません。このチュートリアルを完了するには、次のソフトウェアおよびファイルがインストールされている必要があります。264をサポートする新しいビデオ再生コンポーネントを含むアップデートをご用意しています。
フルスクリーンモードを開始または終了するための新しいActionScriptメソッド、およびフルスクリーンモードが開始または終了したときにムービーを通知する対応イベントが、ActionScript 2
0に追加されました。前述したとおり、フルスクリーンモードを開始するActionScriptは、マウスクリック、またはキー入力に反応する形でのみ動作します。このプロパティは取得と設定が可能です。有効な値は次のとおりです。このプロパティは、ムービーの現在の状態をチェックしたり、フルスクリーンモードを開始または終了したりするのに使用されます。Stageオブジェクトのイベントリスナーは、ムービーがフルスクリーンモードを開始または終了するときに通知を行います。このメソッドは、ムービーがフルスクリーンモードを開始または終了するときに呼び出されます。この関数に対するブール値引数は、ムービーがフルスクリーンモードを開始した(true)か、終了した(false)かを示します。このプロパティを使用すると、ステージのどの部分を画面全体に表示するかを指定できます。このプロパティを指定すると、ハードウェアスケーリングモードも有効になります。このプロパティは、ステージ内外のどこにでも設定できる矩形です。フルスクリーンモードに移行する前に指定する必要があります。また、指定した矩形の縦横比がユーザのモニターの縦横比と異なっている場合は、必要に応じて両脇に「バー」が追加されます。このバーの色は、そのSWFの背景色、またはHTMLで設定されたSWFの背景色と同じです。このプロパティは取得と設定が可能です。このプロパティは、ムービーの現在の状態をチェックしたり、フルスクリーンモードを開始または終了したりするのに使用されます。Stageオブジェクトのイベントリスナーは、ムービーがフルスクリーンモードを開始または終了するときに通知を行います。このプロパティは、ムービーがフルスクリーンモードを開始した(true)か、終了した(false)かを示します。このプロパティを使用すると、ステージのどの部分を画面全体に表示するかを指定できます。このプロパティを指定すると、ハードウェアスケーリングモードも有効になります。このプロパティは、ステージ内外のどこにでも設定できる矩形です。フルスクリーンモードに移行する前に指定する必要があります。また、指定した矩形の縦横比がユーザのモニターの縦横比と異なっている場合は、必要に応じて両脇に「バー」が追加されます。このバーの色は、そのSWFの背景色、またはHTMLで設定されたSWFの背景色と同じです。何もする必要はありません。0クラスファイルに新しいActionScriptプロパティが含まれているので、エラーは発生しません。以前のバージョンのFlashとしてパブリッシュする場合は、多少不恰好な構文を使用することができます。ただし、次の構文の方が簡単です。ソフトウェア描画によるフルスクリーンモードの拡大/縮小動作は、ムービーのscaleMode設定によって決定されます。この設定ではフルスクリーンモードでムービーが画面のサイズに拡大されますが、その縦横比は維持されます。この場合、ムービーは拡大されませんが、ステージの幅と高さのプロパティがフルスクリーンモードで新しいステージサイズを示すように更新され、ステージのサイズ変更イベントハンドラが呼び出されます。fullScreenSourceRectを指定してハードウェアスケーリングによるフルスクリーンモードを使用している場合は、SWFの拡大/縮小によってフルスクリーンモードの機能が影響を受けることはありません。新しいフルスクリーンモードのActionScriptの使用例として、Flashムービーのフルスクリーンモードを切り替えることができるアイテムを含んでいるカスタムコンテキストメニューの追加方法を紹介します。
フルスクリーンモード用のHTML
Flashでのテンプレートのパブリッシュ
フルスクリーンモードで新しい<object>タグパラメータと<embed>タグパラメータをサポートするために、新しいパブリッシュテンプレートを作成しました。これは基本となる「Flashのみ」のテンプレートのバージョンですが、フルスクリーンモードを使用できるようにするために、適切なタグもHTMLに追加します。パブリッシュ設定ダイアログボックスの「HTML」タブで、テンプレートポップアップメニューから「Flash のみ - フルスクリーンサポート」を選択してムービーをパブリッシュします。サンプルのZIPアーカイブをダウンロードして解凍し、新しいテンプレートを入手します。これらのテンプレートをFlex Builderプロジェクトで使用するには、次の手順を実行します。
パブリッシュとテスト
ムービーをパブリッシュしてテストします。次の手順を忘れずに実行してください。最新バージョンのFlashプラグインまたはActiveX コントロールがあることを確認します。フルスクリーンモードを使用するには、バージョン 9,0,28,0以降がインストールされている必要があります。ブラウザにテストムービーをロードします。ムービー、またはムービークリップを右クリックしてカスタムコンテキストメニューを表示すると、フルスクリーンモードを開始する、または終了する項目が表示されます。コンテキストメニューを使用してフルスクリーンモードに切り替えた場合は、コンテキストメニューを使用するか、キーボードのEscキーを押すか、フォーカスを別のウィンドウに切り替えることによってフルスクリーンモードを終了できます。
次のステップ
新しいフルスクリーン機能を使用して作成したデモをコミュニティで共有する場合は、Full-Screen Demosページにデモのリンクを追加してください。
著者について
また、カマキリカンフー(螳螂拳)の武芸者で、数学修士号も持っているので、彼女に盾突いたら大変です。
お問い合わせ
不正コピー防止について
著作権と商標について*
当Webサイトをご利用のお客様は、利用規約およびプライバシーポリシー(2009年7月14日更新)にご同意いただいたものとみなされます。
264ビデオおよびAACオーディオのサポートについての説明 | デベロッパーセンター
記事のアーカイブ*
ユーザグループの検索*
ユーザグループについて*
264ビデオとM4Aオーディオの読み込み
MPEG-4ファイルからのメタデータの抽出
フルスクリーンビデオでのハードウェアスケーリングの使用
印刷用に表示
264ビデオおよびAACオーディオのサポートについての説明
ビデオ改革は次なる重要な段階を迎えようとしています。264エンコードを採用したビデオ用の業界標準で、高解像度(HD)配信を行うことができます。これはまた、オンラインおよび家庭用テレビなどのデバイスのHDコンテンツ用の標準でもあります。
優れた表示能力を備えたH
ユーザはこれらのコーデックを使用して、低ビットレートで高品質のビデオをストリーミングできます。264コンテンツのエンドツーエンドの開発および配布の機能が強化される予定です。今後の展開に対しては、非常に期待が持てるように思われます。264、HE-AACおよび暗号化されたビデオコンテンツもサポートします。そのようなことはありません。264が追加されることにより、開発者はニーズを最も満たすテクノロジの選択肢が増えることになります。264の現在の実装には、アルファチャンネルに対するサポートがない、SWFファイルにビデオを埋め込むことができないなど、いくつかの制限があります。On2 VP6は、Flashベースのビデオプロジェクトに対しては確実で高品質な選択肢になります。On2 VP6コーデックは、メディアの配信用として今でも一貫性のある有用なオプションです。264のサポートの追加は、高品質でHD対応のビデオに対するオプションが増え、広範囲な互換性が備えられたことを意味しています。このチュートリアルを完了するには、次のソフトウェアおよびファイルがインストールされている必要があります。264をサポートする新しいビデオ再生コンポーネントを含むアップデートをご用意しています。264ビデオプレーヤーおよびMP4プレーヤーを作成するためのサンプルファイルが含まれています。ビデオとオーディオのサンプルファイルに加え、この記事のそれぞれのチュートリアル用のFLAファイルがあります。0のサンプルファイルも用意されています。
この記事に必要な予備知識
Flashの操作およびマルチメディアの開発に関する一般的な経験を持っていることをお勧めしますが、高解像度ビデオとオーディオの表示についての概要およびFlash Player 9 Update 3での最適化および再生に関する技術に興味をお持ちの方もこの記事の対象となります。
著者について
同社はコロラド州に本社を置くデジタルメディア企業で、インタラクティブモーションメディアや高度なFlashおよびFlexプラットフォームアプリケーションに注力しています。David氏は常にモーションメディアやビデオの持つ力に情熱を注ぎ、使いやすさと双方向性の課題の解決に取り組んでいます。David氏はアドビ認定のマスターインストラクターで、デンバー大学で上級RIAクラスの授業を受け持っています。また、Rocky Mountainアドビユーザグループのマネージャーも務めているほか、FlashおよびFlexアプリケーション上級コースの講師とコース設計も兼務しています。David氏は、コードや技術的なベストプラクティスに関する高度なレビューを定期的に実施しています。また、過去数年間にわたり、Macromedia、アドビ、およびそのクライアントの業界エキスパートとして、世界中の業界リーダーに対し、技術レビュー、コースウェアレビュー、アプリケーションレビューなどの方向性に関するアドバイスを提供しています。
お問い合わせ
不正コピー防止について
著作権と商標について*
当Webサイトをご利用のお客様は、利用条件およびプライバシーポリシー(2009年7月14日更新)にご同意いただいたものとみなされます。
264ビデオおよびAACオーディオのサポートについての説明 | デベロッパーセンター
記事のアーカイブ*
ユーザグループの検索*
ユーザグループについて*
264ビデオとM4Aオーディオの読み込み
MPEG-4ファイルからのメタデータの抽出
フルスクリーンビデオでのハードウェアスケーリングの使用
264ビデオおよびAACオーディオのサポートについての説明
264で技術的にサポートされる機能、標準のHDビデオサイズ、H
264のコンテナ形式とその説明、AAC/AAC+で提供される機能の基本的な情報に加えて、いくつかの基本的なエンコードリソースについて説明します。264は、国際標準化機構(ISO)によって認められたビデオ圧縮の国際標準です。
これは何を意味するのでしょうか
まず、これは、ビデオをH
Flash Playerでの新しいハードウェアスケーリングおよびマルチスレッドのサポートによって、システムがサポートしている限り、HD 1080pを含む任意の解像度とビットレートでビデオを再生できます(図1を参照)
現在のビデオ標準で使用できる画面の解像度およびビットレート
MPEG-4標準は、コンテナ形式も規定しています。これは、複数の異なるタイプのデータをトラックとして格納し、1つのファイルに含めることができることを意味します。ファイル全体が同期され、データがインターリーブされます。そのため、MPEG-4コンテナ内のビデオまたはオーディオには、メタデータ、カバーアート、字幕およびFlash Playerで抽出できるその他のテキストまたはビジュアルデータを添付することもできます。また、複数のビデオトラックやオーディオトラックをコンテナに含めることもできますが、現在のところFlash Playerは1つのトラックのみを再生し、他のトラックは無視します。iTunesから販売されるすべての楽曲にAACが使用されているので、このコーデックは多くの人々に知られています。最高96KHzのキャプチャ、最高48チャンネルおよび逆方向予測がサポートされるので、技術に精通しているユーザは、より高い品質を実現できます。AACではMP3より高いオーディオ品質が達成される一方で、ファイルサイズは同等か小さくなります。AAC+またはHE-AAC(High Efficiency AAC)は、パラメトリックステレオとスペクトル帯域複製により、ストリーミングオーディオなどの用途に対して低いビットレートで高品質のオーディオが提供されるように最適化されているAACコーデックです。264導入の一環として、市場のソリューションが数多く利用されています。新しいFlash Player 9 Update 3でサポートされる形式のビデオのエンコーディングに対応する、業界標準のツールを提供している企業の一部を次に示します。
サポートされるファイル形式
ただし、iTunesからダウンロードしたファイルやFairPlay*でデジタル暗号化されたファイルなど、保護されたMP4ファイルはサポートされません。
お問い合わせ
不正コピー防止について
著作権と商標について*
当Webサイトをご利用のお客様は、利用規約およびプライバシーポリシー(2009年7月14日更新)にご同意いただいたものとみなされます。
264ビデオおよびAACオーディオのサポートについての説明 | デベロッパーセンター
記事のアーカイブ*
ユーザグループの検索*
ユーザグループについて*
264ビデオとM4Aオーディオの読み込み
MPEG-4ファイルからのメタデータの抽出
フルスクリーンビデオでのハードウェアスケーリングの使用
264ビデオおよびAACオーディオのサポートについての説明
264ビデオとM4Aオーディオの読み込み
264コンテンツの再生
264コンテンツの再生にかかる時間はほとんど変わりません。ただし、いくつかのサポートされないコンテンツに関するメッセージに注意する必要があります。
また、ファイル拡張子を
264ビデオファイルを再生することもできます。
現在のビデオコンポーネントは、再生対象として拡張子が
flvのファイルを探しますが、アドビは仕様を変更する作業を進めており、将来のアップデートでは拡張子の変更は不要になります。プログレッシブダウンロードを使用してビデオを再生する従来の方法は次のとおりです。flaという名前を付けてファイルを保存します。
0ファイルの作成
コードの先頭でビデオ変数を宣言します。0では、NetStreamにクライアントオブジェクトを指定して、ストリームイベントを処理する必要があります。指定しないと、コンパイルエラーが発生します。ハンドラメソッドを実際に作成する必要はありませんが、クライアントオブジェクトは必要です。タイムラインでNetStreamのイベントを処理できるように、クライアントオブジェクトをthisに設定します。NetStreamビデオをビデオオブジェクトに関連付ける前にこのコードを追加します。次に、イベントリスナーを作成します。if条件式の内部で、trace()メソッドを使用して、ファイル構造が無効であることを示すストリングを出力します。else条件の内部で、trace()メソッドを使用して、サポートされるトラックがMP4に含まれていないことを示すストリングを出力します。このイベントハンドラをNetStreamオブジェクトに関連付けます。イベントハンドラを追加した行の下で、ビデオをダイナミックに作成します。264ビデオファイルをプログレッシブダウンロードとして再生する場合に重要なのは、moov atomをファイルの先頭に配置することです。このように配置しないと、ファイル全体をダウンロードしてから再生を開始する必要があります。moov atomは、ファイル全体のインデックス情報を保持しているファイルの一部です。
ただし、これはH
NetStreamオブジェクトだけを使用してファイルを再生します。flaという名前を付けてファイルを保存します。完成したコードは、次のようになります。ブラウザでムービーをテストします。オーディオの再生が開始されます。Soundオブジェクトを使用してM4Aオーディオを制御する方法は少し複雑です。Soundオブジェクトは、MP3ファイルの場合と同じ方法でM4Aファイルをロードすることはできません。そのため、NetStreamを使用してファイルを取り込み、そこでファイルを操作する必要があります。flaファイルを開きます。ブラウザでムービーをテストします。元の約半分の音量レベルで、オーディオの再生が開始されます。
264ファイルの制御
0では、Soundオブジェクトが変更されてサウンドをビデオに添付できなくなったので、ビデオのオーディオの制御にSoundオブジェクトは使用できません。手順は次のとおりです。flaファイルを開きます。通常は、ここで宣言は行いません。
264コンテンツの再生
手順は次のとおりです。コンストラクタの前で、次のようにいくつかの変数を宣言します。処理は不要ですが、クライアントオブジェクトを作成する必要があります。また、NetStreamからステータスイベントを処理するコード行も追加します。完成したメソッドは、次のようになります。ステータスイベントを処理する関数を作成します。
具体的には、H
264ビデオを追跡できる次の2つの新しいステータスイベントを処理します。ファイルを保存します。
お問い合わせ
不正コピー防止について
著作権と商標について*
当Webサイトをご利用のお客様は、利用規約およびプライバシーポリシー(2009年7月14日更新)にご同意いただいたものとみなされます。
264ビデオおよびAACオーディオのサポートについての説明 | デベロッパーセンター
記事のアーカイブ*
ユーザグループの検索*
ユーザグループについて*
264ビデオおよびAACオーディオのサポートについての説明
ビデオ改革は次なる重要な段階を迎えようとしています。264エンコードを採用したビデオ用の業界標準で、高解像度(HD)配信を行うことができます。これはまた、オンラインおよび家庭用テレビなどのデバイスのHDコンテンツ用の標準でもあります。
優れた表示能力を備えたH
ユーザはこれらのコーデックを使用して、低ビットレートで高品質のビデオをストリーミングできます。264コンテンツのエンドツーエンドの開発および配布の機能が強化される予定です。今後の展開に対しては、非常に期待が持てるように思われます。264、HE-AACおよび暗号化されたビデオコンテンツもサポートします。そのようなことはありません。264が追加されることにより、開発者はニーズを最も満たすテクノロジの選択肢が増えることになります。264の現在の実装には、アルファチャンネルに対するサポートがない、SWFファイルにビデオを埋め込むことができないなど、いくつかの制限があります。On2 VP6は、Flashベースのビデオプロジェクトに対しては確実で高品質な選択肢になります。On2 VP6コーデックは、メディアの配信用として今でも一貫性のある有用なオプションです。264のサポートの追加は、高品質でHD対応のビデオに対するオプションが増え、広範囲な互換性が備えられたことを意味しています。このチュートリアルを完了するには、次のソフトウェアおよびファイルがインストールされている必要があります。264をサポートする新しいビデオ再生コンポーネントを含むアップデートをご用意しています。264ビデオプレーヤーおよびMP4プレーヤーを作成するためのサンプルファイルが含まれています。ビデオとオーディオのサンプルファイルに加え、この記事のそれぞれのチュートリアル用のFLAファイルがあります。0のサンプルファイルも用意されています。
この記事に必要な予備知識
Flashの操作およびマルチメディアの開発に関する一般的な経験を持っていることをお勧めしますが、高解像度ビデオとオーディオの表示についての概要およびFlash Player 9 Update 3での最適化および再生に関する技術に興味をお持ちの方もこの記事の対象となります。
264で技術的にサポートされる機能、標準のHDビデオサイズ、H
264のコンテナ形式とその説明、AAC/AAC+で提供される機能の基本的な情報に加えて、いくつかの基本的なエンコードリソースについて説明します。264は、国際標準化機構(ISO)によって認められたビデオ圧縮の国際標準です。
これは何を意味するのでしょうか
まず、これは、ビデオをH
Flash Playerでの新しいハードウェアスケーリングおよびマルチスレッドのサポートによって、システムがサポートしている限り、HD 1080pを含む任意の解像度とビットレートでビデオを再生できます(図1を参照)
現在のビデオ標準で使用できる画面の解像度およびビットレート
MPEG-4標準は、コンテナ形式も規定しています。これは、複数の異なるタイプのデータをトラックとして格納し、1つのファイルに含めることができることを意味します。ファイル全体が同期され、データがインターリーブされます。そのため、MPEG-4コンテナ内のビデオまたはオーディオには、メタデータ、カバーアート、字幕およびFlash Playerで抽出できるその他のテキストまたはビジュアルデータを添付することもできます。また、複数のビデオトラックやオーディオトラックをコンテナに含めることもできますが、現在のところFlash Playerは1つのトラックのみを再生し、他のトラックは無視します。iTunesから販売されるすべての楽曲にAACが使用されているので、このコーデックは多くの人々に知られています。最高96KHzのキャプチャ、最高48チャンネルおよび逆方向予測がサポートされるので、技術に精通しているユーザは、より高い品質を実現できます。AACではMP3より高いオーディオ品質が達成される一方で、ファイルサイズは同等か小さくなります。AAC+またはHE-AAC(High Efficiency AAC)は、パラメトリックステレオとスペクトル帯域複製により、ストリーミングオーディオなどの用途に対して低いビットレートで高品質のオーディオが提供されるように最適化されているAACコーデックです。264導入の一環として、市場のソリューションが数多く利用されています。新しいFlash Player 9 Update 3でサポートされる形式のビデオのエンコーディングに対応する、業界標準のツールを提供している企業の一部を次に示します。
サポートされるファイル形式
ただし、iTunesからダウンロードしたファイルやFairPlay*でデジタル暗号化されたファイルなど、保護されたMP4ファイルはサポートされません。
264ビデオとM4Aオーディオの読み込み
264コンテンツの再生
264コンテンツの再生にかかる時間はほとんど変わりません。ただし、いくつかのサポートされないコンテンツに関するメッセージに注意する必要があります。
また、ファイル拡張子を
264ビデオファイルを再生することもできます。
現在のビデオコンポーネントは、再生対象として拡張子が
flvのファイルを探しますが、アドビは仕様を変更する作業を進めており、将来のアップデートでは拡張子の変更は不要になります。プログレッシブダウンロードを使用してビデオを再生する従来の方法は次のとおりです。flaという名前を付けてファイルを保存します。
0ファイルの作成
コードの先頭でビデオ変数を宣言します。0では、NetStreamにクライアントオブジェクトを指定して、ストリームイベントを処理する必要があります。指定しないと、コンパイルエラーが発生します。ハンドラメソッドを実際に作成する必要はありませんが、クライアントオブジェクトは必要です。タイムラインでNetStreamのイベントを処理できるように、クライアントオブジェクトをthisに設定します。NetStreamビデオをビデオオブジェクトに関連付ける前にこのコードを追加します。次に、イベントリスナーを作成します。if条件式の内部で、trace()メソッドを使用して、ファイル構造が無効であることを示すストリングを出力します。else条件の内部で、trace()メソッドを使用して、サポートされるトラックがMP4に含まれていないことを示すストリングを出力します。このイベントハンドラをNetStreamオブジェクトに関連付けます。イベントハンドラを追加した行の下で、ビデオをダイナミックに作成します。264ビデオファイルをプログレッシブダウンロードとして再生する場合に重要なのは、moov atomをファイルの先頭に配置することです。このように配置しないと、ファイル全体をダウンロードしてから再生を開始する必要があります。moov atomは、ファイル全体のインデックス情報を保持しているファイルの一部です。
ただし、これはH
NetStreamオブジェクトだけを使用してファイルを再生します。flaという名前を付けてファイルを保存します。完成したコードは、次のようになります。ブラウザでムービーをテストします。オーディオの再生が開始されます。Soundオブジェクトを使用してM4Aオーディオを制御する方法は少し複雑です。Soundオブジェクトは、MP3ファイルの場合と同じ方法でM4Aファイルをロードすることはできません。そのため、NetStreamを使用してファイルを取り込み、そこでファイルを操作する必要があります。flaファイルを開きます。ブラウザでムービーをテストします。元の約半分の音量レベルで、オーディオの再生が開始されます。
264ファイルの制御
0では、Soundオブジェクトが変更されてサウンドをビデオに添付できなくなったので、ビデオのオーディオの制御にSoundオブジェクトは使用できません。手順は次のとおりです。flaファイルを開きます。通常は、ここで宣言は行いません。
264コンテンツの再生
手順は次のとおりです。コンストラクタの前で、次のようにいくつかの変数を宣言します。処理は不要ですが、クライアントオブジェクトを作成する必要があります。また、NetStreamからステータスイベントを処理するコード行も追加します。完成したメソッドは、次のようになります。ステータスイベントを処理する関数を作成します。
具体的には、H
264ビデオを追跡できる次の2つの新しいステータスイベントを処理します。ファイルを保存します。
MPEG-4ファイルからのメタデータの抽出
以前は、Flashベースのビデオを操作するときに、再生時に使用するための追加のデータをビデオファイルに挿入できました。データには、トラックの長さやビデオのサイズなど、簡単な関連情報が含まれていました。これらの種類の情報は、新しくサポートされるビデオ形式でも使用できます。MPEGは、多くの異なる項目の情報を1つのファイルにまとめて格納できるコンテナ形式なので、そのコンテナ内の様々な各情報にアクセスできます。
NetStreamのonMetaDataイベントを使用すると、サイズ、長さ、コーデック、シークポイントに加え、カバーアート、字幕、オーディオブックチャプター、その他のテキストやイメージなど、様々な情報をH
264ファイルとM4Aファイルの両方から抽出できます。メタデータにシークポイントが含まれていない場合、ファイルをシークすることはできません。カバーアートもオーディオファイルまたはビデオファイルにエンコードできます。カバーアートは、onMetaDataイベントを介して最も頻繁にアクセスされるファイルです。次のチュートリアルで、この手順について説明します。ビデオファイルからメタデータを抽出する手順は次のとおりです。flaファイルを開きます。outputレイヤーのフレーム1が選択されているときに、ステージ上にダイナミックテキストフィールドを作成します。テキストフィールドのxプロパティを5に設定します。テキストフィールドのyプロパティを5に設定します。テキストフィールドのwidthプロパティを175に設定します。テキストフィールドのheightプロパティを300に設定します。そのため、まずメタデータを処理する関数を記述し、その関数でイベントオブジェクトを唯一のパラメータとして受け取ります。onMetaDataイベントハンドラの内部に、p_infoオブジェクトのプロパティをループ処理してダイナミックテキストフィールドに表示するforループを作成します。コードは、次のようになります。メタデータを使用して、ビデオオブジェクトのサイズを設定します。このサイズが表示されるようにFlashプロジェクトのサイズを調整できます。幅と高さのサイズとして1465 x 720を使用して、サンプルファイルのサイズを調整してください。ブラウザでムービーをテストします。ビデオが出力テキストフィールドの上にロードされ、テキストフィールドが見えないことがあります。この問題を解決するには、上のビデオを移動します。ファイルを保存し、ブラウザでもう一度ムービーをテストします。表示される出力テキストフィールド内にメタデータが表示され、ソースビデオのサイズと一致するようにVideoオブジェクトのサイズが変更されます。オーディオファイルからメタデータを抽出する手順は次のとおりです。flaファイルを開きます。outputレイヤーのフレーム1が選択されているときに、ステージ上に2つのダイナミックテキストフィールドを作成し、インスタンス名としてlength_txtおよびcopy_txtを設定します。また、プロパティインスペクタの「テキストの周囲にボーダーを表示」ボタンをクリックして、テキストフィールドの周囲にボーダーを追加します。プロパティインスペクタの表示は図6のようになります。
テキストフィールドの設定の更新
これらの変更を行うと、ステージは図7の例に示すような表示になります。
2つのテキストフィールドの設定を更新
これによりルートのタイムラインがNetStreamからのイベントを処理します。関数には、Objectと入力されたp_infoという名前の1つのパラメータを渡す必要があります。オーディオの長さはイベントオブジェクトのdurationプロパティに秒単位で格納されます。そのため、その数値に1000を掛けると、メディアのミリ秒単位の所要時間を求めることができます。オーディオソースファイルのエンコードに使用するコーデックを表示するために、copy_txt TextFieldのテキストを設定します。完成したコードは、次のようになります。ブラウザでムービーをテストすると、ファイルのメタデータから抽出された基本的な情報が表示されます。これでも十分ですが、さらに見栄えのするものにできます。ブラウザウィンドウを閉じ、Flashに戻ります。アクションパネルを開きます。カバーイメージを表示する関数を記述します。そのため、このサイズに一致するようにFlashムービーのサイズを変更する必要があります。また、ビデオにカバーアートメタデータが関連付けられている場合は、オーディオだけでなくビデオのこの情報も取得できます。ロードしたイメージが表示されるように、関数の最後の行で、表示リストのインデックス0にLoaderを追加する必要があります。このif条件式は、covrとして格納されたカバーデータがタグオブジェクト内に存在するかどうかをチェックします。elseステートメント内で、copy_txtのテキストプロパティを設定したコードを折り返します。この情報は、サンプルメディアファイルの©cpy属性および©url属性として格納されています。理論的には、複数のイメージをカバーデータとしてメディアに関連付けることができるため、covrプロパティをArrayとして処理する必要があります。ブラウザでムービーをテストします。
オーディオの長さとメディアに関する著作権情報が含まれたカバーアートが表示されます(図8を参照)
ブラウザでムービーをテストするときに表示されるオーディオソースファイルのメタデータ
フルスクリーンビデオでのハードウェアスケーリングの使用
この機能は、フルスクリーンでHDビデオの再生を簡単に操作できるようにするために役立ちます。
新しいハードウェアアクセラレーションは、新しいH
264ビデオ機能専用に作成されたわけではありません。ハードウェアアクセラレーションは、大きいOn2 VP6ビデオファイルや一般的なSWFコンテンツの表示にも使用できます。
最初に表示されるのは「ディスプレイ」タブです(図9を参照)
ハードウェアアクセラレーションのオンとオフを切り替えるFlash Playerの設定パネルの「ディスプレイ」タブ
「ディスプレイ」タブには、ハードウェアアクセラレーションを有効にするかどうかを指定するチェックボックスのみがあります。このチェックボックスがオフになっている場合はオンにして、ハードウェアアクセラレーションを有効にします。ハードウェアアクセラレーションは、コンテンツが新しいActionScript APIを使用してトリガすると使用状態になります。このオプションをオフまたは無効にしてスケーリングAPIを使用すると、ソフトウェアアクセラレーションが使用されます。ハードウェアアクセラレーションを有効にしてAPIを使用すると、Flash Playerはハードウェアアクセラレーションを使用します。ハードウェアアクセラレーションが最も効果を発揮するするのは、ムービーの一部をフルスクリーンまたはムービー全体に拡大するフルスクリーンモードです。ここでは、新しいハードウェアアクセラレーションを利用して、SWFの一部をフルスクリーンに拡大します。フルスクリーンビデオの視覚的な効果の例を確認するには、Adobe Labsのデモ*を参照してください。ムービーの部分をフルスクリーンビデオにスケーリングする手順は次のとおりです。flaファイルを開きます。ステージをフルスクリーンにするには、onReleaseイベントやonKeyDownイベントなどのユーザ操作に応答する必要があります。ただし、ここでは、関数を記述してムービーをフルスクリーンにすることができます。関数内部で、ビデオと同じサイズのRectangleを作成し、同じx座標およびy座標に配置します。そのプロパティは正式にはまだクラスではないため、角括弧を使用してクラスにする必要があります。StageクラスのNORMALプロパティと照合することでステージが標準の表示状態かどうかを確認するif条件式を、上のコード行の後に次のように作成します。条件式の内部でFULL_SCREENプロパティを使用して、ステージの表示状態をフルスクリーンに変更します。ステージの表示状態を再び標準に設定するelseステートメントを追加して、if条件式を拡張します。タイムラインに戻り、outputレイヤーの上に新しいレイヤーを作成します。
矩形を選択し、シンボルに変換ダイアログボックスを呼び出します(F8キーを押す)
フルスクリーンボタンとして機能する矩形に設定する種類としてムービークリップを選択します。
矩形をButtonという名前のムービークリップシンボルに変換
プロパティインスペクタを使用して、x値が40、y値が320の位置にボタンを配置します。ファイル/パブリッシュ設定を選択し、パブリッシュ設定ダイアログボックスにアクセスします。ブラウザでムービーをテストします。ビデオがフルスクリーン表示モードになります。
次のステップ
264とAACのサポートが追加されたことにより、業界標準の高解像度ビデオおよびオーディオを簡単に使用できます。Flash Playerのこのアップデートにより、Web上のビデオの品質レベルが向上し、様々な種類のデバイスでビデオを表示できるようになりました。
著者について
同社はコロラド州に本社を置くデジタルメディア企業で、インタラクティブモーションメディアや高度なFlashおよびFlexプラットフォームアプリケーションに注力しています。David氏は常にモーションメディアやビデオの持つ力に情熱を注ぎ、使いやすさと双方向性の課題の解決に取り組んでいます。David氏はアドビ認定のマスターインストラクターで、デンバー大学で上級RIAクラスの授業を受け持っています。また、Rocky Mountainアドビユーザグループのマネージャーも務めているほか、FlashおよびFlexアプリケーション上級コースの講師とコース設計も兼務しています。David氏は、コードや技術的なベストプラクティスに関する高度なレビューを定期的に実施しています。また、過去数年間にわたり、Macromedia、アドビ、およびそのクライアントの業界エキスパートとして、世界中の業界リーダーに対し、技術レビュー、コースウェアレビュー、アプリケーションレビューなどの方向性に関するアドバイスを提供しています。
お問い合わせ
不正コピー防止について
著作権と商標について*
当Webサイトをご利用のお客様は、利用規約およびプライバシーポリシー(2009年7月14日更新)にご同意いただいたものとみなされます。
より安全なSWF Webアプリケーションの作成 | デベロッパーセンター
記事のアーカイブ*
ユーザグループの検索*
ユーザグループについて*
SWFファイルに対する潜在的な脅威
安全性の高いコンパイラ設定の選択
HTMLコード内でのセキュリティ制御の設定
リモートコンテンツのロード
複雑なクロスドメインの実装
ドメインを越えるSWF間の通信
共有リソースの使用による通信
リモートソースからのデータの検証
テキストフィールドおよび描画可能領域での安全なコンテンツ表示
データの暗号化
開発者向けチェックリスト
SWFファイルに対する潜在的な脅威
この節では、SWFアプリケーションを開発する際に考慮する必要がある全体に影響を及ぼすさまざまな脅威について、簡単な概要を示します。これ以外にも特定のSWFファイルの特定のコンテキスト内で定義できる個別の脅威がありますが、この概要では、SWFのほとんどのデプロイメントに共通しており全体に影響を及ぼす脅威について説明します。このドキュメントの残りの部分では、関連する脅威についての項目で、これらの脅威をFlash Playerの特定のAPIや概念に対応付けて示します。それに続いて、各節で、該当する脅威に対する緩和策について説明します。
クロスドメイン権限の昇格
クロスドメインのロードでは、リモートSWFが、ロードする側のドメインおよびデータへの意図しないアクセスを許可されることがあります。ロードする側のSWFがセキュリティドメインにリモートSWFをインポートする場合、ロードされたSWFは親SWFのデータにアクセスし、そのデータを攻撃者に中継して返すことができます。さらに、Webページの設定によっては、ロードされたSWFがロードされたSWFファイルのWebページにスクリプトを挿入できます。このような攻撃は、エンドユーザが親SWFファイルによってロードされたムービーを制御できる場合に発生する可能性があります。クロスドメイン権限の昇格は、SWFをスプーフィング、ブラウザへのスクリプトのインジェクション、悪意のあるデータのインジェクション、DNSリバインディング、承認の不適切な制限などにさらされる恐れがある、全体に影響を及ぼす脅威です。この脅威は、複数のリモートソースからのコンテンツが1つのセキュリティドメインにロードされて処理される場合に常に存在します。リモートでロードされるSWFが、スプーフィング攻撃を目的として、ロードされるSWFのコントロールをロードする側のSWFの上に表示しようと試みることがあります。悪意のあるSWFが、親SWFの上に重ねて表示されることにより、ロードする側のSWFファイルのコントロールを乗っ取ることができます。例えば、開発者がLoaderにマスクを設定してリモートSWFファイルの表示をStageの特定の領域に制限していない場合、攻撃者がスプーフィング攻撃を実行できます。
悪意のあるデータのインジェクション
攻撃者は、ほとんどの脆弱性を、アプリケーションに悪意のあるデータを挿入することによって見つけ出します。Flashアプリケーションは、さまざまな種類のインターフェイスから悪意のあるデータのインジェクションを受けることがあります。しかし開発者は、これらの変数がURLから設定でき、その場合、攻撃者が変数の値を簡単に変更できるということを忘れがちです。0では、初期化されていない値をFlashVarとしてURLから自動的に設定することができます。0では、各FlashVar変数の値を明示的に要求し、その値を内部変数に手動で割り当てる必要があります。また、SWFファイルがLocalConnectionからデータを取得する場合、SWFファイルがサーバから変数をリモートでロードする場合、SWFファイルが別のSWFファイルからデータをインポートする場合など、SWFがリモートデータをロードするときも常に、悪意のあるデータのインジェクションが行われる可能性があります。リモートで取得したデータの妥当性を検証しない場合、SWFファイルがこの脅威にさらされます。
ブラウザへのスクリプトのインジェクション
インスタンスによっては、所有者がサイト上にサードパーティのSWFファイルをホストしていることがあります。しかし、Webサイトの所有者は、サードパーティのSWFファイルにHTMLコードまたはJavaScriptコードへの読み書きアクセス権を与えないようにできます。アクセス許可の設定が不適切な場合、攻撃者はページ全体を書き換えたり、信頼できるサイトからフィッシングサイトにユーザをリダイレクトしたりできます。考慮する必要がある最も一般的な脆弱性は、攻撃者がクロスサイトスクリプティング(XSS)攻撃を目的としてデータを挿入することです。クロスサイトスクリプティング攻撃は、信頼できるSWFに悪意のあるリモートSWFがインポートされ、そのリモートSWFがjavascript: URLを呼び出す場合にも発生します。
承認の不適切な制限
過度なクロスドメインのアクセス許可を与えると、リレー攻撃、スプーフィング、データ盗用などの攻撃を受ける恐れがあります。例えば、悪意のあるSWFファイルが、過度なアクセス許可を与えるクロスドメインポリシーファイルを利用して、保護されたデータをリモートWebサイトから盗もうと試みる場合があります。allowDomainメソッドまたはクロスドメインファイルでワイルドカードを誤用すると、ドメインの制限が緩くなる可能性があります。comに対して許可されていないアクセス権を得ることがクロスドメインの脅威であると考えがちです。しかし開発者は、SWFファイルが共有環境でホストされるかどうかについても考慮する必要があります。com/~user2のコンテンツが開発者によって明示的に信頼されていない場合も含まれます。また、広告で、複数のソースからの広告が同じドメインでホストされる場合もあります。この脅威への対抗策を検討するときに、開発者は、共有ホスティングの状況を考慮する必要があります。
送信中のデータに対する無許可のアクセス
攻撃者が、RTMPやHTTPなどの暗号化されていないチャネルで送信されたデータに対して、読み取りや変更を試みることがあります。SWFファイルが重要な機能(ショッピングカートでのクレジットカードデータの収集など)を実行している場合、攻撃者がそのデータを閲覧する可能性があります。攻撃者がトラフィックを操作して、信頼されているSWFファイルがエンドユーザに届く前に、悪意のあるSWFに置き換えようとすることもあります。この脅威に対する脆弱性としては、HTTPSやRTMPSなどの安全な通信チャネルを使用して重要なデータを保護していない場合が挙げられます。HTTP経由でロードされるSWFファイルがHTTPS経由でロードされるSWFファイルのデータにアクセスできる場合にも、通信の安全性が低下する恐れがあります。デフォルトでは、HTTP経由でロードされるファイルがHTTPS経由でロードされるSWFファイルのデータにアクセスすることはできません。しかし、データがHTTP SWFとHTTPS SWFの間で共有されていると、安全でないチャネル経由でデータが送信される可能性があります。xmlファイルで安全フラグがfalseに設定された場合に発生します。
ローカルデータに対する無許可のアクセス
攻撃者が、SWFファイルとローカル共有オブジェクトから重要なローカルデータを盗もうとすることがあります。SWFファイルがデコンパイルされ、ローカル共有オブジェクトがサードパーティアプリケーションによって読み取られる可能性があります。また、攻撃者がクロススクリプティングによって情報を直接取得しようと試みることもあります。この脅威に対する脆弱性としては、開発者がSWFアプリケーションと共有オブジェクトに重要なデータを格納している場合などが挙げられます。クロスサイトリクエストフォージェリ*(XSRF)とは、攻撃者のWebサイトを閲覧したユーザに、そのユーザが認証を受けていない別のサイトへの要求を無許可で開始させる手法を指します。標的となるWebサイトがユーザ情報の更新にアトミックな(1回の送信で実行される)アクションを使用している場合、攻撃者はブラウザにそのサイトへの要求を強制的に実行させることにより、そのサイト上でユーザのアカウントの変更を開始できます。ブラウザによって要求にCookieが自動的に付加されるので、攻撃者が攻撃を実行する際にユーザのCookieは必要ありません。通常、攻撃者は自分が実行した更新の結果を直接見られませんが、それでも変更は行われます。Webの現在の設計上、このような攻撃に対する防御はWebサイト自体では実装されていますが、ブラウザやそのクライアントでは実装されていません。WebブラウザとFlash Playerでは、同一生成元ポリシーの一環として、ドメイン名を使用してデータへのアクセスが承認されます。攻撃者が、Webブラウザが特定のドメイン名に関して記録済みのIPアドレスを頻繁に更新するように仕向けることにより、同一生成元ポリシーを回避しようと試みることがあります。この攻撃を実行するためには、攻撃者が、自分の制御下にあるDNSサーバと悪意のあるWebサイトを所有している必要があります。攻撃者はさまざまな手法を用いて自分のDNSサーバ内で自分のドメイン名のIPアドレスを更新し、その更新情報を取得するようにWebブラウザに強制します。攻撃者は最初に自分のドメイン名が自分のパブリックWebサイトのIPを指すようにし、次に攻撃対象の内部ネットワーク上の信頼できるサーバのIPを指すようにし、最後に再び自分のパブリックWebサイトを指すようにします。これらの要求ではすべて、IPアドレスだけが変更され、要求の確立に使用されるドメイン名は変更されません。すべての要求のドメイン名が同じなので、Webブラウザは、信頼できる内部サーバへの接続と攻撃者のパブリックWebサーバへの接続がセキュリティ上同一であると見なします。これにより、攻撃者は内部Webサーバの情報を盗み、そのデータを自分のパブリックWebサイトに送り返せるようになります。この攻撃は、Flashのソケット接続にも適用される可能性があります。
お問い合わせ
不正コピー防止について
著作権と商標について*
当Webサイトをご利用のお客様は、利用条件およびプライバシーポリシー(2009年7月14日更新)にご同意いただいたものとみなされます。
より安全なSWF Webアプリケーションの作成 | デベロッパーセンター
記事のアーカイブ*
ユーザグループの検索*
ユーザグループについて*
SWFファイルに対する潜在的な脅威
安全性の高いコンパイラ設定の選択
HTMLコード内でのセキュリティ制御の設定
リモートコンテンツのロード
複雑なクロスドメインの実装
ドメインを越えるSWF間の通信
共有リソースの使用による通信
リモートソースからのデータの検証
テキストフィールドおよび描画可能領域での安全なコンテンツ表示
データの暗号化
開発者向けチェックリスト
データの暗号化
SWF Webアプリケーションでデータを暗号化するには、いくつかの方法があります。ここでは、それらの方法について簡単に説明します。
関連する脅威:送信中のデータに対する無許可のアクセス、ローカルデータに対する無許可のアクセス
ハッシングとは、不可逆的な暗号化を行う方法で、元のテキストを一意の文字列(ハッシュ)に変換します。ハッシュは不可逆であるため、ハッシュを元のテキストに戻す方法はありません。ハッシュアルゴリズムは、パスワードの認証や格納などの処理を行う場合に便利です。多くのアプリケーションでは、パスワードがハッシュアルゴリズムを通じて処理され、作成されたハッシュがディスク上に格納されます。アプリケーションでエンドユーザの認証を行うときは、入力されたパスワードのハッシュが作成され、格納されているパスワードのハッシュと同じ一意の文字列になるかどうか確認されます。2つのハッシュが一致すると、そのユーザはアクセスを許可されます。この方法では、パスワードを平文でない形式で格納できるため、パスワードが解読されて盗まれることはありません。これは、ハッシュアルゴリズムを対象とした暗号解読攻撃が存在することがわかっているためです。次に例を示します。
対称および非対称暗号化方式
関連する脅威:送信中のデータに対する無許可のアクセス、ローカルデータに対する無許可のアクセス
対称および非対称暗号化方式は、データの可逆的な暗号化を行う場合に便利です。これらの暗号化方式は利用しやすいですが、開発者はSWFファイルが逆コンパイルできることを認識しておく必要があります。このため、これらの暗号化方式の秘密鍵およびプライベート鍵は、SWFファイル自体の中に格納できません。少なくとも、対称方式の秘密鍵と非対称方式のプライベート鍵は、セキュリティで保護されたインターネットプロトコルを通じてダウンロードするか、エンドユーザのマシン上のSWFから生成することによって、漏洩を防止する必要があります。
SWFファイル内の鍵に対する脅威
SWFファイル内で対称方式および非対称方式の秘密鍵を使用する場合は、いくつかの脅威が存在します。対称方式の秘密鍵を共有オブジェクトに格納する場合は、共有オブジェクトが暗号化されていないため、ユーザやユーザのマシン上の悪質なソフトウェアによって読み取られる可能性があることを念頭に置いておく必要があります。また、localPathのデフォルトの設定に変更を加える場合にも、十分な注意が必要です。この設定を変更すると、共有オブジェクトに含まれるデータを読み取ることができるSWFファイルの数が増えるからです。共有オブジェクトのセキュアフラグをtrueに設定すると、安全な方法でロードされたSWFファイルだけに共有オブジェクトへのアクセス権を与えることができます。攻撃者が送信中のSWFファイルの置き換えに成功すると、不正なSWFファイルによって共有オブジェクトから鍵が盗まれる可能性があります。
同じドメインにホストされている外部SWFファイル(鍵を格納するSWFにインポート、ロードされる)、およびSecurity
allowDomain()設定によって権限を付与されている外部SWFファイルも、クロススクリプト権限によってSWFファイルから鍵を取得できます。非対称暗号化方式を使用する場合は、SWFファイル内に公開鍵を格納しても、脅威にさらされることはありません。公開鍵は、対応する秘密鍵を持つサーバアプリケーションにデータを送信する前に、そのデータを暗号化するために使用します。この方法では、暗号化されたデータをサーバに送信するという一方向の通信を行うだけで済みます。また、サーバからSWFファイルに送信された電子署名付きデータの検証にも使用できます。この方法の有効な使用例としては、パスワードなどの機密データを収集し、サーバに送信する必要がある場合などが挙げられます。SWFファイルに含まれるのは公開鍵であり、公開鍵は暗号化にのみ使用されるため、第三者がSWFファイルを逆コンパイルして鍵を盗んだとしても問題はありません。攻撃者が不正な暗号化済みデータをサーバに送りつける可能性もありますが、サーバ側で、暗号化が行われているかどうかにかかわらずデータの検証を行うよう対策を施していれば、問題はありません。ただし、暗号化を使用する場合は、パフォーマンスについて考慮する必要のある問題があるため、暗号化を広範囲にわたって使用する場合は、テストを十分に行ってください。たとえば、RSAによる暗号化は、RSAの復号化よりも処理が速い傾向があります。多くの場合、HTTPSプロトコルを使用して暗号化データを送信する方が、ActionScriptコードで暗号化を実行するよりも、処理が速く安全性も高いと言えます。このコードは、公開鍵による暗号化がオープンソースソリューションで実現できることを示すことだけを目的としています。注:AS3Cryptoライブラリはアドビが作成したものではないため、保守および開発については責任を負いません。開発者は、自身が信頼する、必要な機能を備えたライブラリを選択してください。
次のステップ
より安全なSWFアプリケーションをエンドユーザに展開するには、アドビ、Flashアプリケーションの開発者、およびWebサイトの管理者がお互いに協力する必要があります。アドビは、Flash Playerの新バージョンを作成するたびに、より堅牢なセキュリティコントロールと、安全なアプリケーションを作成するためのツールを備えた、より強力なプラットフォームを実現するため、最大限の努力を払っています。開発者は、これらのツールを使用し、SWFファイルを最新バージョン用にコンパイルし、データの検証を行い、提供されているSDKを使用することによって、Flash Playerで実行されるアプリケーションのセキュリティを強化できます。Webサイトの管理者は、オブジェクトタグパラメータを使用し、クロスドメインポリシーファイルをサイトで正しく展開し、アクセスおよび展開に関する合意済みの計画に基づいて開発者と協力することで、これらのSWFファイルをサイト上に展開できます。これらのテクニックを実行することにより、Flash Playerアプリケーションによってリッチなインターネット環境とより安全な環境をエンドユーザに提供できます。詳細については、次のリソースを参照してください。
0のベストプラクティス*
お問い合わせ
不正コピー防止について
著作権と商標について*
当Webサイトをご利用のお客様は、利用条件およびプライバシーポリシー(2009年7月14日更新)にご同意いただいたものとみなされます。
より安全なSWF Webアプリケーションの作成 | デベロッパーセンター
記事のアーカイブ*
ユーザグループの検索*
ユーザグループについて*
しかし、それによって対応できるのは、Flash Playerで実行されるアプリケーションを安全にデプロイするための全体的なソリューションの半分にすぎません。プログラミング規則が不完全な場合、SWFファイルとそれをホストするサイトがWeb攻撃にさらされる恐れがあります。この記事では、一般的なタスクに関連するセキュリティ上の考慮事項の多くについて説明し、そのような脅威に対抗して安全なコードを作成するのに役立つ手法の例を示します。詳しい情報が必要な場合のために、記事全体を通して、完全なドキュメントへのリンクを提供しています。この記事を最大限に活用するには、次のソフトウェアをインストールする必要があります。
さらに詳しく
この記事に必要な予備知識
SWFファイルに対する潜在的な脅威
この節では、SWFアプリケーションを開発する際に考慮する必要がある全体に影響を及ぼすさまざまな脅威について、簡単な概要を示します。これ以外にも特定のSWFファイルの特定のコンテキスト内で定義できる個別の脅威がありますが、この概要では、SWFのほとんどのデプロイメントに共通しており全体に影響を及ぼす脅威について説明します。このドキュメントの残りの部分では、関連する脅威についての項目で、これらの脅威をFlash Playerの特定のAPIや概念に対応付けて示します。それに続いて、各節で、該当する脅威に対する緩和策について説明します。
クロスドメイン権限の昇格
クロスドメインのロードでは、リモートSWFが、ロードする側のドメインおよびデータへの意図しないアクセスを許可されることがあります。ロードする側のSWFがセキュリティドメインにリモートSWFをインポートする場合、ロードされたSWFは親SWFのデータにアクセスし、そのデータを攻撃者に中継して返すことができます。さらに、Webページの設定によっては、ロードされたSWFがロードされたSWFファイルのWebページにスクリプトを挿入できます。このような攻撃は、エンドユーザが親SWFファイルによってロードされたムービーを制御できる場合に発生する可能性があります。クロスドメイン権限の昇格は、SWFをスプーフィング、ブラウザへのスクリプトのインジェクション、悪意のあるデータのインジェクション、DNSリバインディング、承認の不適切な制限などにさらされる恐れがある、全体に影響を及ぼす脅威です。この脅威は、複数のリモートソースからのコンテンツが1つのセキュリティドメインにロードされて処理される場合に常に存在します。リモートでロードされるSWFが、スプーフィング攻撃を目的として、ロードされるSWFのコントロールをロードする側のSWFの上に表示しようと試みることがあります。悪意のあるSWFが、親SWFの上に重ねて表示されることにより、ロードする側のSWFファイルのコントロールを乗っ取ることができます。例えば、開発者がLoaderにマスクを設定してリモートSWFファイルの表示をStageの特定の領域に制限していない場合、攻撃者がスプーフィング攻撃を実行できます。
悪意のあるデータのインジェクション
攻撃者は、ほとんどの脆弱性を、アプリケーションに悪意のあるデータを挿入することによって見つけ出します。Flashアプリケーションは、さまざまな種類のインターフェイスから悪意のあるデータのインジェクションを受けることがあります。しかし開発者は、これらの変数がURLから設定でき、その場合、攻撃者が変数の値を簡単に変更できるということを忘れがちです。0では、初期化されていない値をFlashVarとしてURLから自動的に設定することができます。0では、各FlashVar変数の値を明示的に要求し、その値を内部変数に手動で割り当てる必要があります。また、SWFファイルがLocalConnectionからデータを取得する場合、SWFファイルがサーバから変数をリモートでロードする場合、SWFファイルが別のSWFファイルからデータをインポートする場合など、SWFがリモートデータをロードするときも常に、悪意のあるデータのインジェクションが行われる可能性があります。リモートで取得したデータの妥当性を検証しない場合、SWFファイルがこの脅威にさらされます。
ブラウザへのスクリプトのインジェクション
インスタンスによっては、所有者がサイト上にサードパーティのSWFファイルをホストしていることがあります。しかし、Webサイトの所有者は、サードパーティのSWFファイルにHTMLコードまたはJavaScriptコードへの読み書きアクセス権を与えないようにできます。アクセス許可の設定が不適切な場合、攻撃者はページ全体を書き換えたり、信頼できるサイトからフィッシングサイトにユーザをリダイレクトしたりできます。考慮する必要がある最も一般的な脆弱性は、攻撃者がクロスサイトスクリプティング(XSS)攻撃を目的としてデータを挿入することです。クロスサイトスクリプティング攻撃は、信頼できるSWFに悪意のあるリモートSWFがインポートされ、そのリモートSWFがjavascript: URLを呼び出す場合にも発生します。
承認の不適切な制限
過度なクロスドメインのアクセス許可を与えると、リレー攻撃、スプーフィング、データ盗用などの攻撃を受ける恐れがあります。例えば、悪意のあるSWFファイルが、過度なアクセス許可を与えるクロスドメインポリシーファイルを利用して、保護されたデータをリモートWebサイトから盗もうと試みる場合があります。allowDomainメソッドまたはクロスドメインファイルでワイルドカードを誤用すると、ドメインの制限が緩くなる可能性があります。comに対して許可されていないアクセス権を得ることがクロスドメインの脅威であると考えがちです。しかし開発者は、SWFファイルが共有環境でホストされるかどうかについても考慮する必要があります。com/~user2のコンテンツが開発者によって明示的に信頼されていない場合も含まれます。また、広告で、複数のソースからの広告が同じドメインでホストされる場合もあります。この脅威への対抗策を検討するときに、開発者は、共有ホスティングの状況を考慮する必要があります。
送信中のデータに対する無許可のアクセス
攻撃者が、RTMPやHTTPなどの暗号化されていないチャネルで送信されたデータに対して、読み取りや変更を試みることがあります。SWFファイルが重要な機能(ショッピングカートでのクレジットカードデータの収集など)を実行している場合、攻撃者がそのデータを閲覧する可能性があります。攻撃者がトラフィックを操作して、信頼されているSWFファイルがエンドユーザに届く前に、悪意のあるSWFに置き換えようとすることもあります。この脅威に対する脆弱性としては、HTTPSやRTMPSなどの安全な通信チャネルを使用して重要なデータを保護していない場合が挙げられます。HTTP経由でロードされるSWFファイルがHTTPS経由でロードされるSWFファイルのデータにアクセスできる場合にも、通信の安全性が低下する恐れがあります。デフォルトでは、HTTP経由でロードされるファイルがHTTPS経由でロードされるSWFファイルのデータにアクセスすることはできません。しかし、データがHTTP SWFとHTTPS SWFの間で共有されていると、安全でないチャネル経由でデータが送信される可能性があります。xmlファイルで安全フラグがfalseに設定された場合に発生します。
ローカルデータに対する無許可のアクセス
攻撃者が、SWFファイルとローカル共有オブジェクトから重要なローカルデータを盗もうとすることがあります。SWFファイルがデコンパイルされ、ローカル共有オブジェクトがサードパーティアプリケーションによって読み取られる可能性があります。また、攻撃者がクロススクリプティングによって情報を直接取得しようと試みることもあります。この脅威に対する脆弱性としては、開発者がSWFアプリケーションと共有オブジェクトに重要なデータを格納している場合などが挙げられます。クロスサイトリクエストフォージェリ*(XSRF)とは、攻撃者のWebサイトを閲覧したユーザに、そのユーザが認証を受けていない別のサイトへの要求を無許可で開始させる手法を指します。標的となるWebサイトがユーザ情報の更新にアトミックな(1回の送信で実行される)アクションを使用している場合、攻撃者はブラウザにそのサイトへの要求を強制的に実行させることにより、そのサイト上でユーザのアカウントの変更を開始できます。ブラウザによって要求にCookieが自動的に付加されるので、攻撃者が攻撃を実行する際にユーザのCookieは必要ありません。通常、攻撃者は自分が実行した更新の結果を直接見られませんが、それでも変更は行われます。Webの現在の設計上、このような攻撃に対する防御はWebサイト自体では実装されていますが、ブラウザやそのクライアントでは実装されていません。WebブラウザとFlash Playerでは、同一生成元ポリシーの一環として、ドメイン名を使用してデータへのアクセスが承認されます。攻撃者が、Webブラウザが特定のドメイン名に関して記録済みのIPアドレスを頻繁に更新するように仕向けることにより、同一生成元ポリシーを回避しようと試みることがあります。この攻撃を実行するためには、攻撃者が、自分の制御下にあるDNSサーバと悪意のあるWebサイトを所有している必要があります。攻撃者はさまざまな手法を用いて自分のDNSサーバ内で自分のドメイン名のIPアドレスを更新し、その更新情報を取得するようにWebブラウザに強制します。攻撃者は最初に自分のドメイン名が自分のパブリックWebサイトのIPを指すようにし、次に攻撃対象の内部ネットワーク上の信頼できるサーバのIPを指すようにし、最後に再び自分のパブリックWebサイトを指すようにします。これらの要求ではすべて、IPアドレスだけが変更され、要求の確立に使用されるドメイン名は変更されません。すべての要求のドメイン名が同じなので、Webブラウザは、信頼できる内部サーバへの接続と攻撃者のパブリックWebサーバへの接続がセキュリティ上同一であると見なします。これにより、攻撃者は内部Webサーバの情報を盗み、そのデータを自分のパブリックWebサイトに送り返せるようになります。この攻撃は、Flashのソケット接続にも適用される可能性があります。
安全性の高いコンパイラ設定の選択
Flash Playerの最近のすべてのバージョンには、プレイヤーの新しいバージョンが入手可能になるとユーザに通知する自動アップデート機能が導入されています。この機能の導入により、ユーザの大半が新しいバージョンに迅速に移行しています。一部のアプリケーションでは、普及率が顧客の98%に達すれば十分であるといえます。
しかし、グローバルな組織にとって、インターネット上の何億というシステムの1
5%に未到達ということは、到達していないシステムが数百万になるということを意味します。古いバージョンのFlash Playerを使用するシステムには、古いオペレーティングシステムや、システムの安定性を図るために、どうしても必要でない限りアップデートを受信しないロックされた環境に含まれるシステムなどがあります。多くの場合、新しいバージョンのFlash Playerには、SWFファイルがホストされたWebサイトで悪用されないようにする上で役立つ重要なセキュリティアップデートやセキュリティ機能が含まれています。Flash Player 7では、サイト開発者とエンドユーザの両方にとって成熟度の低いセキュリティモデルを使用しています。したがって、SWFで安全性の高い設定を使用できるようにするには、Flash Player 8以降との互換性を保つようにコンパイルする必要があります。0を利用すると、より優れたセキュリティツールを入手できます。0を使用する開発者は、データ検証の実行プロセスを容易にする正規表現を利用できます。言語内での入力制御の集中管理も強化されます。0の処理に使用するAVM2仮想マシンでは、処理速度、堅牢性および安定性が向上しています。0への移行に関するガイドラインに複数のリソースが用意されています。
「読み込みプロテクト」オプションと「デバッグを許可」オプションの使用
関連する脅威:ローカルデータに対する無許可のアクセス
読み込みプロテクトおよびデバッグを許可の各フラグでは、MD5ハッシュを使用してSWFファイルをパスワードで保護し、SWFファイルがFlashオーサリングツールに読み込まれないようにします。この保護は、オーサリングツール用の基本的な保護であり、オーサリングツールではこの保護が優先されます。ただし、攻撃者がその気になれば、SWFファイルを逆コンパイルしてソースコードを取得することも、バイナリからデバッグフラグをストリップすることもできます。これらのフラグで使用されるMD5ハッシュは、辞書ベースのブルートフォース攻撃の対象となります。したがって、読み込みプロテクトフラグを設定している場合でも、SWFファイルを一種のブラックボックスアプリケーションと見なさないようにしてください。SWFに格納された機密データや秘密事項は簡単に見つかります。開発者は、SWFファイルのソースコードに静的パスワード、暗号化キーその他の機密データを格納しないようにする必要があります。
クリーンコードのコンパイル
関連する脅威:ローカルデータに対する無許可のアクセス
アプリケーションの作成時には、最終的な運用リリースからすべてのデバッグコードを削除することがベストプラクティスです。これは、SWFアプリケーションを開発する際のベストプラクティスでもあります。Flash開発環境のトレースアクションを省略フラグは、コンパイルされたSWFファイルの作成時にすべてのトレースコマンドを削除するようコンパイラに通知します。これにより、パブリッシュされるSWFのサイズが小さくなり、SWFから余分な情報やアクションがすべて削除されます。
最小ステージサイズの設定
関連する脅威:スプーフィング
共有オブジェクト、マイク、カメラその他のコンポーネントからのFlash Playerメッセージをユーザに完全に表示できるように、最小ステージサイズは、幅215ピクセル、高さ138ピクセルに設定する必要があります。
HTMLコード内でのセキュリティ制御の設定
SWFをHTMLに埋め込む場合、ブラウザからまたはネットワーク上でコンテンツにアクセスするためにSWFファイルが持つアクセス許可をFlash Playerに通知するフラグを設定できます。これらのフラグは、サイトでサードパーティ開発者の信頼性のないSWFファイルをホストする場合に役立ちます。
関連する脅威:ブラウザへのスクリプトのインジェクション
0以降で使用できるようになりました。0の場合)に送信することによって、ブラウザに対して外部スクリプト呼び出しを行うことができるかどうかが決まります。SWFファイルへのアクセスを許可する場合、基本的にHTMLページ全体への読み取りアクセスと書き込みアクセスの両方を許可することになるという点に注意してください。always:SWFファイルをロードする際に使用するドメインに関係なく、ブラウザと通信するときにSWFファイルは完全に信頼されます。このSWFによってロードされたすべてのSWFファイルにも、ブラウザと通信する許可が与えられます。次のコード例の強調表示されているセクションを確認してください。
関連する脅威:ブラウザへのスクリプトのインジェクション、クロスドメイン権限の昇格
all:ネットワーク接続を行うときに、SWFは完全に信頼されます。これがデフォルト設定です。0コマンドを作成できなくなります。すべてのネットワーク呼び出しは、SWF内で内部的に行う必要があります。none:これは、HTML内で設定できるタグの中で最も制限が厳しいタグです。このタグを指定すると、SWFによるすべての外部通信がブロックされます。
0の場合、内部設定によってブロックされるネットワークメソッドだけでなく、XML
(ActionScriptではなく)Flashオーサリングツールで追加されたインポート済み共有ライブラリのシンボルは、実行時にブロックされます。次のコード例の強調表示されているセクションを確認してください。
さまざまなセキュリティレベルのネットワーク設定とアクセス設定
SWFは、ブラウザおよびネットワークと通信するためのフルアクセス権を持ちます。これが最も安全性の低い設定です。SWFは、ソケットやローダーなどの内部APIを利用してネットワークと通信できます。すべての内部ネットワークAPIを使用できます。SWFは、ソケットやローダーなどの内部APIを利用してネットワークと通信できます。SWFはブラウザの呼び出しを行うことはできませんが、ソケットやローダーなどの内部APIを使用してネットワーク呼び出しを行うことができます。このSWFはブラウザと通信できません。SWFは、ソケットやローダーなどの内部APIを利用してネットワークと通信できます。これが最も安全性の高い設定です。
フルスクリーンモードの制御
関連する脅威:スプーフィング
フルスクリーンモードでの動作について詳しくは、デベロッパーセンターの記事「Flash Player 9のフルスクリーンモードの説明」を参照してください。Flash Playerに用意された機能を使用して、フルスクリーンモードの表示を制御できます。サードパーティのSWFファイルをホストするWebサイトでは、フルスクリーンモードに切り替え、サイトのコンテンツをオーバーレイすることをビデオに許可することは望ましくない場合があります。基本的に、フルスクリーン表示を使用すると、エンドユーザは実際にはサードパーティのSWFファイルとやり取りしているにもかかわらず、ホストしているWebサイトとやり取りしていると信じ込まされる可能性があります。アドビでは、このシナリオを制限する他の制御を用意しました。ユーザは、マウスクリックまたはキー入力によってフルスクリーンモードを開始する必要があります。フルスクリーン表示を起動すると、SWFをフルスクリーンモードで表示することをエンドユーザに警告するオーバーレイダイアログボックスが表示されます。このダイアログボックスでは、フルスクリーンモードの終了方法も示されます。SWFがフルスクリーンモードで表示されている間、ユーザはテキスト入力フィールドにデータを入力することはできません。cfgファイルでフルスクリーンモードを禁止することもできます。次のコード例の強調表示されているセクションを確認してください。
リモートコンテンツのロード
必要と考えられる最も一般的なタスクの1つは、イメージ、サウンドまたはその他のデータをリモートWebサイトから取得することです。コンテンツが要求元のSWFファイルとは異なるドメインにある場合、Flash Playerはリモートドメインに問い合わせて、ユーザがそのコンテンツへのアクセス許可を持っているかどうかを確認することが必要になる場合があります。以下の節では、アクセス許可が必要とされる状況と、アクセス許可を取得する方法について説明します。
異なるドメインからのコンテンツのロード
関連する脅威:クロスドメイン権限の昇格
デフォルトでは、Flash Playerはブラウザが使用する同一生成元ポリシーに従います。このポリシーは、1つのドメイン内のコンテンツは、同じドメイン名でホストされる他のすべてのコンテンツとデータにアクセスできるというものです。また、サイトは他のドメインのコンテンツを表示できますが、他のドメインに属するデータに直接アクセスすることはできません。
たとえば、同一生成元ポリシーでは、www
comに関連付けられている他のすべてのデータへのアクセスが許可されます。comのWebページを表示するインラインフレームを含めることもできます。
ただし、同一生成元ポリシーでは、www
Flash Playerは、コンテンツの生成元を定めるために使用する完全ドメイン名をコンテンツのセキュリティドメインと見なします。comによって定義されていると見なします。
comサイトでホストされる他のSWFファイルは、別のセキュリティドメインからロードされているので、これらのSWFファイルは、www
comサイトからロードされたSWFにフルアクセスすることはできません。comドメインとは異なるセキュリティドメインと見なされます。comからロードされたコンテンツをそれぞれ別のセキュリティドメインに分離します。ブラウザとは異なり、Flash Playerには、複数のドメイン名を含めるように同一生成元の保護を拡張するメソッドが用意されています。これにより、複数のドメイン名を使用するWebサイト所有者は、サイト間でやり取りすることが可能になります。これらのメソッドの多くは、開発者が外部とデータを共有できるようにワイルドカードの使用をサポートしています。セキュリティの観点からワイルドカードは慎重に使用する必要があります。ワイルドカードを使用すると、データへのアクセスをすべてのユーザに許可することになるからです。IPアドレスを使用して1つのドメイン名を2つのセキュリティドメインに分ける。多数のドメイン名を1つのセキュリティドメインに組み込むだけでなく、1つのドメイン名を2つのセキュリティドメインに分けることもできます。これは、使用できるドメイン名が1つしかないときに、2つの異なる信頼レベルでSWFファイルを使用する場合に必要となることがあります。これを実現するために、Flash Playerではドメイン名をIPアドレスに関連付けないという点を利用できます。swfによってロードされたSWFとは別のセキュリティドメインに属するものと見なします。この方法は、サイトで信頼できないユーザにSWFファイルのアップロードを許可する場合に役立ちます。サイト所有者は、ユーザがアップロードした悪意のあるSWFファイルよるアクセスからサイトのSWFファイルを保護する必要があります。そのため、サイト所有者は、URLのドメイン名を使用して信頼できるSWFファイルを参照し、URLに含まれるIPアドレスを使用して、ユーザが送信した悪意のある可能性があるSWFファイルをロードすることができます。
クロスドメインファイルの実装
関連する脅威:クロスドメイン権限の昇格、承認の不適切な制限
クロスドメインファイルは、複数のドメイン名を同じ生成元に属するものと見なすことを許可するように同一生成元ポリシーを拡張する1つの方法です。クロスドメインポリシーファイルは、このファイルをホストするサーバに、サーバのコンテンツをクロスドメインファイルに示されたドメインと同じ生成元に属するものと見なしてよいことを認識させる方法です。ポート80または443のWebサーバから提供されるクロスドメインファイルは、HTTPポリシーファイルと見なされ、Web要求のポリシーを制御できます。他のポートからホストされるクロスドメインファイルは、ソケットポリシーファイルと見なされます。ソケットポリシーファイルについては、後ほど説明します。xmlファイルを使用して、HTTPサーバへのアクセスに関する次の3つの側面を指定できます。
サーバの同一生成元に属していると信頼できるドメイン
リストされたドメイン名について、HTTPコンテンツとHTTPSコンテンツ間の通信を許可するかどうか
ポート1024より大きいポートへのソケットアクセスを暗黙的に許可する(Flash Playerの今後のバージョンでは、この機能は削除される予定です)
コンテンツ配信者は、これらのクロスドメイン制御を利用できます。クロスドメイン制御は、Webサイト全体に適用することも、一部分だけに適用することもできます。allowDomain()メソッドを使用すると、クロスドメインのアクセス許可をファイルごとに付与できます。ほとんどのブラウザと同様に、Flash Playerではクロスドメインのデータ送信は防止されないことに注意してください。comに対してデータのHTTP POSTを実行する場合、クロスドメインファイルは必要ありません。comのSWFが要求の応答データにアクセスする必要がある場合は、クロスドメインポリシーファイルが必要です。xmlファイルを使用する必要があるいくつかの状況を以下に示します。
contentなどを使用して、別のドメインのムービーまたはイメージに対してイメージの抽出を実行する必要がある場合
イメージを別のドメインからHTMLテキストフィールドにロードする場合
ソケットがポート1024より大きいポートに接続することを許可する必要がある場合
loadなど)によってデータを直接ロードする場合
Web管理者がサイトに対するクロスドメインのすべてのロード要求を明示的にブロックする場合
リモートHTTPサーバ上のSWFが、サーバのWebサイトのHTTPSで保護されたセクション内からデータをロードする必要がある場合
xmlファイルを使用する必要はありません。
別のドメイン内のものにアクセスせずに、そのドメインからロードしたイメージを子として表示する場合
ビデオデータやサウンドスペクトルデータへのアクセスを試みずにRTMPサーバのデータを表示または再生する場合
ローダーと同じドメインからイメージをロードする場合
リモートコンテンツをSWFファイルに正常にロードするには、リモートドメインでコンテンツのディレクトリまたはその親ディレクトリにcrossdomain
xmlファイルを配置する必要があります。xmlファイルを要求する必要があります。xmlファイルに示されていない場合、またはこのファイルが存在しない場合には、コンテンツへのアクセスは拒否され、データにアクセスしようすると例外がスローされます。クロスドメインファイルを使用すると、アクセスをグローバルかつ明示的に拒否することができます。クロスドメインファイルが存在しない場合にも、アクセスは拒否されます。
また、すべてのユーザに対してアクセスを明示的に拒否するには、エントリを含まないcrossdomain
xmlファイルをルートディレクトリに作成し、次のようにnoneに設定したサイト制御ポリシーを作成します。
クロスドメイン要求に関連するリスク
クロスドメインポリシーファイルの要求に関連するリスクがいくつかあります。comで、Cookieを使用してWebサイトの機密領域に対する認証と許可を追跡しているとします。この設定により、Webサイトは同一生成元の制限がサイトに適用されないことをFlash Playerに通知します。
そのため、リモートドメインの悪意のあるSWFにも、www
com内のすべてのデータとコンテンツへのアクセスが許可されることになります。悪意のあるSWFは、応答で返されたデータを取得し、元のWebサイトに返送することができます。内部ネットワーク上に過度のアクセス許可を設定したクロスドメインファイルが存在すると、この脅威が拡大するおそれがあります。たとえば、内部IT担当者が、ホストが内部ネットワーク上にあり、すべてのユーザが内部ネットワーク上で信頼されていると考えて、domain="*"を設定したクロスドメインファイルを作成する可能性があります。クロスドメインポリシーファイルは、ホストが信頼してそのデータを委ねるドメインを示すものです。したがって、IT管理者が作成したクロスドメインポリシーファイルは、内部ホストがインターネットサイトを含むすべてのサイトを信頼してそのデータを委ねることを示していることになります。そのため、ブラウザによって外部WebサイトからロードされたSWFは、内部Webサイトへの要求を作成し、その情報を中継してインターネットに送信することが許可されます。クロスドメインでのアクセスを調整する。クロスドメインのアクセス許可は多数のリスクを伴うため、管理者はさまざまな制御を使用して、コンテンツへの詳細なアクセス許可を付与できます。次のような制御を使用できます。
共有可能なコンテンツをあるサブドメイン(public
ワイルドカードを静的なドメイン情報と共に使用して、アクセス許可のスコープを制限する。サブディレクトリに基づいてアクセス許可を付与する。メタポリシーを使用して、未承認のクロスドメインポリシーファイルを防ぐ。HTTPS経由でロードされたSWFにのみアクセス許可を付与する。次の各節では、過度のクロスドメインアクセス許可の作成を回避するためのこれらの手法について詳しく説明します。ワイルドカードをドメイン名と組み合わせて使用する。ドメインに頻繁に変更される複数のサブドメインが含まれている場合、管理者はワイルドカードを親ドメイン名と組み合わせて使用できます。xmlファイルの有効なエントリを示しています。
SSLの一貫した使用
関連する脅威:送信中のデータに対する無許可のアクセス
HTTPS経由でロードされた信頼できるSWFファイルに安全に伝達された機密データに、HTTP経由でロードされた信頼性のないSWFファイルがアクセスするのを防ぐために、これらの制限がデフォルトで設定されています。man-in-the-middle攻撃とは、ネットワーク上でエンドユーザとサーバとの間に割り込んだ第三者が、SWFファイルの送信中にファイルの内容を変更したり、ファイルを置き換えたりするものです。データを確実に保護するために、すべてのデータをHTTPS経由でロードするSWFアプリケーションを作成しているWebサイトもあります。ただし、このようなWebサイトで、HTTP経由の初期SWFアプリケーションをロードすることでユーザ操作が開始されると問題が発生します。Flash Playerは、FlashアプリケーションがHTTPSを使用していることをエンドユーザにフィードバックしないので、エンドユーザは情報が保護されていることを確認できません。そのため、エンドユーザはSWFファイルを信頼することができません。SSLを使用してデータを保護することを予定している場合は、アプリケーション全体にわたりSSLを一貫して使用する必要があります。これにより、ユーザはセキュリティで保護された通信によってSWFを受信できます。また、セキュリティ保護されていないプロトコルとセキュリティ保護されたプロトコルが混在することによって生じる問題を開発者が回避する上でも役立ちます。ただし、この方法は推奨されません。HTTP SWFファイルからHTTPSで保護されたデータへの通信を許可することがどうしても必要な場合は、HTTP経由でロードされたSWFファイルに対してHTTPSで保護されたデータを公開するときに制限を課すようにします。したがって、SWFが接続しているサーバに証明書に関する問題(期限切れの証明書やドメイン名の不一致など)がある場合、ブラウザは問題についてユーザにプロンプトを表示することで処理します。ユーザが安全かつシームレスに操作できるように、開発者はWebサイト管理者と協力して、SSL証明書が最新の状態であること、信頼されている証明機関によって署名されていること、およびホストのドメイン名と一致していることを確認する必要があります。xmlファイルはsecureフラグを使用して、HTTPサーバ上でホストされたSWFがHTTPSで保護されたサイトから提供されるデータにアクセスするのを防ぎます。この場合、リモートHTTP経由でロードされたSWFファイルが、WebサイトのHTTPSで保護された領域のコンテンツにアクセスすることを許可しないようプレイヤーに通知されます。本来SSLによって保護されていたデータをHTTP経由でリモートサーバに送信すると、SSL接続によってそのデータに提供されていたすべての保護が無効になる可能性があります。secureフラグは、Webエントリに適用することも、ソケットポリシーエントリに適用することもできます。
複雑なクロスドメインの実装
以下の節では、サブディレクトリ内のクロスドメインポリシーファイル、メタポリシーの利用、ソケットポリシーファイルなど、より複雑なクロスドメインの実装について説明します。サブディレクトリからHTTPポリシーファイルを指定すると、そのディレクトリとそのすべてのサブディレクトリへのアクセスを定義できます。
したがって、管理者は、サイトのルートディレクトリ内に非常に一般的なcrossdomain
xmlファイルを作成する代わりに、ユーザが各自のニーズに応じてサブディレクトリ内で独自のcrossdomain
xmlファイルを定義することを許可できます。xmlファイルでこのアクセス許可を指定すれば、そのディレクトリだけを公開することができます。xmlファイルでは、ポートへのアクセスは定義できません。サブディレクトリからポリシーファイルをロードする方法のコード例を次に示します。
関連する脅威:クロスサイトリクエストフォージェリ
攻撃者がFlashVarを制御できるようになると、loadPolicyFileメソッドを使用してクロスドメインのGET要求を実行し、任意のデータをリモートサイトに送信する可能性があります。これによって、不正な情報公開が行われたり、クロスサイトリクエストフォージェリ攻撃を受けたりする恐れがあります。FlashVarとして場所を受け入れる必要がある場合、開発者は、URLをloadPolicyFileメソッドに提供する前に、そのURLが承認されたホワイトリストに記載されていることを確認する手順を踏む必要があります。
xmlファイルの制御
0)についての記事のメタポリシーの節を参照してください。
多くの開発者にとって、システム上のユーザに各自のディレクトリに対するcrossdomain
xmlファイルの作成を許可するかどうかは、悩ましい問題です。場合によっては、システム管理者だけがクロスドメインのアクセス許可を定義できるようにする必要があります。xmlファイルの作成を許可するディレクトリを制限するためのコントロールを設定できるようになりました。none:マスターポリシーファイルを含め、サーバ上のどの場所でもポリシーファイルを作成できません。これは、特定のHTTP応答がポリシーファイルとして解釈されるのを防ぎます。none-this-responseと他のメタポリシーの両方が存在する場合、現在のHTTP応答をポリシーファイルにすることはできませんが、それ以外のメタポリシーはサーバ全体に対するメタポリシーとして解釈されます。xmlに置かれたマスターポリシーファイルのみが許可されます。xml」で終わるポリシーファイルのみが許可され、他のポリシーファイルは許可されません。all:すべてのポリシーファイルが許可されます。この設定は、ログイン資格情報を必要としないパブリックなインターネットサーバでのみ使用するようにしてください。
管理者がこれらのコントロールを利用するには、Webのルートディレクトリに次の例のようなcrossdomain
xmlファイルを作成します。
ポリシーファイルのチェックの開始
この節で説明した内容についてさらに詳しく知りたい場合は、Adobe LiveDocsの次のページが役に立ちます。urlに対応するデフォルトの場所からポリシーファイルのダウンロードを試みます。
イメージコンテンツにアクセスする例としては、Bitmapオブジェクトを取得するためにLoader
draw()メソッドを呼び出す場合などがあります。セキュリティエラーを防止するためにポリシーファイルをチェックする方法のコード例を次に示します。
関連する脅威:DNSリバインディング、クロスドメイン権限の昇格
この節では、ソケットポリシーファイルの概要について簡単に説明します。0)についての記事のソケットポリシーファイルの節を参照してください。ソケットポリシーファイルは、ドメインに対して許可されるソケット接続を定義します。ソケットポリシーファイルは、ポート843で待機しているソケットポリシーファイルサーバか、目的の接続と同じポートでホストされる必要があります。このファイルは、クロスドメインファイルと同様に、ポリシーファイルが許可されるサーバ上の場所を定義するメタポリシーをサポートしています。使用できるメタポリシーは以下のとおりです。all:このホスト上のすべてのポートのソケットポリシーファイルが許可されます。このメタポリシーは、ログイン信用情報を必要とするコンテンツを提供しないインターネット上のホストにのみ適用できます。デフォルトではこれが選択されます。master-only:ポート843から提供されるソケットマスターポリシーファイルのみが、このホスト上で許可されます。none:このホスト上ではソケットポリシーファイルは許可されません。このメタポリシーがマスターポリシーファイルで宣言されている場合、マスターポリシーファイルはこのメタポリシーを宣言するためだけに存在することができます。ソケットポリシーファイルは、HTTPポリシーファイルと同様のsecureフラグをサポートしています。デフォルトでは、このフラグはfalseであると見なされます。ソケットポリシーファイルは安全でないプロトコル経由で取得され、man-in-the-middle攻撃の標的となる可能性があるので、現時点ではリモートソケットにこのフラグを使用することはあまりお勧めできません。通信中に攻撃者がこのフラグの値を変更する可能性があります。
ポートアクセスを定義するソケットポリシーファイルでの範囲とコンマの使用
ワイルドカードを使用してポートアクセスを定義する代わりに、Flash Playerでは、範囲とコンマを使用してポート番号のグループを指定できます。
ドメインを越えるSWF間の通信
関連する脅威:クロスドメインの権限の昇格、悪意のあるデータのインジェクション、送信中のデータに対する無許可のアクセス、承認の不適切な制限
Flash Playerには、開発者の必要に応じて、SWFファイル間の通信を行うための方法がいくつか用意されています。それぞれの方法に、クロスドメイン通信の機能があります。どの方法が適しているかは、使用事例のシナリオと、2つのドメイン間にどの程度の信頼関係があるかによって異なります。ソリューションは、直接通信と、共通のリソースを使用する通信に分けられます。直接通信を行う方法では、対象のSWFファイルが送信側によってロードされる必要があります。通信のための共通のリソースを作成した場合は、ロード操作は不要であり、複数のSWFファイル間で通信を行うことができます。一般的な方法のリストと、その機能およびセキュリティに関して考慮する必要がある事項を以下に示します。ロードされたリモートSWFは、元のドメインに対してクロススクリプトを実行できません。リモートSWFは、ロードする側のドメインにある任意のSWFに対してクロススクリプトを実行できます。アクセスは、1つのローダーにつき2つのクロスドメイン通信に制限されます。ドメイン間のクロススクリプトのための一方向通信です。リモートドメイン上のすべてのSWFファイルが、アクセスを許可された特定のSWFに対してクロススクリプトを実行できます。両方のSWFファイルで、元のドメインへのアクセスが維持されます。同じドメインのSWFファイル間では自動的にクロススクリプトを実行できます。これは、読み込みロードされないSWFファイルのための代わりの方法です。
共有リソースの使用による通信