sandbox de segurança do Webplayer

no Unity 3.0, o webplayer implementa um modelo de segurança muito semelhante ao usado pelo Adobe Flash player™. Essas restrições de segurança se aplicam apenas ao webplayer e ao editor quando o destino de compilação ativo é o WebPlayer. O modelo de segurança tem várias partes:

• restrições ao acesso a dados em um domínio diferente daquele que hospeda seu .arquivo unity3d.
• alguma limitação no uso dos soquetes.
• não permitir a invocação de qualquer método que consideramos fora dos limites. (coisas como arquivo.Excluir, etc).
• não permitindo o uso do sistema.Reflexao.* para chamar métodos privados / internos nas aulas, você não se escreveu.

atualmente, apenas as duas primeiras partes do modelo de segurança são emuladas no Editor.

a funcionalidade de rede muti-player integrada do Unity (UnityEngine.Network, UnityEngine.NetworkView classes etc.) não é afetada.

este documento descreve como garantir que seu conteúdo continue funcionando com a versão 3.0 do Unity webplayer.

• consulte a referência da API Unity para obter informações sobre a classe WWW.
• consulte a referência da API. NET para obter informações sobre a classe de Soquete.net.

a classe WWW e os soquetes usam o mesmo esquema de política, mas, além disso, são sistemas completamente separados. A Política WWW define apenas permissões no serviço da web onde a política está hospedada, mas as Políticas de Soquete se aplicam a todas as conexões de soquete TCP/UDP.

o Unity editor vem com um recurso” emular segurança da Web”, que impõe o modelo de segurança do webplayer.Isso facilita a detecção de problemas no conforto do editor. Você pode encontrar esta configuração emedit->configurações do projeto – > Editor. Veja também as configurações do Editor.

o Unity webplayer espera que um arquivo de política http servido chamado crossdomain.xml esteja disponível no domínio que você deseja acessar com a classe WWW(embora isso não seja necessário se for o mesmo domínio que hospeda o arquivo unity3d).

por exemplo, imagine um jogo de tetris, hospedado no seguinte url:

http://gamecompany.com/games/tetris.unity3d

precisa acessar uma lista de recordes a partir do seguinte url:

http://highscoreprovider.net/gethighscore.php

neste caso, você precisará colocar um crossdomain.xml arquivo na raiz do highscoreprovider.net domínio como este: http://highscoreprovider.net/crossdomain.xml

O conteúdo de crossdomain.xml arquivo está no formato usado pelo Flash player. É muito provável que vocêencontre o arquivo crossdomain.xml já em vigor. A política no arquivo é assim:

<?xml version="1.0"?><cross-domain-policy><allow-access-from domain="*"/></cross-domain-policy>

quando este arquivo é colocado em http://highscoreprovider.net/crossdomain.xml, o proprietário desse domínio declara que o conteúdo do servidor web pode ser acessado por qualquer webplayer proveniente de qualquer domínio.

o Unity webplayer não suporta as tags<allow-http-request-headers-from domain > e<site-control allowed-cross-domain-policies >. Observe que crossdomain.xml deve ser um arquivo ASCII.

depuração

definir uma variável de ambiente ENABLE_CROSSDOMAIN_LOGGING para 1 fará com que as mensagens do console sejam geradas à medida que o tempo de execução do Unity busca e decodifica o arquivo crossdomain.xml. Em um Mac, você pode definir variáveis de ambiente globais em /etc/launchd.conf. Em um PC, use o Painel de Controle->Sistema E Segurança->Sistema>configurações Avançadas do sistema->Variáveis de Ambiente…

Aqui está um exemplo de saída com este conjunto de variáveis de ambiente, quando o webplayer tentativas para a obtenção de uma imagem a partir de um servidor remoto:

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

Quando executado no Editor estas mensagens são escritas no Editor.log. Tentar ler um arquivo crossdomain.xml armazenado incorretamente como utf16 com um BOM resultará em uma falha na análise do xml:

BuildFlashPolicy caught an exception while parsing http://www.remoteserver.com/crossdomain.xml: Expected element

isso ocorre porque o BOM não é esperado. Usando um arquivo não suportado utf16 sem BOM resultará em:

BuildFlashPolicy caught an exception while parsing http://www.remoteserver.com/crossdomain.xml: Policy can't be constructed from empty stream.

