Estratégia de segurança do WPF – Segurança da Plataforma

Embora o WPF (Windows Presentation Foundation) forneça uma variedade de serviços de segurança, ele também aproveita os recursos de segurança da plataforma subjacente, que inclui o sistema operacional, o CLR e o Internet Explorer. Essas camadas se combinam para fornecer ao WPF um modelo de segurança forte e de defesa em profundidade que tenta evitar qualquer ponto único de falha, conforme mostrado na figura a seguir:

O restante deste tópico discute os recursos em cada uma dessas camadas que pertencem especificamente ao WPF.

Segurança do sistema operacional

O núcleo do Windows fornece vários recursos de segurança que formam a base de segurança para todos os aplicativos do Windows, incluindo aqueles criados com o WPF. Este tópico discute a amplitude desses recursos de segurança que são importantes para o WPF, bem como como o WPF se integra a eles para fornecer mais defesa detalhada.

Microsoft Windows XP Service Pack 2 (SP2)

Além de uma revisão geral e o fortalecimento do Windows, há três recursos importantes do Windows XP SP2 que discutiremos neste tópico:

• Compilação /GS

• Microsoft Windows Update.

Compilação /GS

O Windows XP SP2 fornece proteção recompilando muitas bibliotecas principais do sistema, incluindo todas as dependências do WPF, como o CLR, para ajudar a reduzir os excessos de buffer. Isso é obtido usando o parâmetro /GS com o compilador de linha de comando C/C++. Embora os excessos de buffer devam ser explicitamente evitados, a compilação /GS fornece um exemplo de uma defesa detalhada contra possíveis vulnerabilidades que são criadas inadvertidamente ou mal-intencionadas por elas.

Historicamente, os excessos de buffer têm sido a causa de muitas explorações de segurança de alto impacto. Uma sobrecarga de buffer ocorre quando um invasor se aproveita de uma vulnerabilidade de código que permite a injeção de código mal-intencionado que grava além dos limites de um buffer. Isso permite que um invasor sequestre o processo no qual o código está sendo executado substituindo o endereço de retorno de uma função para causar a execução do código do invasor. O resultado é um código mal-intencionado que executa código arbitrário com os mesmos privilégios que o processo sequestrado.

Em um alto nível, o sinalizador do compilador -GS protege contra alguns possíveis excessos de buffer injetando um cookie de segurança especial para proteger o endereço de retorno de uma função que tem buffers de cadeia de caracteres locais. Depois que uma função é retornada, o cookie de segurança é comparado com seu valor anterior. Se o valor tiver sido alterado, uma sobrecarga de buffer poderá ter ocorrido e o processo será interrompido com uma condição de erro. Parar o processo impede a execução de código potencialmente mal-intencionado. Consulte -GS (Verificação de Segurança do Buffer) para obter mais detalhes.

O WPF é compilado com o sinalizador /GS para adicionar mais uma camada de defesa aos aplicativos WPF.

Windows Vista

Os usuários do WPF no Windows Vista se beneficiarão dos aprimoramentos de segurança adicionais do sistema operacional, incluindo " acesso ao usuárioLeast-Privilege", verificações de integridade de código e isolamento de privilégios.

Controle de Conta de Usuário (UAC)

Hoje, os usuários do Windows tendem a operar com privilégios de administrador porque muitos aplicativos exigem tais privilégios para instalação e/ou execução. Ser capaz de gravar configurações de aplicativo padrão no Registro é um exemplo.

Executar com privilégios de administrador realmente significa que os aplicativos são executados a partir de processos que recebem privilégios de administrador. O impacto na segurança disso é que qualquer código mal-intencionado que sequestra um processo em execução com privilégios de administrador herdará automaticamente esses privilégios, incluindo o acesso a recursos críticos do sistema.

Uma maneira de proteger contra essa ameaça de segurança é executar aplicativos com a menor quantidade de privilégios necessários. Isso é conhecido como o princípio do privilégio mínimo e é um recurso principal do sistema operacional Windows. Esse recurso é chamado UAC (Controle de Conta de Usuário) e é usado pelo UAC do Windows de duas maneiras principais:

