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

目次

  1. はじめに
  2. SWFファイルに対する潜在的な脅威
  3. 安全性の高いコンパイラ設定の選択
  4. HTMLコード内でのセキュリティ制御の設定
  5. リモートコンテンツのロード
  6. 複雑なクロスドメインの実装
  7. ドメインを越えるSWF間の通信
  8. 共有リソースの使用による通信
  9. リモートソースからのデータの検証
  10. テキストフィールドおよび描画可能領域での安全なコンテンツ表示
  11. 例外処理
  12. データの暗号化
  13. 開発者向けチェックリスト

より安全なSWF Webアプリケーションの作成

リモートコンテンツのロード

必要と考えられる最も一般的なタスクの１つは、イメージ、サウンドまたはその他のデータをリモートWebサイトから取得することです。コンテンツが要求元のSWFファイルとは異なるドメインにある場合、Flash Playerはリモートドメインに問い合わせて、ユーザがそのコンテンツへのアクセス許可を持っているかどうかを確認することが必要になる場合があります。以下の節では、アクセス許可が必要とされる状況と、アクセス許可を取得する方法について説明します。

異なるドメインからのコンテンツのロード

関連する脅威：クロスドメイン権限の昇格

デフォルトでは、Flash Playerはブラウザが使用する同一生成元ポリシーに従います。このポリシーは、１つのドメイン内のコンテンツは、同じドメイン名でホストされる他のすべてのコンテンツとデータにアクセスできるというものです。また、サイトは他のドメインのコンテンツを表示できますが、他のドメインに属するデータに直接アクセスすることはできません。たとえば、同一生成元ポリシーでは、www.a.comのコンテンツの一部分から、www.a.comに関連付けられている他のすべてのデータへのアクセスが許可されます。www.a.comサイトに、www.b.comのWebページを表示するインラインフレームを含めることもできます。ただし、同一生成元ポリシーでは、www.a.comがwww.b.comのCookieにアクセスしたり、www.b.comのページ上のJavaScriptとやり取りしたりすることは禁止されています。

Flash Playerは、コンテンツの生成元を定めるために使用する完全ドメイン名をコンテンツのセキュリティドメインと見なします。Flash Playerでは、SWFファイルのドメインはSWFファイルがホストされる場所によって定義されます。www.a.comドメインのWebページにwww.b.comドメインからSWFをロードするobjectタグが含まれている場合、このSWFはセキュリティドメインがwww.b.comによって定義されていると見なします。www.a.comサイトでホストされる他のSWFファイルは、別のセキュリティドメインからロードされているので、これらのSWFファイルは、www.b.comサイトからロードされたSWFにフルアクセスすることはできません。Flash Playerでは、ドメイン名を完全に一致させます。したがって、www.a.comドメインはhome.a.comドメインとは異なるセキュリティドメインと見なされます。また、Flash Playerは、HTTPS経由でwww.a.comからロードされたコンテンツと、HTTP経由でwww.a.comからロードされたコンテンツをそれぞれ別のセキュリティドメインに分離します。

ブラウザとは異なり、Flash Playerには、複数のドメイン名を含めるように同一生成元の保護を拡張するメソッドが用意されています。したがって、www.a.comサイトの所有者は、サイトのコンテンツをhome.a.comドメインと共有できることをFlash Playerに通知することができます。これにより、複数のドメイン名を使用するWebサイト所有者は、サイト間でやり取りすることが可能になります。これらのメソッドの多くは、開発者が外部とデータを共有できるようにワイルドカードの使用をサポートしています。セキュリティの観点からワイルドカードは慎重に使用する必要があります。ワイルドカードを使用すると、データへのアクセスをすべてのユーザに許可することになるからです。

IPアドレスを使用して１つのドメイン名を２つのセキュリティドメインに分ける

多数のドメイン名を１つのセキュリティドメインに組み込むだけでなく、１つのドメイン名を２つのセキュリティドメインに分けることもできます。これは、使用できるドメイン名が１つしかないときに、２つの異なる信頼レベルでSWFファイルを使用する場合に必要となることがあります。これを実現するために、Flash Playerではドメイン名をIPアドレスに関連付けないという点を利用できます。

www.example.comサイトがIPアドレス1.2.3.4でホストされている場合、Flash PlayerはURL http://www.example.com/my.swfによってロードされたSWFを、URL http://1.2.3.4/my.swfによってロードされたSWFとは別のセキュリティドメインに属するものと見なします。この方法は、サイトで信頼できないユーザにSWFファイルのアップロードを許可する場合に役立ちます。サイト所有者は、ユーザがアップロードした悪意のあるSWFファイルよるアクセスからサイトのSWFファイルを保護する必要があります。そのため、サイト所有者は、URLのドメイン名を使用して信頼できるSWFファイルを参照し、URLに含まれるIPアドレスを使用して、ユーザが送信した悪意のある可能性があるSWFファイルをロードすることができます。

