Controles de permissão

Flash 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 autoridade
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 do AIR.

Controles de administrador

Um 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.cfg

  • O diretório Global Flash Player Trust

O arquivo mms.cfg

O 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:

  • Windows: system \Macromed\Flash\mms.cfg

    (por exemplo, C:\WINDOWS\system32\Macromed\Flash\mms.cfg)

  • Mac: app support /Macromedia/mms.cfg

    (por exemplo, /Library/Application Support/Macromedia/mms.cfg)

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 Trust

Usuá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:

  • Windows: system \Macromed\Flash\FlashPlayerTrust

    (por exemplo, C:\WINDOWS\system32\Macromed\Flash\FlashPlayerTrust)

  • Mac: app support /Macromedia/FlashPlayerTrust

    (por exemplo, /Library/Application Support/Macromedia/FlashPlayerTrust)

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ário

O 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ções

A 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 Trust

Usuá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):

  • Windows: app data\Macromedia\Flash Player\#Security\FlashPlayerTrust

    (por exemplo, C:\Documents and Settings\JohnD\Application Data\Macromedia\Flash Player\#Security\FlashPlayerTrust no Windows XP ou C:\Users\JohnD\AppData\Roaming\Macromedia\Flash Player\#Security\FlashPlayerTrust no Windows Vista)

    No Windows, a pasta Application Data fica oculta, por padrão. Para mostrar pastas e arquivos ocultos, selecione Meu computador para abrir o Windows Explorer, selecione Ferramentas > Opções de pasta e selecione a aba Exibir. Na guia Exibir, selecione o botão de opção Mostrar pastas e arquivos ocultos.

  • Mac: app data/Macromedia/Flash Player/#Security/FlashPlayerTrust

    (por exemplo, /Users/JohnD/Library/Preferences/Macromedia/Flash Player/#Security/FlashPlayerTrust)

    Essas configurações afetam apenas o usuário atual, não outros usuários que fazem logon no computador. Se um usuário sem direitos administrativos instalar um aplicativo em sua própria parte do sistema, o diretório User Flash Player Trust permitirá que o instalador registre o aplicativo como confiável para aquele usuário.

    Como um desenvolvedor que distribui um arquivo SWF executado localmente por meio de um aplicativo instalador, você pode fazer com que o aplicativo instalador adicione um arquivo de configuração ao diretório User Flash Player Trust, concedendo privilégios totais ao arquivo que está distribuindo. Mesmo nessa situação, o arquivo do diretório User Flash Player Trust é considerado um controle de usuário, porque uma ação do usuário (instalação) o inicia.

    Também existe um diretório Global Flash Player Trust, usado pelo usuário administrativo ou por instaladores para registrar um aplicativo para todos os usuários de um computador (consulte Controles de administrador ).

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:

  • Dados em bitmaps, sons e vídeos

  • Carregamento de arquivos de texto e XML

  • Importação de arquivos SWF de outros domínios de segurança no domínio de segurança do arquivo SWF que está sendo carregado

  • Acesso a soquete e conexões de soquete XML

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.
  • Conexões com base em documento exigem arquivos de política de URL . Esses arquivos permitem que o servidor indique que seus dados e documentos estão disponíveis para arquivos SWF servidos em determinados domínios ou em todos os domínios.

  • Conexões de soquete exigem arquivos de política de soquetes que ativam a rede diretamente no nível inferior do soquete TCP usando as classes Socket e XMLSocket.

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 do AIR não exige um arquivo de políticas para acessar dados em uma URL ou um soquete. O código em um aplicativo do 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 mestre

Por padrão, primeiro o Flash Player (e o conteúdo AIR que não está na caixa de proteção do aplicativo do 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 URL

O 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 URL

Um 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:
  • Por um único asterisco (*), que corresponde a todos os domínios e a todos os endereços IP.

  • Por um asterisco seguido por um sufixo, que corresponde apenas aos domínios que terminam com o sufixo especificado.

Sufixos devem começar com um ponto. No entanto domínios curinga com sufixos podem corresponder a domínios que consistem apenas no sufixo sem o ponto inicial. Por exemplo, xyz.com é considerado como parte de *.xyz.com. Curingas não são permitidos em especificações de domínios IP.

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ítica

O 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 usar o método Loader.load() , defina a propriedade checkPolicyFile do parâmetro context , que é um objeto LoaderContext.

  • Ao incorporar uma imagem em um arquivo de texto usando a tag <img> , defina o atributo checkPolicyFile da tag <img> como "true" , da seguinte maneira:

    <img checkPolicyFile = "true" src = "example.jpg">
  • Ao usar o método Sound.load() , defina a propriedade checkPolicyFile do parâmetro context , que é um objeto SoundLoaderContext.

  • Ao usar a classe NetStream, defina a propriedade checkPolicyFile do objeto NetStream.

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 do 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) .