• Para executar a maioria dos aplicativos com privilégios UAC por padrão, mesmo que o usuário seja um administrador; somente aplicativos que precisam de privilégios de administrador serão executados com privilégios de administrador. Para serem executados com privilégios administrativos, os aplicativos devem ser explicitamente marcados no manifesto do aplicativo ou como uma entrada na política de segurança.

• Para fornecer soluções de compatibilidade, como virtualização. Por exemplo, muitos aplicativos tentam gravar em locais restritos, como C:\Arquivos de Programas. Para aplicativos em execução no UAC, existe uma localização alternativa por usuário que não exige privilégios de administrador para gravar. Para aplicativos em execução no UAC, o UAC virtualiza C:\Arquivos de Programas para que os aplicativos que pensam que estão gravando nele estejam realmente gravando na localização alternativa por usuário. Esse tipo de trabalho de compatibilidade permite que o sistema operacional execute muitos aplicativos que não podiam ser executados anteriormente no UAC.

Verificações de integridade de código

O Windows Vista incorpora verificações de integridade de código mais profundas para ajudar a impedir que código mal-intencionado seja injetado em arquivos do sistema ou no kernel em tempo de carregamento/execução. Isso vai além da proteção de arquivos do sistema.

Processo de direitos limitados para aplicativos Browser-Hosted

Aplicativos WPF hospedados pelo navegador são executados na área restrita da zona da Internet. A integração do WPF com o Microsoft Internet Explorer estende essa proteção com suporte adicional.

Como os XBAPs (aplicativos do navegador XAML) geralmente são protegidos pelo conjunto de permissões de zona da Internet, a remoção desses privilégios não prejudica os XBAPs (aplicativos do navegador XAML) de uma perspectiva de compatibilidade. Em vez disso, uma camada de defesa em profundidade adicional é criada; se um aplicativo em área restrita for capaz de explorar outras camadas e seqüestrar o processo, o processo ainda terá privilégios limitados.

Consulte Usando uma Conta de Usuário Least-Privileged.

Segurança do Common Language Runtime

O CLR (Common Language Runtime) oferece uma série de principais benefícios de segurança que incluem validação e verificação, CAS (Segurança de Acesso ao Código) e a Metodologia Crítica de Segurança.

Validação e verificação

Para fornecer isolamento e integridade do assembly, o CLR utiliza um processo de validação. A validação CLR garante que os assemblies sejam isolados ao validar o formato de arquivo PE (Executável Portátil) para endereços que apontam para fora dos assemblies. A validação CLR também valida a integridade dos metadados incorporados em um assembly.

Para garantir a segurança de tipos, ajudar a evitar problemas comuns de segurança (por exemplo, estouros de buffer) e permitir o uso de áreas restritas através do isolamento de subprocessos, a segurança do CLR usa o conceito de verificação.

Os aplicativos gerenciados são compilados na MSIL (Linguagem Intermediária da Microsoft). Quando os métodos em um aplicativo gerenciado são executados, seu MSIL é compilado em código nativo por meio da compilação JIT (Just-In-Time). A compilação JIT inclui um processo de verificação que aplica muitas regras de segurança e robustez que garantem que o código não:

• Violar contratos de tipo

• Introduzir sobrecargas de buffer

• Acessar a memória descontroladamente.

O código gerenciado que não está em conformidade com as regras de verificação não tem permissão para ser executado, a menos que seja considerado código confiável.

A vantagem do código verificável é um dos principais motivos pelos quais o WPF se baseia no .NET Framework. Na medida em que o código verificável é usado, a possibilidade de explorar possíveis vulnerabilidades é muito reduzida.

Segurança de Acesso ao Código

