Controles de permissãoFlash Player 9 e posterior, Adobe AIR 1.0 e posterior O modelo de segurança de tempo de execução do cliente Flash Player foi designado em torno de recursos que são objetos, como arquivos SWF, dados locais e URLs da Internet. Participantes são as partes que são as proprietárias ou que usam esses recursos. Os participantes podem exercer controles (configurações de segurança) sobre seus próprios recursos e cada recurso tem quatro participantes. O Flash Player reforça estritamente uma hierarquia de autoridade para esses controles, conforme mostrado na ilustração a seguir:  Hierarquia de controles de segurança Isso significa, por exemplo, que se um administrador restringir o acesso a um recurso, nenhum outro participante poderá substituir essa restrição. Nos aplicativos AIR, esses controles de permissão valem apenas para os conteúdos executados fora da caixa de proteção do aplicativo AIR. Controles de administradorUm usuário administrativo de um computador (um usuário que fez logon com direitos administrativos) pode aplicar configurações de segurança do Flash Player que afetam todos os usuários do computador. Em um ambiente não empresarial, como em um computador doméstico, normalmente há um usuário que também tem acesso administrativo. Mesmo em um ambiente empresarial, usuários individuais podem ter direitos administrativos no computador. Há dois tipos de controles de usuário administrativo:
O arquivo mms.cfgO arquivo mms.cfg é um arquivo de texto que permite que os administradores ativem ou restrinjam o acesso a vários recursos. Quando o Flash Player é iniciado, lê as configurações de segurança desse arquivo e as usa para limitar a funcionalidade. O arquivo mms.cfg inclui configurações que o administrador usa para gerenciar recursos, como controles de privacidade, segurança de arquivo local, conexões de soquete, entre outros. Um arquivo SWF pode acessar algumas informações sobre capacidades que foram desativadas chamando as propriedades Capabilities.avHardwareDisable e Capabilities.localFileReadDisable. No entanto a maioria das configurações no arquivo mms.cfg não podem ser consultadas no ActionScript. Para reforçar as políticas de segurança e de privacidade independentemente do aplicativo para um computador, o arquivo mms.cfg deve ser modificado apenas por administradores do sistema. O arquivo mms.cfg não deve ser usado por instaladores de aplicativos. Embora um instalador que executa com privilégios administrativos possa modificar o conteúdo do arquivo mms.cfg, a Adobe considera esse uso como uma violação da confiança do usuário e recomenda que os criadores de instaladores nunca modifiquem o arquivo mms.cfg. O arquivo mms.cfg é armazenado no seguinte local:
Para obter mais informações sobre o arquivo mms.cfg, consulte o Guia de administração do Flash Player, em www.adobe.com/go/flash_player_admin_br. O diretório Global Flash Player TrustUsuários administrativos e aplicativos de instalador podem registrar arquivos SWF locais especificados como confiáveis para todos os usuários. Esses arquivos SWF são atribuídos à caixa de proteção local confiável. Eles podem interagir com quaisquer outros arquivos SWF e podem carregar dados de qualquer lugar remoto ou local. Os arquivos são designados como confiáveis no diretório Global Flash Player Trust, no seguinte local:
O diretório Flash Player Trust pode conter qualquer número de arquivos de texto, cada um dos quais lista caminhos confiáveis, com um caminho por linha. Cada caminho pode ser um arquivo SWF individual, um arquivo HTML ou um diretório. Linhas de comentários começam com o símbolo #. Por exemplo, um arquivo de configuração de confiança do Flash Player que contém o texto a seguir concede status confiável a todos os arquivos no diretório especificado e em todos os subdiretórios: # Trust files in the following directories: C:\Documents and Settings\All Users\Documents\SampleApp Os caminhos listados em um arquivo de configuração de confiança devem sempre ser caminhos locais ou caminhos de rede SMB. Qualquer caminho HTTP em um arquivo de configuração confiável é ignorado. Apenas arquivos locais podem ser confiáveis. Para evitar conflitos, dê a cada arquivo de configuração confiável um nome de arquivo correspondente ao aplicativo de instalação e use uma extensão de arquivo .cfg. Como um desenvolvedor que distribui um arquivo SWF executado localmente por meio de um aplicativo instalador, é possível fazer com que o aplicativo instalador adicione um arquivo de configuração ao diretório Global Flash Player Trust, concedendo privilégios totais ao arquivo que você está distribuindo. O aplicativo instalador deve ser executado por um usuário com direitos administrativos. Ao contrário do arquivo ms.cfg, o diretório Global Flash Player Trust é incluído com o objetivo de aplicativos instaladores concederem permissões de confiança. Os usuários administrativos e os aplicativos instaladores podem designar aplicativos locais confiáveis usando o diretório Global Flash Player Trust. Também há diretórios Flash Player Trust para usuários individuais (consulte Controles de usuário). Controles de usuárioO Flash Player fornece três mecanismos diferentes em nível de usuário para definir permissões: a UI de Configurações, o Gerenciador de configurações e o diretório User Flash Player Trust. A UI de Configurações e o Gerenciador de configuraçõesA UI de Configurações é um mecanismo rápido e interativo para definir as configurações de um domínio específico. O Gerenciador de configurações tem uma interface mais detalhada e permite fazer alterações globais que afetam as permissões de muitos ou de todos os domínios. Além disso, quando um arquivo SWG solicita uma nova permissão, exigindo a tomada de decisões relativas a segurança ou privacidade durante a execução, são exibidas caixas de diálogo nas quais os usuários podem ajustar algumas configurações do Flash Player. O Gerenciador de Configurações e a UI de Configurações oferecem opções relacionadas a segurança, como configurações de câmera e microfone, configurações de armazenamento de objetos compartilhados, configurações relacionadas a conteúdo pré-existente etc. Nem o Gerenciador de Configurações, nem a UI de Configurações estão disponíveis para os aplicativos AIR. Nota: Qualquer configuração feita no arquivo mms.cfg (consulte Controles de administrador) não é refletida no Gerenciador de configurações.
Para obter detalhes sobre o Gerenciador de configurações, consulte www.adobe.com/go/settingsmanager_br. O diretório User Flash Player TrustUsuários e aplicativos instaladores podem registrar arquivos SWF locais como confiáveis. Esses arquivos SWF são atribuídos à caixa de proteção local confiável. Eles podem interagir com quaisquer outros arquivos SWF e podem carregar dados de qualquer lugar remoto ou local. Um usuário designa um arquivo como confiável no diretório User Flash Player Trust, que está no mesmo diretório que a área de armazenamento de objetos compartilhados, nos seguintes locais (os locais são específicos do usuário atual):
Controles de site (arquivos de política)Para disponibilizar dados do servidor Web para arquivos SWF de outros domínios, crie um arquivo de política do servidor. Um arquivo de política é um arquivo XML colocado em um local específico no servidor. arquivos de política afetam o acesso a vários ativos, incluindo os seguintes:
Objetos ActionScript instanciam dois tipos diferentes de conexões de servidor: conexões de servidor com base em documento e conexões de soquete. Os objetos do ActionScript, como Loader, Sound, URLLoader e URLStream instanciam conexões de servidor com base em documento e esses objetos carregam um arquivo de uma URL. Os objetos Socket e XMLSocket do ActionScript fazem conexões de soquete que funcionam com fluxos de dados, não com documentos carregados. Como o Flash Player oferece suporte a dois tipos de conexões de servidor, há dois tipos de arquivos de política: arquivos de política de URL e arquivos de política de soquete.
O Flash Player exige que arquivos de política sejam transmitidos usando o mesmo protocolo que a tentativa de conexão quer usar. Por exemplo, quando você coloca um arquivo de política no servidor HTTP, os arquivos SWF de outros domínios recebem permissão para carregar dados dele como um servidor HTTP. No entanto, se não fornecer um arquivo de política de soquete no mesmo servidor, você estará proibindo que arquivos SWF de outros domínios se conectem ao servidor no nível de soquete. Em outras palavras, o meio pelo qual um arquivo de política é recuperado deve corresponder ao meio de conexão. O uso e a sintaxe do arquivo de política são discutidos brevemente no restante desta seção, pois eles se aplicam aos arquivos SWF publicados para o Flash Player 10. A implementação do arquivo de política é um pouco diferente em versões anteriores do Flash Player, uma vez que versões sucessivas reforçaram a segurança do Flash Player. Para obter informações mais detalhadas sobre arquivos de política, consulte o tópico “Alterações em arquivos de política do Flash Player 9” do Centro de desenvolvedores do Flash Player, em www.adobe.com/go/devnet_security_br. O código executado na caixa de proteção do aplicativo AIR não exige um arquivo de políticas para acessar dados em uma URL ou um soquete. O código em um aplicativo AIR executado em uma caixa de proteção que não seja de um aplicativo exige um arquivo de políticas. arquivos de política mestrePor padrão, primeiro o Flash Player (e o conteúdo AIR que não está na caixa de proteção do aplicativo AIR) procura um arquivo de política de URL denominado crossdomain.xml no diretório raiz do servidor e procura um arquivo de política de soquete na porta 843. Um arquivo em um desses locais é chamado de arquivo de política mestre. No caso de conexões de soquete, o Flash Player também procura um arquivo de política de soquete na mesma porta que a conexão principal. No entanto, um arquivo de política encontrado naquela porta não é considerado um arquivo de política mestre. Além de especificar permissões de acesso, o arquivo de política mestre também pode conter uma instrução meta-policy. Uma metapolítica especifica quais locais podem conter arquivos de política. A metapolítica padrão dos arquivos de política de URL é “somente mestre”, o que significa que /crossdomain.xml é o único arquivo de política permitido no servidor. A metapolítica padrão para arquivos de política de soquete é “all”, o que significa que qualquer soquete no host pode servir um arquivo de política de soquete. Nota: No Flash Player 9 e anterior, a metapolítica padrão de arquivos de política de URL era “all”, o que significa que qualquer diretório pode conter um arquivo de política. Se você implantou aplicativos que carregam arquivos de política de locais diferentes do arquivo padrão /crossdomain.xml e se esses aplicativos estiverem executando agora no Flash Player 10, verifique se você (ou outro administrador do servidor) modificou o arquivo de política mestre para permitir arquivos de política adicionais. Para obter informações sobre como especificar uma metapolítica diferente, consulte o tópico “Alterações em arquivos de política do Flash Player 9” do Centro de desenvolvedores do Flash Player, em www.adobe.com/go/devnet_security_br.
Um arquivo SWF pode verificar se existe um nome de arquivo de política diferente ou um local de diretório diferente chamando o método Security.loadPolicyFile(). No entanto, se o arquivo de política mestre não especificar que o local de destino pode servir arquivos de política, a chamada para loadPolicyFile() não terá nenhum efeito, mesmo que haja um arquivo de política naquele local. Chame loadPolicyFile() antes de tentar qualquer operação de rede que exija o arquivo de política. O Flash Player enfileira automaticamente solicitações de rede por trás de tentativas do arquivo de política correspondente. Portanto, é aceitável, por exemplo, chamar Security.loadPolicyFile() imediatamente antes de iniciar uma operação de rede. Ao verificar um arquivo de política mestre, o Flash Player aguarda três segundos por uma resposta do servidor. Se uma resposta não for recebida, o Flash Player assumirá que não existe nenhum arquivo de política. No entanto não há nenhum valor de tempo limite padrão para chamadas para loadPolicyFile(). O Flash Player assume que o arquivo que está chamando existe, e aguarda quanto tempo for necessário para carregá-lo. Portanto, para verificar se um arquivo de política mestre está carregado, use loadPolicyFile() para chamá-lo explicitamente. Mesmo que o método seja denominado Security.loadPolicyFile(), um arquivo de política não será carregado até que uma chamada de rede que exija um arquivo de política seja emitida. Chamadas para loadPolicyFile() simplesmente informam ao Flash Player onde procurar por arquivos de política quando eles são necessários. Não é possível receber notificação de quando uma solicitação de arquivo de política é iniciada ou concluída e não há motivo para isso. O Flash Player executa verificações de políticas assincronamente e aguarda automaticamente para iniciar conexões até após o êxito das verificações do arquivo de política. As seções a seguir contêm informações que se aplicam apenas a arquivos de política de URL. Para obter mais informações sobre arquivos de política de soquete, consulte Conexão a soquetes. Escopo do arquivo de política de URLO arquivo de política de URL se aplica apenas ao diretório do qual ele é carregado e a seus diretórios filho. Um arquivo de política no diretório raiz se aplica ao todo o servidor. Um arquivo de política carregado de um subdiretório arbitrário aplica-se apenas àquele diretório e a seus subdiretórios. Um arquivo de política afeta o acesso somente ao servidor específico onde ele reside. Por exemplo, um arquivo de política localizado em https://www.adobe.com:8080/crossdomain.xml aplica-se apenas a chamadas de carregamento de dados feitas para www.adobe.com por HTTPS na porta 8080. Especificação de permissões de acesso em um arquivo de política de URLUm arquivo de política contém uma única tag <cross-domain-policy> que, por sua vez, contém zero ou mais tags <allow-access-from>. Cada tag <allow-access-from> contém um atributo, domain, que especifica um endereço IP exato, um domínio exato ou um domínio curinga (qualquer domínio). Os domínios curinga são indicados de duas maneiras:
O exemplo a seguir mostra um arquivo de política de URL que permite acesso a arquivos SWF originados de *.example.com, www.friendOfExample.com e 192.0.34.166: <?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*.example.com" />
<allow-access-from domain="www.friendOfExample.com" />
<allow-access-from domain="192.0.34.166" />
</cross-domain-policy>
Se você especificar um endereço IP, o acesso será concedido somente a arquivos SWF carregados daquele endereço IP usando a sintaxe IP (por exemplo, http://65.57.83.12/flashmovie.swf). O acesso não é concedido a arquivos SWF que usam a sintaxe de nome de domínio. O Flash Player não executa resolução de DNS. É possível permitir acesso a documentos originários de qualquer domínio, conforme mostrado no exemplo a seguir: <?xml version="1.0"?> <!-- http://www.foo.com/crossdomain.xml --> <cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy> Cada tag <allow-access-from> também tem o atributo opcional secure que é padronizado como true. Se o arquivo de política estiver em um servidor HTTPS e você quiser permitir que arquivos SWF em um servidor não-HTTPS carreguem dados do servidor HTTPS, poderá definir o atributo como false. A configuração do atributo secure como false pode comprometer a segurança oferecida pelo HTTPS. Especificamente, a configuração desse atributo como false abre conteúdo de segurança a ataques por falsificação. A Adobe recomenda enfaticamente que você não defina o atributo secure como false. Se os dados a serem carregados estiverem em um servidor HTTPS, mas o carregamento do arquivo SWF estiver em um servidor HTTP, a Adobe recomenda mover o arquivo SWF que está sendo carregado para um servidor HTTPS. Fazer isso permite manter todas as cópias de seus dados seguras sob a proteção de HTTPS. No entanto, se você decidir que deve manter o arquivo SWF que está sendo carregado em um servidor HTTP, adicione o atributo secure="false" à tag <allow-access-from>, conforme mostrado no código a seguir: <allow-access-from domain="www.example.com" secure="false" /> Outro elemento que pode ser usado para permitir acesso é a tag allow-http-request-headers-from. Esse elemento concede a um cliente, que hospeda conteúdo de outro domínio, permissão para enviar cabeçalhos definidos pelo usuário ao seu domínio. Enquanto a tag <allow-access-from> concede a outros domínios permissão para enviar dados ao seu domínio, a tag allow-http-request-headers-from concede a outros domínios permissão para enviar dados a seu domínio na forma de cabeçalhos. No exemplo a seguir, qualquer domínio tem permissão para enviar o cabeçalho SOAPAction ao domínio atual:
<cross-domain-policy>
<allow-http-request-headers-from domain="*" headers="SOAPAction"/>
</cross-domain-policy>
Se a instrução allow-http-request-headers-from estiver no arquivo de política mestre, ela será aplicada a todos os diretórios no host. Caso contrário, ela será aplicada apenas ao diretório e subdiretórios do arquivo de política que contêm a instrução. Pré-carregamento de arquivos de políticaO carregamento de dados de um servidor ou a conexão a um soquete é uma operação assíncrona. O Flash Player simplesmente aguarda que o download do arquivo de política seja concluído antes de iniciar a operação principal. No entanto, a extração de dados de pixels de imagens ou a extração de dados de amostra de sons é uma operação síncrona. O arquivo de política deve ser carregado para que os dados possam ser extraídos. Ao carregar a mídia, especifique que ela verifique a existência de um arquivo de política:
Ao definir um desses parâmetros, o Flash Player primeiro verifica se há qualquer arquivo de política que já foi baixado naquele domínio. Em seguida, ele procura o arquivo de política no local padrão do servidor, verificando as instruções <allow-access-from> e a presença de uma metapolítica. Finalmente, ele considera quaisquer chamadas pendentes para o método Security.loadPolicyFile() para verificar se elas estão em escopo. Controles de autor (desenvolvedor)A API ActionScript principal usada para conceder privilégios de segurança é o método Security.allowDomain() que concede privilégios a arquivos SWF nos domínios especificados por você. No exemplo a seguir, um arquivo SWF concede acesso a arquivos SWF servidos no domínio www.example.com: Security.allowDomain("www.example.com")
Esse método concede permissões para o seguinte:
O objetivo principal da chamada do método Security.allowDomain() é conceder permissão para arquivos SWF em um domínio externo para executar script do arquivo SWF chamando o método Security.allowDomain(). Para obter mais informações, consulte Cross-scripting. Especificar um endereço IP como parâmetro do método Security.allowDomain() não permite acesso de todas as partes que se originam no endereço IP especificado. Ao contrário, isso permite o acesso apenas de uma parte que contém o endereço IP especificado como sua URL, em vez de um nome de domínio mapeia para o endereço IP. Por exemplo, se o nome do domínio www.example.com for mapeado para o endereço IP 192.0.34.166, uma chamada para Security.allowDomain("192.0.34.166") não concederá acesso a www.example.com. É possível passar o curinga "*" para o método Security.allowDomain() para permitir acesso a todos os domínios. Como ele concede permissão para arquivos SWF de todos os domínios para executarem script na chamada do arquivo, use o curinga "*" com cuidado. O ActionScript inclui uma segunda API de permissão, chamada Security.allowInsecureDomain(). Esse método faz a mesma coisa que o método Security.allowDomain(), exceto que, quando chamado de um arquivo SWF servido por uma conexão HTTPS segura, ele permite adicionalmente acesso ao arquivo SWF de chamada por outros arquivos SWF que são servidos em um protocolo inseguro, como HTTP. No entanto, não é uma boa prática de segurança permitir script entre arquivos de um protocolo seguro (HTTPS) e arquivos de protocolos inseguros (como HTTP). Isso pode abrir conteúdo seguro a ataques de falsificação. Esses ataques podem ocorrer da seguinte maneira: como o método Security.allowInsecureDomain() permite acesso aos dados de HTTPS seguro por arquivos SWF servidos em conexões HTTP, um invasor situado entre o servidor HTTP e seus usuários pode substituir seu arquivo SWF de HTTP por um arquivo próprio, que pode então acessar seus dados HTTPS. Importante: O código executado na caixa de proteção do aplicativo AIR não tem permissão para chamar os métodos allowDomain() ou allowInsecureDomain() da classe de Segurança.
Outro método importante relacionado à segurança é o método Security.loadPolicyFile() que faz com que o Flash Player verifique se há um arquivo de política em um local não padrão. Para obter mais informações, consulte Controles de site (arquivos de política). 
|
|