isso ocorre porque o primeiro byte no arquivo é zero, o que faz com que o analisador pense que chegou ao final do arquivo. Crossdomain.xml deve ser um arquivo ASCII.

implicações para o uso de Sockets:

um Unity webplayer precisa de uma política de socket served para se conectar a um host específico. Esta política é hospedada por padrão pelo host de destino na porta 843, mas também pode ser hospedada em outras portas. A diferença funcional com uma porta não padrão é que ela deve ser buscada manualmente com segurança.PrefetchSocketPolicy () chamada de API e se estiver hospedado em uma porta superior a 1024, a Política só pode dar acesso a outras portas superiores a 1024.

ao usar a porta padrão, funciona assim: um Unity webplayer tenta fazer uma conexão de soquete TCP a um host, primeiro verifica se o servidor host aceitará o connection.It faz isso abrindo um soquete TCP na porta 843, emite uma solicitação e espera receber uma política de Soquete sobre a nova conexão. O Unity webplayer então verifica se a política do host permite que a conexão vá em frente e continuará sem erros, em caso afirmativo. Esse processo acontece de forma transparente ao código do usuário, que não precisa ser modificado para usar esse modelo de segurança. Um exemplo de uma política de soquete é assim:

<?xml version="1.0"?><cross-domain-policy> <allow-access-from domain="*" to-ports="1200-1220"/> </cross-domain-policy>"

esta política diz efetivamente que “o conteúdo de qualquer domínio é livre para fazer conexões de Soquete nas portas 1200-1220”. O Unity webplayer respeitará isso e rejeitará qualquer tentativa de conexão de soquete usando uma porta fora desse intervalo (uma SecurityException será lançada).

ao usar conexões UDP, a política também pode ser buscada automaticamente quando precisa ser aplicada de maneira semelhante à do TCP. A diferença é que a auto-buscando com TCP acontece quando você se conecta a algo (garante que você tem permissão para se conectar a um servidor), mas com o UDP, pois está sem conexão, isso também acontece quando você chamar qualquer API ponto que envia ou recebe dados (garante que você está autorizado a enviar/receber tráfego de/para um servidor).

o formato usado para a Política de soquete é o mesmo usado pelo Flash player, exceto que algumas tags não são suportadas. O Unity webplayer suporta apenas ” * ” como um valor válido para a configuração do domínio e a configuração “to-ports” é obrigatória.

<?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>

a Política de Soquete se aplica aos tipos de conexão TCP e UDP para que o tráfego UDP e TCP possa ser controlado por um servidor de política.

para sua conveniência, fornecemos um pequeno programa que simplesmente escuta na porta 843; quando em uma conexão ele recebe uma string de solicitação, ele responderá com uma política de Soquete válida.O código do servidor pode ser encontrado dentro da pasta Unity install, em Data / Tools / SocketPolicyServer no Windows ou / Unity.app/Contents/Tools / SocketPolicyServer no OS X. observe que o executável pré-construído pode ser executado no Mac, pois é um executável Mono. Basta digitar ” mono sockpol.exe ” para executá-lo. Observe que este código de exemplo mostra o comportamento correto de um servidor de política de Soquete. Especificamente, o servidor espera receber uma string terminada em zero que contenha < policy-file-request/ >. Ele só envia ao cliente o documento xml da Política de soquete quando essa string (e exatamente essa string) for recebida. Além disso, é necessário que o cabeçalho xml e o corpo xml sejam enviados com uma única gravação de Soquete. Quebrar o cabeçalho e o corpo em operações de gravação de Soquete separadas pode causar exceções de segurança devido ao Unity receber uma política incompleta. Se você tiver algum problema com seu próprio servidor, considere usar o exemplo que fornecemos. Isso deve ajudá-lo a diagnosticar se você tem problemas de servidor ou rede.

bibliotecas de rede de terceiros, comumente usadas para redes de jogos multiplayer, devem ser capazes de trabalhar com esses requisitos, desde que não dependam da funcionalidade peer 2 peer (veja abaixo), mas utilizem servidores dedicados. Às vezes, eles até saem da caixa com suporte para políticas de hospedagem.

Nota: Embora os arquivos de política crossdomain.xml e socket sejam documentos xml e sejam amplamente semelhantes, a maneira como esses documentos são atendidos é muito diferente. Crossdomain.xml(que se aplica a solicitações http) é buscado usando http na porta 80, onde-como a Política de soquete é buscada na porta 843 usando um servidor trivial que implementa a Política <-file-request/>. Você não pode usar um servidor http para emitir o arquivo de política de soquete, nem configurar um servidor simplesmente envia o arquivo de política de soquete em resposta a uma conexão de soquete na porta 843. Observe também que cada servidor ao qual você se conecta requer seu próprio servidor de política de Soquete.