Um computador cliente expõe uma ampla variedade de recursos aos quais um aplicativo gerenciado pode ter acesso, incluindo o sistema de arquivos, o Registro, os serviços de impressão, a interface do usuário, a reflexão e as variáveis de ambiente. Antes que um aplicativo gerenciado possa acessar qualquer um dos recursos em um computador cliente, ele deve ter permissão do .NET Framework para fazer isso. Uma permissão no CAS é uma subclasse do CodeAccessPermission; O CAS implementa uma subclasse para cada recurso que os aplicativos gerenciados podem acessar.

O conjunto de permissões que um aplicativo gerenciado é concedido pelo CAS quando ele inicia a execução é conhecido como um conjunto de permissões e é determinado por evidências fornecidas pelo aplicativo. Para aplicativos WPF, a evidência fornecida é a localização ou zona da qual os aplicativos são iniciados. O CAS identifica as seguintes zonas:

• Meu computador. Aplicativos iniciados a partir do computador cliente (totalmente confiável).

• Intranet local. Aplicativos lançados a partir da intranet. (Um pouco confiável).

• Internet. Aplicativos iniciados pela Internet. (Menos confiável).

• Sites Confiáveis. Aplicativos identificados por um usuário como sendo confiáveis. (Menos confiável).

• Sites não confiáveis. Aplicativos identificados por um usuário como não confiáveis. (Não confiável).

Para cada uma dessas zonas, o CAS fornece um conjunto de permissões predefinido que inclui as permissões que correspondem ao nível de confiança associado a cada uma. Elas incluem:

• FullTrust. Para aplicativos iniciados na zona Meu Computador . Todas as permissões possíveis são concedidas.

• LocalIntranet. Para aplicativos iniciados a partir da zona intranet local . Um subconjunto de permissões é concedido para proporcionar acesso moderado aos recursos de uma máquina cliente, incluindo recursos isolados, acesso irrestrito à UI, diálogos de arquivos sem restrições, reflexão limitada e acesso limitado a variáveis de ambiente. Permissões para recursos críticos, como o Registro, não são fornecidas.

• Internet. Para aplicativos iniciados da zona da Internet ou de Sites Confiáveis. Um subconjunto de permissões é concedido para fornecer acesso limitado aos recursos de um computador cliente, incluindo armazenamento isolado, somente abertura de arquivo e interface do usuário limitada. Essencialmente, esse conjunto de permissões isola os aplicativos do computador cliente.

Os aplicativos identificados como sendo da zona Sites Não Confiáveis não recebem nenhuma permissão do CAS. Consequentemente, um conjunto de permissões predefinido não existe para eles.

A figura a seguir ilustra a relação entre zonas, conjuntos de permissões, permissões e recursos:

As restrições da área restrita de segurança da zona da Internet se aplicam igualmente a qualquer código que um XBAP importe de uma biblioteca do sistema, incluindo o WPF. Isso garante que todos os bits do código sejam bloqueados, até mesmo o WPF. Infelizmente, para ser capaz de executar, um XBAP precisa executar uma funcionalidade que exija mais permissões do que aquelas habilitadas pela área restrita de segurança da zona da Internet.

Considere um aplicativo XBAP que inclui a seguinte página:

FileIOPermission fp = new FileIOPermission(PermissionState.Unrestricted);
fp.Assert();

// Perform operation that uses the assert

// Revert the assert when operation is completed
CodeAccessPermission.RevertAssert();

Dim fp As New FileIOPermission(PermissionState.Unrestricted)
fp.Assert()

' Perform operation that uses the assert

' Revert the assert when operation is completed
CodeAccessPermission.RevertAssert()

Para executar esse XBAP, o código WPF subjacente deve executar mais funcionalidade do que está disponível para o XBAP de chamada, incluindo:

• Criando um identificador de janela (HWND) para renderização

• Expedindo mensagens

• Carregando a fonte Tahoma

Do ponto de vista de segurança, permitir o acesso direto a qualquer uma dessas operações do aplicativo em área restrita seria catastrófico.

Felizmente, o WPF atende a essa situação permitindo que essas operações sejam executadas com privilégios elevados em nome do aplicativo em ambiente controlado. Embora todas as operações do WPF sejam verificadas em relação às permissões limitadas de segurança de zona da Internet do domínio de aplicativo do XBAP, o WPF (como acontece com outras bibliotecas do sistema) recebe um conjunto de permissões que inclui todas as permissões possíveis.