クロスドメインファイルの実装

関連する脅威：クロスドメイン権限の昇格、承認の不適切な制限

crossdomain.xmlファイルの使用方法を調べる場合は、Adobe LiveDocsの「アクセス許可管理の概要」、およびFlash Playerデベロッパーセンターの「Cross-domain policy file usage recommendations for Flash Player*」を参照してください。

クロスドメインファイルは、複数のドメイン名を同じ生成元に属するものと見なすことを許可するように同一生成元ポリシーを拡張する１つの方法です。クロスドメインポリシーファイルは、このファイルをホストするサーバに、サーバのコンテンツをクロスドメインファイルに示されたドメインと同じ生成元に属するものと見なしてよいことを認識させる方法です。ポート80または443のWebサーバから提供されるクロスドメインファイルは、HTTPポリシーファイルと見なされ、Web要求のポリシーを制御できます。他のポートからホストされるクロスドメインファイルは、ソケットポリシーファイルと見なされます。ソケットポリシーファイルについては、後ほど説明します。

crossdomain.xmlファイルを使用して、HTTPサーバへのアクセスに関する次の３つの側面を指定できます。

  • サーバの同一生成元に属していると信頼できるドメイン。
  • リストされたドメイン名について、HTTPコンテンツとHTTPSコンテンツ間の通信を許可するかどうか。
  • ポート1024より大きいポートへのソケットアクセスを暗黙的に許可する（Flash Playerの今後のバージョンでは、この機能は削除される予定です）。

コンテンツ配信者は、これらのクロスドメイン制御を利用できます。クロスドメイン制御は、Webサイト全体に適用することも、一部分だけに適用することもできます。また、SWFファイルの作成者は、後述するSecurity.allowDomain()メソッドを使用してクロスドメイン制御を定義できます。Security.allowDomain()メソッドを使用すると、クロスドメインのアクセス許可をファイルごとに付与できます。

ほとんどのブラウザと同様に、Flash Playerではクロスドメインのデータ送信は防止されないことに注意してください。Flash Playerが防ごうとするのは、クロスドメインのデータのロードだけです。home.a.comのWebサイトで、Flash Playerに応答を返さないメソッドを使用してwww.a.comに対してデータのHTTP POSTを実行する場合、クロスドメインファイルは必要ありません。home.a.comのSWFが要求の応答データにアクセスする必要がある場合は、クロスドメインポリシーファイルが必要です。

crossdomain.xmlファイルを使用する必要があるいくつかの状況を以下に示します。

  • Bitmap.draw()やLoader.contentなどを使用して、別のドメインのムービーまたはイメージに対してイメージの抽出を実行する必要がある場合
  • 別のドメインからロードされたサウンドに対してサウンドデータの抽出（ID3InfoやcomputeSpectrumなど）を実行する場合
  • イメージを別のドメインからHTMLテキストフィールドにロードする場合
  • ソケットがポート1024より大きいポートに接続することを許可する必要がある場合
  • 別のドメインによるAPI呼び出し（LoadVars、URLLoader、XML.loadなど）によってデータを直接ロードする場合
  • Web管理者がサイトに対するクロスドメインのすべてのロード要求を明示的にブロックする場合
  • リモートHTTPサーバ上のSWFが、サーバのWebサイトのHTTPSで保護されたセクション内からデータをロードする必要がある場合

次の場合は、crossdomain.xmlファイルを使用する必要はありません。

  • 別のドメイン内のものにアクセスせずに、そのドメインからロードしたイメージを子として表示する場合
  • ビデオデータやサウンドスペクトルデータへのアクセスを試みずにRTMPサーバのデータを表示または再生する場合
  • ローダーと同じドメインからイメージをロードする場合
  • SWF間通信のクロスドメインのアクセス許可がSecurity.allowDomain()によって制御されているときにSWFファイルをロードする場合

リモートコンテンツをSWFファイルに正常にロードするには、リモートドメインでコンテンツのディレクトリまたはその親ディレクトリにcrossdomain.xmlファイルを配置する必要があります。Flash Playerは、新しいリモートドメインへの要求を作成する前に、allowNetworkingの設定でリモートドメインへのアクセスが許可されていることを確認します。次に、Flash Playerは、現在のドメインがリモートドメインのコンテンツをロードすることを許可されているかどうかを確認するために、crossdomain.xmlファイルを要求する必要があります。現在のドメインがcrossdomain.xmlファイルに示されていない場合、またはこのファイルが存在しない場合には、コンテンツへのアクセスは拒否され、データにアクセスしようすると例外がスローされます。

