アドビ システムズ社は、Adobe Flash Playerのセキュリティ面を強化するために、2008年４月８日にFlash Player 9のセキュリティアップデート版であるFlash Player 9,0,124,0をリリースしました。今回のアップデートは、これまでに明らかになっているFlash Playerの脆弱性を軽減するものです。対象となるのは、DNSリバインディング攻撃やクロスドメインポリシーファイル脆弱性 （セキュリティ速報 ABSP07-20） 、SWF内でのクロスサイトスクリプティング脆弱性（セキュリティ情報 APSA07-06 ） です。今回のセキュリティ強化の実施により、既存のFlashコンテンツに影響を及ぼす可能性があります。

コンテンツ提供者の方々は、４月のセキュリティアップデータ内容に目を通して自身のコンテンツに影響があるかどうかをチェックし、もし影響がある場合にはスムーズに移行できるように、当記事で紹介している対応手順に沿ってご自身のSWFファイルへの対応をお願いいたします。この記事では、４月のセキュリティアップデータ内容の概要を説明し、関連した情報へのリンクを紹介しています。

以下の状況に当てはまる方は、該当記事を読んでください。

• XMLSocket や Socket を使用している。

• クロスドメインでデータ送受信する際のネットワークAPIでaddRequestHeaderやURLRequest.requestHeadersを使用している。

  あるいは、

  Webサービス提供者としてリモートドメイン上のコンテンツへのアクセスを許可している。

• Flash Playerバージョン7以前の形式で書き出したSWFファイルが、ホストとなるHTMLファイルとコミュニケーションを行っている。
• ネットワークAPIを介して外部のSWFとコミュニケーションをとる際に「javascript:」を使用している。

アドビ システムズ社ではセキュリティ情報を随時公開しており、そのお知らせをメールで受け取ることが可能です。メールの購読は、「 Security Notification Service*」から登録できます。

すべてのソケット接続において、常にソケットポリシーファイルが必要となる

2007年12月に行われたFlash Player 9,0,115,0のセキュリティアップデート時にはソケットポリシーファイルに関する変更が行われましたが、その変更への対応はコンテンツ提供者の任意によるオプション的なものでした。今回のセキュリティアップデートではこの変更への対応が義務化となります。ソケットポリシーファイルは、ソケット接続時に利用するポリシーファイルです。Flash Player 9,0,115,0では、ソケットメタポリシーのデフォルト設定が「all」でしたが、今後のバージョンでは「none」となります。

Flash Playerには2つのタイプのポリシーファイルがあります。1つはHTTPポリシーファイル。これはサーバ上に置く「crossdomain.xml」ファイルで、他のドメインのSWFがそのサーバ上のコンテンツをロードできるかどうかを定義するためのポリシーファイルです。もう1つはソケットポリシーファイルで、Flash PlayerがXMLSocket や Socket を通して接続する際に使用するポートを定義するものです。今後のセキュリティアップデートでは、HTTPポリシーファイルを利用したソケットアクセスができなくなり、またソケットポリシーファイルに関 するルールの変更が行われます。

今回の変更は「DNS強化」を行い、ActionScriptが不当なソケット接続によるDNSリバインディング攻撃（セキュリティ速報ABSP07-20参照）に利用されるのを避けるためのものです。Flash Player 9,0,115,0では、ソケットポリシーファイルを実装するかどうかはコンテンツ提供者に委ねられており、実装しなくてもFlash Playerのデバッグバージョンで警告が表示されるだけでした。今後のセキュリティアップデートでは、これらの警告はコンテンツのエラーとなり、古いソケットポリシールールに沿ったSWFファイルは機能しなくなる可能性があります。

なお、Flash Player 9,0,115,0では以下のコンセプトが導入されました。

• ソケットマスターポリシーファイル：このファイルは固定のTCPポート番号843から提供されます。ポート番号を固定しているのは、ホストからソケットポリシーファイルを提供する際に標準的なポートを使用し、管理しやすくするためです。
• ソケットメタポリシー：これは「ポリシーに対するポリシー」です。ソケットメタポリシーを使用することで、サーバ管理者はサーバ上にあるどのファイルが許可されたソケットポリシーファイルなのかを指定することができます。
• 厳密なソケットルール：ソケット接続時にソケットポリシーファイルを必須とするルールのことです。

＜影響を受ける状況＞

以下の状況においてXMLSocket や Socketを利用しているコンテンツすべてに影響があります。

• SWFが、Webサーバのルートディレクトリにあるcrossdomain.xmlファイルを利用して、同じホストの1024以上のポート番号を使ってソケット接続を行っている。
• SWFが、自身のホストにXMLSocket や Socket接続を行う際、ソケットポリシーファイルの読み取りにloadPolicyFileを実行していない。
• SWFが、自身のホストにXMLSocket や Socket接続してポリシーファイルをロードするが、そのポリシーファイルの許可ドメインリスト内に自身のドメインが含まれていない。