Isso requer que o WPF receba privilégios elevados, impedindo que esses privilégios sejam regidos pelo conjunto de permissões de zona da Internet do domínio do aplicativo host.

O WPF faz isso utilizando o método Assert de uma permissão. O código a seguir mostra como isso acontece.

FileIOPermission fp = new FileIOPermission(PermissionState.Unrestricted);
fp.Assert();

// Perform operation that uses the assert

// Revert the assert when operation is completed
CodeAccessPermission.RevertAssert();

Dim fp As New FileIOPermission(PermissionState.Unrestricted)
fp.Assert()

' Perform operation that uses the assert

' Revert the assert when operation is completed
CodeAccessPermission.RevertAssert()

O Assert basicamente impede que as permissões ilimitadas exigidas pelo WPF sejam restritas pelas permissões de zona da Internet do XBAP.

Do ponto de vista da plataforma, o WPF é responsável por usar o Assert corretamente; um uso incorreto do Assert pode permitir que o código mal-intencionado eleve privilégios. Consequentemente, é importante chamar Assert apenas quando necessário e garantir que as restrições de área restrita permaneçam intactas. Por exemplo, o código em área restrita não tem permissão para abrir arquivos aleatórios, mas tem permissão para usar fontes. O WPF permite que aplicativos em área restrita usem a funcionalidade de fonte chamando Assert e que o WPF leia arquivos conhecidos por conter essas fontes em nome do aplicativo em área restrita.

Implantação do ClickOnce

O ClickOnce é uma tecnologia de implantação abrangente incluída no .NET Framework e integra-se ao Visual Studio (consulte a segurança e a implantação do ClickOnce para obter informações detalhadas). Aplicativos WPF autônomos podem ser implantados usando o ClickOnce, enquanto os aplicativos hospedados pelo navegador devem ser implantados com o ClickOnce.

Os aplicativos implantados usando o ClickOnce recebem uma camada de segurança adicional sobre o CAS (Code Access Security); Essencialmente, os aplicativos implantados do ClickOnce solicitam as permissões necessárias. Elas receberão apenas essas permissões se não excederem o conjunto de permissões para a zona da qual o aplicativo é implantado. Ao reduzir o conjunto de permissões somente para aqueles que são necessários, mesmo que sejam menores do que os fornecidos pelo conjunto de permissões da zona de inicialização, o número de recursos aos quais o aplicativo tem acesso é reduzido ao mínimo. Consequentemente, se o aplicativo for sequestrado, o potencial de danos ao computador cliente será reduzido.

Metodologia Security-Critical

O código WPF que utiliza permissões para habilitar a sandbox da zona da Internet para aplicativos XBAP deve ser submetido ao mais alto grau possível de auditoria e controle de segurança. Para facilitar esse requisito, o .NET Framework fornece um novo suporte para o gerenciamento de código que eleva o privilégio. Especificamente, o CLR permite identificar o código que eleva o privilégio e o marca com o SecurityCriticalAttribute; qualquer código não marcado SecurityCriticalAttribute se torna transparente usando essa metodologia. Por outro lado, o código gerenciado que não está marcado SecurityCriticalAttribute é impedido de elevar o privilégio.

A Metodologia de Security-Critical permite que a organização do código WPF aumente os privilégios para núcleo de segurança crítico, com o restante sendo transparente. Isolar o código crítico de segurança permite que a equipe de engenharia do WPF concentre uma análise de segurança adicional e controle do código-fonte no kernel crítico de segurança acima e além das práticas de segurança padrão (consulte Estratégia de Segurança do WPF – Engenharia de Segurança).

