アクセシビリティ
デベロッパーリソース
Deneb Meketa

Deneb Meketa

Adobe

目次

作成日:
2007年12月3日
更新日:
2008年10月28日
ユーザレベル:
中級
製品:
Flash Player

Flash Player 9および10におけるポリシーファイル関連の変更点

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

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

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

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

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

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

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

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

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

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

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

対応済みの問題

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

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

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

その他の改善点

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

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

著者について

Deneb Meketa は Adobe Flash Player チームのエンジニアです。Deneb は自ら現在問題になっているセキュリティの変更を実装しました。セキュリティの問題では深い自責の念に駆られましたが、Deneb 自身その 10 倍以上大変だったことは間違いありません。最近は、週末をサンフランシスコのベイエリアでハンググライダーに乗って過ごすようになりました。