クロスドメインファイルを使用すると、アクセスをグローバルかつ明示的に拒否することができます。クロスドメインファイルが存在しない場合にも、アクセスは拒否されます。また、すべてのユーザに対してアクセスを明示的に拒否するには、エントリを含まないcrossdomain.xmlファイルをルートディレクトリに作成し、次のようにnoneに設定したサイト制御ポリシーを作成します。

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "/xml/dtds/cross-domain-policy.dtd">
<!-- Policy file for mysite.com -->
<cross-domain-policy> 
 <-- No one can have raw access to any of the content on this site through Flash Player -->
 <-- This is the only cross-domain policy file on this server -->
  <site-control permitted-cross-domain-policies="none" />
</cross-domain-policy>

クロスドメイン要求に関連するリスク

クロスドメインポリシーファイルの要求に関連するリスクがいくつかあります。たとえば、www.example.comで、Cookieを使用してWebサイトの機密領域に対する認証と許可を追跡しているとします。Webサイトの管理者がallow-access-from domain設定をグローバルなワイルドカード（"*"）に設定して、すべてのサイトアクセスを許可するクロスドメインポリシーを導入しました。この設定により、Webサイトは同一生成元の制限がサイトに適用されないことをFlash Playerに通知します。そのため、リモートドメインの悪意のあるSWFにも、www.example.com内のすべてのデータとコンテンツへのアクセスが許可されることになります。Webブラウザは、Flash Playerによって作成されたHTTP要求に既存のCookieを追加するので、リモートドメインのSWFは、機密情報が含まれたWebサイトの領域への要求を作成できます。悪意のあるSWFは、応答で返されたデータを取得し、元のWebサイトに返送することができます。

内部ネットワーク上に過度のアクセス許可を設定したクロスドメインファイルが存在すると、この脅威が拡大するおそれがあります。たとえば、内部IT担当者が、ホストが内部ネットワーク上にあり、すべてのユーザが内部ネットワーク上で信頼されていると考えて、domain="*"を設定したクロスドメインファイルを作成する可能性があります。クロスドメインポリシーファイルは、ホストが信頼してそのデータを委ねるドメインを示すものです。したがって、IT管理者が作成したクロスドメインポリシーファイルは、内部ホストがインターネットサイトを含むすべてのサイトを信頼してそのデータを委ねることを示していることになります。そのため、ブラウザによって外部WebサイトからロードされたSWFは、内部Webサイトへの要求を作成し、その情報を中継してインターネットに送信することが許可されます。

クロスドメインでのアクセスを調整する

クロスドメインのアクセス許可は多数のリスクを伴うため、管理者はさまざまな制御を使用して、コンテンツへの詳細なアクセス許可を付与できます。次のような制御を使用できます。

  • 共有可能なコンテンツをあるサブドメイン（public.mysite.com）に配置し、共有できないコンテンツを別のサブドメイン（private.mysite.com）に配置する。
  • ワイルドカードを静的なドメイン情報と共に使用して、アクセス許可のスコープを制限する。
  • サブディレクトリに基づいてアクセス許可を付与する。
  • メタポリシーを使用して、未承認のクロスドメインポリシーファイルを防ぐ。
  • HTTPS経由でロードされたSWFにのみアクセス許可を付与する。

次の各節では、過度のクロスドメインアクセス許可の作成を回避するためのこれらの手法について詳しく説明します。

ワイルドカードをドメイン名と組み合わせて使用する

ドメインに頻繁に変更される複数のサブドメインが含まれている場合、管理者はワイルドカードを親ドメイン名と組み合わせて使用できます。つまり、domain= "*"ではなく、domain="*.mysite.com"を指定できます。次のサンプルは、"*"ワイルドカードに代わる方法を使用したcrossdomain.xmlファイルの有効なエントリを示しています。

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "/xml/dtds/cross-domain-policy.dtd">
<!-- Policy file for mysite.com -->
<cross-domain-policy>
  <!-- This is the only cross-domain policy file for this server -->
  <site-control permitted-cross-domain-policies="master-only"/>
   <!— Administrators can set multiple entries with a wildcard on the sub-domain to     avoid setting domain="*"  -->
   <allow-access-from domain="*.mysite.com" />  
       <allow-access-from domain="*.myothersite.com" /> 
</cross-domain-policy>

SSLの一貫した使用

関連する脅威：送信中のデータに対する無許可のアクセス