Observe que o .NET Framework permite que o código confiável estenda a área restrita da zona da Internet XBAP, permitindo que os desenvolvedores escrevam assemblies gerenciados marcados com AllowPartiallyTrustedCallersAttribute (APTCA) e implantados no GAC (Cache de Assembly Global) do usuário. Marcar um assembly com APTCA é uma operação de segurança altamente sensível, pois permite que qualquer código acione esse assembly, incluindo código mal-intencionado da Internet. As práticas recomendadas e de extrema cautela devem ser usadas ao fazer isso e os usuários devem optar por confiar nesse software para que ele seja instalado.

Segurança do Microsoft Internet Explorer

Além de reduzir problemas de segurança e simplificar a configuração de segurança, o Microsoft Internet Explorer 6 (SP2) contém vários recursos que aprimoram a segurança dos usuários de XBAPs (aplicativos do navegador XAML). O impulso desses recursos tenta permitir aos usuários maior controle sobre sua experiência de navegação.

Antes do IE6 SP2, os usuários podiam estar sujeitos a qualquer um dos seguintes:

• Janelas pop-up aleatórias.

• Redirecionamento de script confuso.

• Inúmeras caixas de diálogo de segurança em alguns sites.

Em alguns casos, sites não confiáveis tentariam enganar os usuários falsificando a interface do usuário da instalação ou mostrando repetidamente uma caixa de diálogo de instalação do Microsoft ActiveX, mesmo que o usuário possa tê-la cancelado. Usando essas técnicas, é possível que um número significativo de usuários tenha sido enganado para tomar decisões ruins que resultaram na instalação de aplicativos spyware.

O IE6 SP2 inclui vários recursos para atenuar esses tipos de problemas, que giram em torno do conceito de iniciação do usuário. O IE6 SP2 detecta quando um usuário clica em um link ou elemento de página antes de uma ação, que é conhecida como iniciação do usuário, e o trata de forma diferente de quando uma ação semelhante é disparada pelo script em uma página. Por exemplo, o IE6 SP2 incorpora um bloqueador dePop-Up que detecta quando um usuário clica em um botão antes da página criar um pop-up. Isso permite que o IE6 SP2 permita a maioria dos pop-ups inócuos, evitando pop-ups que os usuários não pedem nem querem. Pop-ups bloqueados estão presos na nova Barra de Informações, que permite ao usuário desativar manualmente o bloqueio e visualizar o pop-up.

A mesma lógica de iniciação do usuário também é aplicada aos prompts de segurança open/save . As caixas de diálogo de instalação do ActiveX estão sempre presas na Barra de Informações, a menos que representem uma atualização de um controle instalado anteriormente. Essas medidas se combinam para dar aos usuários uma experiência de usuário mais segura e controlada, uma vez que eles são protegidos contra sites que os assediam para instalar softwares indesejados ou mal-intencionados.

Esses recursos também protegem os clientes que usam o IE6 SP2 para navegar até sites que permitem que eles baixem e instalem aplicativos WPF. Em particular, isso ocorre porque o IE6 SP2 oferece uma experiência de usuário melhor que reduz a chance de os usuários instalarem aplicativos mal-intencionados ou desonestos, independentemente de qual tecnologia foi usada para compilá-la, incluindo o WPF. O WPF adiciona a essas proteções usando o ClickOnce para facilitar o download de seus aplicativos pela Internet. Como os XBAPs (aplicativos do navegador XAML) são executados em um sandbox de segurança da zona da Internet, eles podem ser iniciados de forma integrada. Por outro lado, aplicativos WPF autônomos exigem total confiança para serem executados. Para esses aplicativos, o ClickOnce exibirá uma caixa de diálogo de segurança durante o processo de inicialização para notificar o uso dos requisitos de segurança adicionais do aplicativo. No entanto, isso deve ser iniciado pelo usuário, também será regido pela lógica iniciada pelo usuário e pode ser cancelado.

O Internet Explorer 7 incorpora e estende os recursos de segurança do IE6 SP2 como parte de um compromisso contínuo com a segurança.

Consulte também

• Segurança de Acesso ao Código
• Segurança
• Segurança parcialmente confiável do WPF
• Estratégia de Segurança do WPF - Engenharia de Segurança