＜対策方法＞

該当するコンテンツ提供者はまず、Flash Player 9,0,115,0で導入されたソケットポリシーファイルの内容を把握するためにFlash Playerデベロッパーセンターの記事「セキュリティに関するFlash Player 9の変更点」のソケットポリシーファイル項目を読んでください。自分のサイトが該当するかどうかを調べる方法は、文書番号 (233457) Flash Player バージョン 9.0.115.0 以降でソケットが機能しないで詳しく解説しています。

この変更をオプション的に採用しているFlash Player 9,0,115,0のユーザーがいることを考えると、彼らをDNSリバインディング攻撃から守るためにも、ホスト管理者の方には素早い対応を期待します。

この義務化された変更に対応するには、ホストソケットへの接続を許可するソケットポリシーファイルを作成する必要があります。このソケットポリシーファイルは、ソケットマスターポリシーのポート番号843か、ソケット接続の行き先となるポート番号から提供されます。ソケットポリシーファイルには、ソケット接続を許可するすべてのドメインが含まれていなければなりません。もちろん、自身のドメインもです。ソケットマスターポリシーファイルでソケットポリシーファイルを提供する場合は、必ずソケットポリシーファイルを配置する範囲を記したメタポリシーを含めるようにしてください。また、Flash Playerがポリシーファイルのロード場所を検知しているかどうかを調べるためにloadPolicyFileを実行してみることも大切です。自身のコンテンツに対策を施したら、文書番号233457にある方法で適切に行われいているかどうかを確かめてください。

ドメイン間でヘッダを送信するにはポリシーファイルが必須

現時点のFlash Playerのバージョンでは、SWFはGETやPOSTリクエストにおいて任意のHTTPリクエストヘッダを設定することが可能です（ただし、ブラックリストのヘッダは除く）。 4月のセキュリティアップデートでは、新しいセキュリティ機能が追加され、SWFが他のドメインにヘッダを送信する前にクロスドメインポリシーファイルによるチェックが行われます。これにより、他のドメインのコンテンツから送られてくる悪意あるHTTPヘッダからWebサイトを守るようにします。また、UPnP問題の可能性を軽減するための機能でもあります。UPnP問題とは、ルータが予期せぬヘッダ値を的確に処理できなくなることです。

SWF が他のホストにヘッダを送信できるようにするには、SWF自身のホストがヘッダを送るホストからポリシーファイルの形式に沿って明確な許可を得なければなりません。 既存のポリシーファイルモデルでも、同じファイルロケーションやActionScript APIを使えば利用することもできますが、新しいシンタックスが必要となります。header-sendingを正しく指定するには、<allow-http-request-headers-from>という新しいタグを使用します。

引き続きFlash Playerでは、ブラックリスト以外のヘッダであればSWFのホストへの送信を許可し、必要に応じてブロックリストへと登録していきます。今回の新しいセキュリティ機能の結果、クロスドメインポリシーファイルのルールに則っていれば、Flash Player 9,0,115,0のブラックリストに追加されたHTTPヘッダはブラックリストから除外されます。

＜影響を受ける状況＞

以下の状況において影響があります。

• ActionScript 2.0のXML.addRequestHeaderやLoadVars.addRequestHeaderメソッド、あるいはActionScript 3.0のURLRequest.requestHeadersプロパティを使って、他のドメインやホストにカスタムHTTPヘッダを送信しているアプリケーション。
• 他のドメインにホストされているFlashベースのアプリケーションにサービスを提供しようとしているWebサービス。
• Flash Player 9,0,115,0で導入されたHTTP認証ヘッダの制約によって影響を受けるアプリケーション。

＜対策方法＞

該当するコンテンツ提供者は、ヘッダの送信先であるサイト上のヘッダポリシータグがポリシーファイルに含まれるようにしてください。また、crossdomain.xmlポリシーファイルをサーバのドキュメントルート以外のディレクトリに置いている場合は、loadPolicyFileを呼び出すActionScriptを追加してSWFを再バブリッシュしてください。

アドビ システムズ社としては、今後行われるクロスドメインポリシーファイルの変更に備えて、crossdomain.xmlファイル内にメタポリシータグを含めておくことを強くおすすめします。Flash Player 9,0,115,0では、メタポリシーファイルはオプション的な扱いでしたが、将来的には義務化となり、従っていないコンテンツはセキュリティエラーとなります。