depuração

você pode usar telnet para se conectar ao servidor de política de Soquete. Uma sessão de exemplo é mostrada abaixo:

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$

nesta sessão de exemplo, o telnet é usado para se conectar ao localhost na porta 843. Telnet responde com as três primeiras linhas e, em seguida, fica esperando que o usuário insira algo. O usuário inseriu a string de solicitação de política <policy-file-request/ >, que o servidor de política de Soquete recebe e responde com a Política de Soquete. O servidor então se desconecta fazendo com que a telnet informe que a conexão foi fechada.

soquetes de escuta

você não pode criar soquetes de escuta no webplayer, ele não pode atuar como um servidor. Portanto, os webplayers não podem se comunicar diretamente (peer 2 peer). Ao usar soquetes TCP, você só pode se conectar a terminais remotos, desde que seja permitido através do sistema de política de Soquete. Para UDP ele funciona da mesma forma, mas o conceito é um pouco diferente, pois é um protocolo sem conexão, você não precisa se conectar/ouvir para enviar/receber pacotes. Ele funciona reforçando que você só pode receber pacotes de um servidor se ele respondeu primeiro com uma política válida com a tag allow-access-from domain.

tudo isso é tão irritante, por que todas essas coisas existem?

os recursos de segurança socket E WWW existem para proteger as pessoas que instalam o Unity Web Player. Sem essas restrições, um ataque como o seguinte, seria possível:

• Bob trabalha na casa branca.Frank é o mal. Ele escreve um webgame unity que finge ser um jogo, mas em segundo plano faz um pedido WWW para http://internal.whitehouse.gov/LocationOfNuclearBombs.pdf. interno.whitehouse.gov é um servidor que não é acessível a partir da internet, mas é acessível a partir da estação de trabalho de Bob porque ele trabalha na Casa Branca.Frank envia esses bytes pdf para http://frank.com/secretDataUploader.php
• Frank coloca este jogo emhttp://www.frank.com/coolgame.unity3d
• Frank de alguma forma convence Bob a jogar o jogo.
• Bob joga o jogo.
• o jogo Baixa silenciosamente o documento secreto e o envia para Frank.

com os recursos de segurança WWW e socket, esse ataque falhará, porque antes de baixar o pdf, o unity verifica http://internal.whitehouse.gov/crossdomain.xml, com a intenção de perguntar a esse servidor: “os dados que você tem em seu servidor estão disponíveis para uso público?”. Colocando um crossdomain.xml em um servidor web pode ser visto como a resposta a essa pergunta. No caso deste exemplo, o operador do sistema de internal.whitehouse.gov não vai colocar um crossdomain.xml em seu servidor, o que levará o Unity a não baixar o pdf.

infelizmente, para proteger as pessoas que instalam o Unity Web Player, as pessoas que se desenvolvem no Unity precisam levar em consideração essas medidas de segurança ao desenvolver conteúdo. As mesmas restrições estão presentes em todas as principais tecnologias de plug-ins. (Flash, Silverlight, Shockwave)

Exceções

a fim de encontrar o equilíbrio certo entre a proteção da Web Player de usuários e tornar a vida dos desenvolvedores de conteúdo fácil, temos implementado uma exceção para o mecanismo de segurança descritos acima:

Você tem permissão para fazer download de imagens a partir de servidores que não têm um crossdomain.arquivo xml. No entanto, a única coisa que você pode fazer com essas imagens é usá-las como texturas em sua cena. Você não tem permissão para usar GetPixel() neles. Você também não tem permissão para ler de volta da tela. Ambas as tentativas resultarão em um SecurityException sendo lançado:

SecurityException: No read access to the texture data: at (wrapper managed-to-native) UnityEngine.Texture2D:GetPixel (int,int)

o raciocínio está aqui é que não há problema em baixar a imagem, desde que o desenvolvedor de conteúdo não tenha acesso a ela. Assim, você pode exibi-lo para o usuário, mas não pode enviar os bytes da imagem de volta para algum outro servidor. Se você precisar acessar os dados do pixel, coloque um arquivo crossdomain.xml no servidor de onde as imagens são obtidas.