のセキュリティサンドボックスUnity3.0では、WebplayerはAdobe Flash player™で使用されるものと非常によく似たセキュリテ このセキュリティ制限は、webplayerにのみ適用され、アクティブなビルドターゲットがWebPlayerの場合はエディターにも適用されます。 セキュリティモデルにはいくつかの部分があります:
- あなたをホストしているもの以外のドメイン上のデータへのアクセスの制限。ファイル：example.unity3d
- ソケットの使用に関するいくつかの制限。
- 私たちが立ち入り禁止と判断したメソッドの呼び出しを禁止します。 （ファイルのようなもの。削除など）。
- システムの使用を許可しません。反射。*クラス内のprivate/internalメソッドを呼び出すには、自分で書いていません。
現在、セキュリティモデルの最初の2つの部分のみがエディタでエミュレートされています。
Unityの組み込みマルチプレイヤーネットワーキング機能(UnityEngine.Network、UnityEngine.NetworkViewクラスなど)は影響を受けません。
このドキュメントでは、コンテンツがUnity webplayerのバージョン3.0で動作し続けるようにする方法について説明します。
- WWWクラスの詳細については、Unity APIリファレンスを参照してください。
- .NET Socketクラスの詳細については、.NET APIリファレンスを参照してください。
WWWクラスとソケットは同じポリシースキーマを使用しますが、それ以外は完全に別々のシステムです。 WWWポリシーは、ポリシーがホストされているwebサービスのアクセス許可のみを定義しますが、ソケットポリシーはすべてのTCP/UDPソケット接続に適用されます。
Unityエディタには、webplayerのセキュリティモデルを強制する”Webセキュリティのエミュレート”機能が付属しています。これは、エディタの快適さから問題を検出することが容易になります。 この設定は、Edit->Project Settings->Editorで確認できます。 エディタの設定も参照してください。
Unity webplayerは、crossdomain.xmlという名前のhttpサービスポリシーファイルがWWWクラスでアクセスするドメインで利用できることを期待しています（ただし、unity3dファイルをホ
たとえば、次のurlでホストされているテトリスゲームを想像してみてください:
http://gamecompany.com/games/tetris.unity3d
次のurlからハイスコアリストにアクセスする必要があります:
http://highscoreprovider.net/gethighscore.php
この場合、crossdomain.xmlファイルをファイルのルートに配置する必要があります。highscoreprovider.net このようなドメイン: http://highscoreprovider.net/crossdomain.xml
crossdomain.xmlファイルの内容は、Flash playerで使用される形式です。 すでに場所にあるcrossdomain.xmlファイルを見つける可能性が非常に高いです。 ファイル内のポリシーは次のようになります:
<?xml version="1.0"?><cross-domain-policy><allow-access-from domain="*"/></cross-domain-policy>このファイルがhttp://highscoreprovider.net/crossdomain.xmlに置かれると、そのドメインの所有者は、webサーバーの内容が任意のドメインから来る任意のwebplayerによってアクセスされる可能性があるUnity webplayerは、<allow-http-request-headers-from domain>および<site-control allowed-cross-domain-policies>タグをサポートしていません。 crossdomain.xmlはASCIIファイルでなければならないことに注意してください。
デバッグ
環境変数ENABLE_CROSSDOMAIN_LOGGINGを1に設定すると、Unityランタイムがcrossdomain.xmlファイルをフェッチしてデコードするときにコンソールメッセージが生成されます。 Macでは、/etc/launchd.confでグローバル環境変数を設定できます。 PCの使用コントロールパネル->システムとセキュリティ->システム->高度なシステム設定->環境変数…
webplayerがリモートサーバーからイメージを取得しようとすると、こ:
Determining crossdomain.xml location for request: http://www.remoteserver.com/image.jpgAbout to parse url: http://www.remoteserver.com/image.jpgDetermining crossdomain.xml location for request: http://www.remoteserver.com/image.jpgAbout to parse url: http://www.remoteserver.com/crossdomain.xmlAbout to parse url: http://www.remoteserver.com/image.jpgDetermining crossdomain.xml location for request: http://www.remoteserver.com/image.jpgDownload had OK statuscodeReceived the following crossdomain.xml--------------------------------------<?xml version="1.0"?><cross-domain-policy><allow-access-from domain="*"/></cross-domain-policy>----------------------received policyParsing: cross-domain-policycross-domain-policyParsing: allow-access-fromallow-access-from domain: *done parsing policycrossdomain.xml was succesfully parsedAbout to parse url: http://www.remoteserver.com/image.jpgChecking if http://www.remoteserver.com/image.jpg is a valid domainChecking request-host: www.remoteserver.com against valid domain: *All requirements met, the request is approvedエディタで実行すると、これらのメッセージがエディタに書き込まれます。ログ… 誤ってutf16として格納されているcrossdomain.xmlファイルをBOMで読み取ろうとすると、xmlの解析に失敗します:
BuildFlashPolicy caught an exception while parsing http://www.remoteserver.com/crossdomain.xml: Expected elementこれは、BOMが期待されていないためです。 サポートされていないutf16ファイルをBOMなしで使用すると、次のようになります:
BuildFlashPolicy caught an exception while parsing http://www.remoteserver.com/crossdomain.xml: Policy can't be constructed from empty stream.これは、ファイルの最初のバイトがゼロであるため、パーサーはファイルの最後に達したと考えます。 Crossdomain.xmlはASCIIファイルである必要があります。
ソケットの使用への影響:
Unity webplayerは、特定のホストに接続するためにソケット提供ポリシーを必要とします。 このポリシーは、デフォルトではポート843上のターゲットホストによってホストされますが、他のポートでもホストできます。 デフォルト以外のポートとの機能的な違いは、セキュリティを使用して手動で取得する必要があることです。PrefetchSocketPolicy()API呼び出しで、1024よりも高いポートでホストされている場合、ポリシーは1024よりも高い他のポートへのアクセスのみを与えることができます。
デフォルトのポートを使用すると、次のように動作します。Unity webplayerはホストへのTCPソケット接続を試み、最初にホストサーバーがホストへのTCPソケット接続を受connection.It これを行うには、ポート843でTCPソケットを開き、要求を発行し、新しい接続を介してソケットポリシーを受信することを期待します。 Unity webplayerは、ホストのポリシーが接続を先に進めることを許可していることを確認し、そうであればエラーなしで続行します。 このプロセスはユーザーのコードに対して透過的に行われ、このセキュリティモデルを使用するために変更する必要はありません。 ソケットポリシーの例は次のようになります:
<?xml version="1.0"?><cross-domain-policy> <allow-access-from domain="*" to-ports="1200-1220"/> </cross-domain-policy>"このポリシーは、”任意のドメインからのコンテンツは、ポート1200-1220でソケット接続を自由に行うことができます”と Unity webplayerはこれを尊重し、rejectanyがその範囲外のポートを使用してソケット接続を試みました（SecurityExceptionがスローされます）。
UDP接続を使用する場合、TCPと同様の方法でポリシーを強制する必要がある場合にも、ポリシーを自動フェッチすることができます。 違いは、TCPでの自動フェッチは、何かに接続するときに発生します（サーバーへの接続が許可されていることを確認します）が、UDPでは接続がないため、データを送
ソケットポリシーに使用される形式は、一部のタグがサポートされていないことを除いて、Flash playerで使用される形式と同じです。 Unity webplayerは、ドメイン設定の有効な値として”*”のみをサポートし、”to-ports”設定は必須です。
<?xml version="1.0" encoding="ISO-8859-1"?><!ELEMENT cross-domain-policy (allow-access-from*)><!ELEMENT allow-access-from EMPTY><!ATTLIST allow-access-from domain CDATA #REQUIRED><!ATTLIST allow-access-from to-ports CDATA #REQUIRED>ソケットポリシーはTCPとUDPの両方の接続タイプに適用されるため、UDPとTCPの両方のトラフィックを1つのポリシーサーバーで制御できます。
あなたの便宜のために、私たちは単にポート843でリッスンする小さなプログラムを提供しています。サーバーコードは、Unityのインストールフォルダ、WindowsのData/Tools/SocketPolicyServerまたは/Unity内にあります。os X上のapp/Contents/Tools/SocketPolicyServer.それはモノ実行可能ファイルであるため、事前に構築された実行可能ファイルは、Mac上で実行することができることに注意してくださ ただ、”モノsockpol”と入力します。exe”を実行します。 このコード例は、ソケットポリシーサーバーの正しい動作を示していることに注意してください。 具体的には、サーバーは<policy-file-request/>を含むゼロで終了する文字列を受信することを期待しています。 この文字列（および正確にはこの文字列）が受信されたときにのみ、ソケットポリシー xmlドキュメントをクライアントに送信します。 さらに、xmlヘッダーとxml本文は、単一のソケット書き込みで送信される必要があります。 ヘッダーと本文を別々のソケット書き込み操作に分割すると、Unityが不完全なポリシーを受信するためにセキュリティ例外が発生する可能性があります。 あなた自身のサーバーに問題が発生した場合は、私たちが提供する例を使用することを検討してください。 これは、サーバーまたはネットワークの問題があるかどうかを診断するのに役立ちます。
マルチプレイヤーゲームネットワーキングに一般的に使用されるサードパーティのネットワークライブラリは、ピア2ピア機能（下記参照）に依存せず、専用サーバーを利 これらは時々方針を催すためのサポートの箱から出て来る。
注: crossdomain.xmlとソケットポリシーファイルは両方ともxmlドキュメントであり、広く似ていますが、これらのドキュメントの提供方法は非常に異なります。 ソケットポリシーは、<policy-file-request/>を実装する簡単なサーバーを使用してポート843からフェッチされるためです。 Httpサーバーを使用してソケットポリシーファイルを発行したり、ポート843のソケット接続に応答してソケットポリシーファイルを送信するサーバーを設定したり また、接続先の各サーバーには、独自のソケットポリシーサーバーが必要であることにも注意してください。
デバッグ
telnetを使用してソケットポリシーサーバーに接続できます。 セッションの例を以下に示します:
host$ telnet localhost 843Trying 127.0.0.1...Connected to localhost.Escape character is '^]'.<policy-file-request/><?xml version='1.0'?><cross-domain-policy> <allow-access-from domain="*" to-ports="*" /></cross-domain-policy>Connection closed by foreign host.host$このセッション例では、telnetを使用してポート843のlocalhostに接続します。 Telnetは最初の3行で応答し、ユーザーが何かを入力するのを待って座っています。 ユーザーは、ポリシー要求文字列<policy-file-request/>を入力しており、ソケットポリシーサーバーはこの文字列を受信し、ソケットポリシーで応答します。 その後、サーバーが切断され、telnetが接続が閉じられたことを報告します。
Listening sockets
webplayerでlistening socketsを作成することはできず、サーバーとして機能することはできません。 したがって、webplayersは相互に直接通信することはできません（ピア2ピア）。 TCPソケットを使用する場合は、ソケットポリシーシステムを介して許可されている場合にのみ、リモートエンドポイントに接続できます。 UDPの場合は同じように動作しますが、概念はコネクションレスプロトコルであるため、パケットの送受信に接続/リッスンする必要はありません。 これは、allow-access-from domainタグを持つ有効なポリシーで最初に応答した場合にのみ、サーバーからパケットを受信できるように強制することによって機能します。
これはすべてちょうどとても迷惑です、なぜこのようなものはすべて存在しますか？
Unity Web Playerをインストールする人を保護するために、ソケットとWWWのセキュリティ機能が存在します。 これらの制限がなければ、次のような攻撃が可能になります:
- ボブはホワイトハウスで働いてる
- フランクは悪です。 彼はゲームのふりをするunity webgameを書いているが、バックグラウンドでhttp://internal.whitehouse.gov/LocationOfNuclearBombs.pdfへのWWW要求を行う。 内部。ホワイトハウス政府は、インターネットから到達可能ではないサーバーですが、彼がホワイトハウスで働いているので、ボブのワークステーションから到達可能です。
- Frankはこれらのpdfバイトをhttp://frank.com/secretDataUploader.php
- Frankに送信し、このゲームをhttp://www.frank.com/coolgame.unity3d
- Frankに何らかの形でゲームをプレイさせるよう説得します。
- ボブはゲームをプレイしています。
- ゲームは黙って秘密文書をダウンロードし、フランクに送信します。
WWWとsocketのセキュリティ機能を使用すると、pdfをダウンロードする前にunityがhttp://internal.whitehouse.gov/crossdomain.xmlをチェックし、そのサーバーに尋ねる意図があるため、この攻撃は失敗します: “あなたのサーバー上にあるデータは、一般的な使用のために利用可能ですか？”. クロスドメインを配置します。webサーバー上のxmlは、その質問に対する応答と見なすことができます。 この例の場合、システム演算子は次のようになります。internal.whitehouse.gov crossdomainを配置しません。Unityがpdfをダウンロードしないようにするために、そのサーバー上のxml。
残念ながら、Unity Web Playerをインストールする人を保護するために、Unityで開発する人はコンテンツを開発する際にこれらのセキュリティ対策を考慮する必要 同じ制限は、すべての主要なプラグイン技術に存在しています。 (Flash,Silverlight,Shockwave)
例外
Web Playerユーザーの保護とコンテンツ開発者の生活を容易にするために、上記のセキュリティメカニズムに例外を実装しました。
クロスドメインを持たないサーバーから画像をダウンロードすることができます。xmlファイル。 ただし、これらの画像で行うことが許可されている唯一のことは、シーン内のテクスチャとして使用することです。 それらにGetPixel（）を使用することはできません。 また、画面から読み戻すこともできません。 両方の試行を行うと、SecurityExceptionがスローされます:
SecurityException: No read access to the texture data: at (wrapper managed-to-native) UnityEngine.Texture2D:GetPixel (int,int)ここでの推論は、コンテンツ開発者がそれにアクセスできない限り、イメージをダウンロードしても大丈夫だということです。 したがって、ユーザーに表示することはできますが、イメージのバイトを他のサーバーに送り返すことはできません。 ピクセルデータにアクセスする必要がある場合は、画像がフェッチされるサーバーにcrossdomain.xmlファイルを配置します。