新しいクロスドメインポリシーファイルタグやシンタックス、それによって影響を受けるAPIについての詳細情報は、文書番号 233450 Flash Player から任意のヘッダがリモートドメインに送信されない（Flash Player 9）を見てください。

allowScriptAccessのデフォルトは常に「sameDomain」

バージョン7以前の形式で書き出されたSWFに対して、パラメータが不明なときに使用されるallowScriptAccessのデフォルト設定が「always」から「sameDomain」へと変更されます。この変更により、古いバージョンで書き出されたSWFの挙動が、現在のセキュリティモデルに対応するようになり、結果としてデフォルト状態でよりセキュリティが確保されるようになります。allowScriptAccessの許可メカニズムでは、<object>や<embed>タグのHTMLプロパティを使って、SWFが同じHTML上にあるJavaScriptコードを呼び出す機能をコントロールしています。セキュリティ情報APSA07-06にあるように、古いバージョンのSWF向けのallowScriptAccessのデフォルト設定が「always」となっていると、サイトがクロスサイトスクリプティングの攻撃にさらされる可能性があるのです。

＜影響を受ける状況＞

fscommand()やgetURL("javascript:...")を使っているコンテンツで以下の状況に当てはまる場合は影響を受ける可能性があります。

• SWFがバージョン7以前の形式で書き出されている。
• SWFを読み込むHTMLの<object>/<embed>内でallowScriptAccessパラメータの値を指定していない。
• HTMLとSWFが異なるドメイン、あるいは同じドメイン内でも異なるホストネームから提供されている。たとえば、HTMLはwww.mysite.com にあり、www.anothersite.comや content.mysite.comにあるSWFを読み込んでいる。
• SWFのActionScriptコードがHTML内のJavaScriptコードを呼び出す際に、fscommand()やgetURL("javascript:...")を使用している。

また、以下のケースも影響を受ける可能性があります。

• バージョン8以降の形式で書き出されたSWFであっても、リモートで読み込むSWFがバージョン7以前の形式で書き出されている。
• HTMLなしにSWFをホストしている。

＜対策方法＞

対策方法としては、まず問題が起きそうなHTMLページでallowScriptAccess="always"を指定します。もし、HTMLページなしにSWFをホストしているサイトは、Flash Playerをより低い特権モードで実行させるためにHTMLを用意してください。

ただ、この設定ではSWFやそれが読み込むSWFすべてが、HTMLファイル内のJavaScriptコードを実行することができてしまいます。もし、あなた自身がSWFを管理して いるならば、この許可設定を行ってもいいでしょう。ただし、SWFやそれが読み込むSWFを管理していないのであれば、「allowScriptAccess="always"」によってあなたのHTMLが悪用される可能性がないかどうか慎重に検討してください。

「javascript:」 系URLはネットワーキングAPIでは使用禁止、ただし、getURL()や navigateToURL()とHTMLテキストフィールドは例外

コンテンツ制作者が意図しないスクリプトが実行されるのを防ぐために、ブラウザインタラクション用に設計されたAPI以外のものは、「javascript:」系URLを利用することができなくなります。ただし、getURL()とnavigateToURL()は例外として使用し続けることが可能となります。

もともとすべてのネットワーキングAPTにおいて「javascript:」系URLを使用することは想定されていません。今回の変更は、禁止にすることでより髙いセキュリティを確保するためのものです。このタイプの問題で引き起こされる脆弱性の例として、Loader.load()を呼び出すように設計されたSWFを想定してください。このSWFは、クエリ文字列パラメータによってURLを外部から渡される可能性があります。デベロッパーは「http:」系URLしか渡されないと思いこんでしまいがちですが、攻撃者から「javascript:」系URLを渡されることもあり得るのです。この手の攻撃を防ぐには、 入力検証*を行うのが一番の防御策ですが、意外と忘れられています。

セキュリティ情報APSA07-06にあるように、ネットワークAPIに関する今回の変更によって、不適切な入力検証にから引き起こされるクロスサイトスクリプティング攻撃を軽減することができます。

＜影響を受ける状況＞

ネットワーキングAPIで「javascript:」系URLを使用しているコンテンツは影響を受けます。なお、ここでいう「javascript:」系URLには「vbscript:」も含まれています。

＜対策方法＞

「javascript:」系URLの使用が禁止されているネットワーキングAPIで「javascript:」系URLを使用している場合は、コンテンツを書き換える必要があります。今後、JavaScriptとActionScriptとの間でコミュニケーションを行う際は、ExternalInterfaceクラスを使用することをおすすめします。

また、デベロッパーのみなさんは、よりセキュアなコードの開発に向けて、ぜひFlash Playerデベロッパーセンターの記事「Creating more secure SWF web applications*」に目を通してください。

著者について