Flash Playerバージョン７以降では、HTTP経由でロードされたSWFがHTTPS経由で提供されるリソースにアクセスすることを防ぐ制限が設けられています。HTTPS経由でロードされた信頼できるSWFファイルに安全に伝達された機密データに、HTTP経由でロードされた信頼性のないSWFファイルがアクセスするのを防ぐために、これらの制限がデフォルトで設定されています。HTTP経由でロードされたSWFファイルは、man-in-the-middle攻撃の対象となるので信頼できません。man-in-the-middle攻撃とは、ネットワーク上でエンドユーザとサーバとの間に割り込んだ第三者が、SWFファイルの送信中にファイルの内容を変更したり、ファイルを置き換えたりするものです。man-in-the-middle攻撃は、ワイヤレスネットワークをはじめとするさまざまな場所で頻繁に実行されます。

データを確実に保護するために、すべてのデータをHTTPS経由でロードするSWFアプリケーションを作成しているWebサイトもあります。ただし、このようなWebサイトで、HTTP経由の初期SWFアプリケーションをロードすることでユーザ操作が開始されると問題が発生します。Flash Playerは、FlashアプリケーションがHTTPSを使用していることをエンドユーザにフィードバックしないので、エンドユーザは情報が保護されていることを確認できません。また、初期FlashアプリケーションはHTTP経由でロードされるので、man-in-the middle攻撃の対象となります。そのため、エンドユーザはSWFファイルを信頼することができません。SSLを使用してデータを保護することを予定している場合は、アプリケーション全体にわたりSSLを一貫して使用する必要があります。これにより、ユーザはセキュリティで保護された通信によってSWFを受信できます。また、セキュリティ保護されていないプロトコルとセキュリティ保護されたプロトコルが混在することによって生じる問題を開発者が回避する上でも役立ちます。

HTTP SWFファイルとHTTPS SWFファイルの通信を許可しないようにする

crossdomain.xmlファイルでドメインの「secure」フラグを「false」に設定するか、SWF内でallowInsecureDomainメソッドを使用することにより、これらの保護を無効にすることができます。ただし、この方法は推奨されません。HTTP SWFファイルからHTTPSで保護されたデータへの通信を許可することがどうしても必要な場合は、HTTP経由でロードされたSWFファイルに対してHTTPSで保護されたデータを公開するときに制限を課すようにします。たとえば、crossdomain.xmlファイルでsecure="false"を設定し、サイトのすべてのデータを公開するのではなく、HTTPS経由でロードされたSWFファイル内のLocalConnectionでallowInsecureDomainを設定し、HTTP経由でロードされたSWFファイルからのアクセスを制御できるようにする方がよい場合もあります。

安全ではないHTTPS接続

Flash Playerでは、ブラウザのSSL実装を使用してHTTPS要求の作成をサポートします。したがって、SWFが接続しているサーバに証明書に関する問題（期限切れの証明書やドメイン名の不一致など）がある場合、ブラウザは問題についてユーザにプロンプトを表示することで処理します。ユーザが安全かつシームレスに操作できるように、開発者はWebサイト管理者と協力して、SSL証明書が最新の状態であること、信頼されている証明機関によって署名されていること、およびホストのドメイン名と一致していることを確認する必要があります。

secureフラグを使用してSSL保護を確保する

デフォルトでは、crossdomain.xmlファイルはsecureフラグを使用して、HTTPサーバ上でホストされたSWFがHTTPSで保護されたサイトから提供されるデータにアクセスするのを防ぎます。secureフラグのデフォルト値は「true」です。この場合、リモートHTTP経由でロードされたSWFファイルが、WebサイトのHTTPSで保護された領域のコンテンツにアクセスすることを許可しないようプレイヤーに通知されます。本来SSLによって保護されていたデータをHTTP経由でリモートサーバに送信すると、SSL接続によってそのデータに提供されていたすべての保護が無効になる可能性があります。secureフラグは、Webエントリに適用することも、ソケットポリシーエントリに適用することもできます。

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "/xml/dtds/cross-domain-policy.dtd">
<!-- Policy file for mysite.com -->
<cross-domain-policy>
   <!-- This is a master-policy file -->
   <site-control permitted-cross-domain-policies="master-only"/>
   <!-- This says that http://www.mysecuresite.com can access this site's HTTP data -->
   <!-- SWFs on https://www.mysecuresite.com can access this site's HTTPS data -->
   <!-- SWFs on http://www.mysecuresite.com can not access this site's HTTPS data -->
       <allow-access-from domain="www.mysecuresite.com" secure="true" />
</cross-domain-policy>
ページ 5 / 13
前のページ
次のページ