Estratégia de segurança do Windows Presentation Foundation - Segurança da Plataforma

Artigo
08/25/2010

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

Ilustração de segurança do WPF

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

Este tópico contém as seguintes seções.

Segurança do sistema operacional
Segurança no Common Language Runtime
Segurança no Microsoft Internet Explorer
Tópicos relacionados

Segurança do sistema operacional

O nível mínimo de sistema operacional exigido pelo WPF é o Windows XP SP2. O núcleo de Windows XP SP2 fornece vários recursos de segurança que formam a base de segurança para todos Windows aplicativos, incluindo aqueles criados com o WPF. Windows Vista incorpora os recursos de segurança do WPF e se estende ainda mais. Este tópico aborda a amplitude desses recursos de segurança que são importantes para o WPF, assim como o modo como o WPF se integra a eles para fornecer ainda mais proteção em profundidade.

Microsoft Windows XP Service Pack 2 (SP2)

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

Compilação /GS
Microsoft Windows Update.

Compilação com /GS

O Windows XP SP2 fornece proteção através da recompilação de muitas bibliotecas do núcleo do sistema, incluindo todas as dependências do WPF, como o CLR, para ajudar a mitigar estouros de buffer. Isso é obtido usando-se o parâmetro /GS do compilador C/C++ em linha de comando. Embora estouros de buffer devam ser explicitamente evitados, a compilação com /GS fornece um exemplo de proteção em profundidade contra possíveis vulnerabilidades criadas inadvertidamente ou de maneira mal-intencionada por eles.

Historicamente, estouros de buffer tem sido a causa de muitas vulnerabilidades de segurança de alto impacto. Um estouro de buffer ocorre quando um invasor aproveita uma vulnerabilidade de código que permite a inclusão de código mal-intencionado que escreve além dos limites de um buffer. Isso permite então que um invasor sequestre o processo no qual o código está sendo executado, sobrescrevendo o endereço de retorno de uma função para fazer com que o código do invasor seja executado. O resultado é código mal-intencionado que executa código arbitrário com os mesmos privilégios que o processo sequestrado.

Em alto nível, o parâmetro de compilador /GS protege contra alguns possíveis estouros de buffer ao injetar um cookie de segurança especial para proteger o endereço de retorno de uma função que tem buffers de string locais. Após uma função retornar, o cookie de segurança é comparado com seu valor anterior. Se o valor foi alterado, pode ter ocorrido um estouro do buffer e o processo é interrompido com uma condição de erro. Interromper o processo impede a execução de código possivelmente mal-intencionado. See /GS (verificação de segurança de buffer) para obter mais detalhes.

O WPF é compilado com o parâmetro /GS para adicionar ainda outra camada de defesa aos aplicativos WPF.

Aprimoramentos do Microsoft Windows Update

O Microsoft Windows Update também foi aprimorado no Windows XP SP2 para simplificar o processo de download e instalação de atualizações. Essas alterações aumentam significativamente a segurança para clientes WPF ao ajudar a garantir que seus sistemas estão atualizados, especialmente com relação às atualizações de segurança.

Windows Vista

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

Controle de conta de usuário (UAC)

Hoje em dia, os usuários Windows tendem a usar o sistema com privilégios de administrador pois muitos aplicativos os requerem para sua instalação ou execução, ou ambos. Poder gravar as configurações padrão do aplicativo no registro é um exemplo.

Usar o sistema com privilégios de administrador na verdade significa que os aplicativos são executados a partir de processos que têm privilégios de administrador. O impacto de segurança disto é que qualquer código mal-intencionado que sequestre um processo executado com privilégios de administrador herdará automaticamente esses privilégios, incluindo o acesso aos recursos críticos do sistema.

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

Executar a maioria dos aplicativos com privilégios UAC por padrão, mesmo se o usuário for um administrador; somente aplicativos que precisam de privilégios de administrador serão executado com privilégios de administrador. Para executar com privilégios administrativos, os aplicativos devem ser explicitamente marcados em seus manifestos de aplicativo ou como uma entrada na política/diretiva 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 executando em UAC, existe um local alternativo, por usuário, que não requer privilégios de administrador para escrita. Para aplicativos executados em UAC, o UAC virtualiza o "C:\Arquivos de programas" de modo que os aplicativos que acham que estão escrevendo lá, estão na verdade escrevendo no local alternativo (por usuário). Esse tipo de esforço de compatibilidade permite que o sistema operacional execute vários aplicativos que anteriormente não poderiam ser executados em 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 carga/execução. Isso vai além da proteção de arquivos do sistema.

Processos com direitos limitados para aplicativos hospedados em navegador

Hospedado no navegador WPF aplicativos executados dentro de área de segurança de zona Internet. WPF integração com o Microsoft Internet Explorer estende essa proteção com suporte adicional.

Internet Explorer 6 Service Pack 2 e Internet Explorer 7 para XP

O WPF auxilia a segurança do sistema operacional, limitando os privilégios dos processo das aplicativos de navegador XAML (XBAPs) para obter mais proteção. Antes que um aplicativo WPF hospedado em navegador seja iniciado, o sistema operacional cria um processo host que remove os privilégios desnecessários do identificador do processo. Alguns exemplos de privilégios que são removidos incluem a capacidade de desligar a máquina do usuário, carregar drivers e acesso de leitura a todos os arquivos no computador.

Internet Explorer 7 para Vista

No Windows Internet Explorer 7, os aplicativos WPF são executados em modo protegido. Especificamente, as aplicativos de navegador XAML (XBAPs) executam com integridade de nível médio.

Camada de defesa em profundidade

Já que as aplicativos de navegador XAML (XBAPs) são geralmente executadas em modo seguro pelo conjunto de permissões da zona Internet, remover esses privilégios não danifica as aplicativos de navegador XAML (XBAPs) de uma perspectiva de compatibilidade. Em vez disso, uma camada adicional de proteção em profundidade é criada; se um aplicativo em modo seguro for capaz de explorar outras camadas e sequestrar o processo, o processo ainda terá apenas privilégios limitados.

See Usando uma conta de usuário Least-Privileged.

Segurança no Common Language Runtime

O common language runtime (CLR) oferece vários benefícios chave de segurança que incluem validação e verificação, Segurança de Acesso a Código (CAS), e a metodologia de segurança crítica.

Validação e verificação

Para fornecer isolamento de assembly e integridade, a CLR usa um processo de validação. CLR a validação garante que os assemblies são isolados, validando seu formato de arquivo executável portátil (PE) para endereços que aponte fora do assembly. CLR validação também valida a integridade dos metadados é incorporado dentro de um assembly.

Para garantir a segurança de tipos, ajudar a evitar problemas comuns de segurança (por exemplo saturações de buffer) e ativar o modo seguro por meio do isolamento subprocesso, CLR segurança usa o conceito de verificação.

Aplicativos gerenciados são compilados em Microsoft Intermediate Language (MSIL). Quando métodos em um aplicativo gerenciado são executados, o MSIL é compilado em código nativo por meio de compilação Just-In-Time (JIT). A compilação JIT inclui um processo de verificação que aplica regras de segurança e robustez que asseguram o código não:

Viola contratos de tipo
Apresenta estouros de buffer
Acessa a memória de maneira descuidada.

Código gerenciado que não esteja de acordo com as regras de verificação tem sua execução negada, a menos que ele seja considerado código confiável.

A vantagem de ter código verificável é uma razão chave do porque do WPF se basear no .NET Framework. Na medida em que código verificável é usado, a possibilidade de explorar possíveis vulnerabilidades é bastante reduzida.

Segurança de Acesso de código

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

O conjunto de permissões que é concedido a um aplicativo gerenciado pelo CAS quando ele é iniciado é conhecido como um conjunto de permissões e é determinado pelas "provas" fornecidas pelo aplicativo. For WPF aplicativos, a evidência que é fornecida é o local ou zona, da qual os aplicativos são iniciados. CAS identifica as seguintes zonas:

Meu computador. Aplicativos iniciados a partir da máquina do cliente (totalmente confiável).
Intranet local. Aplicativos iniciados a partir da intranet. (Um pouco confiáveis).
Internet. Aplicativos iniciados a partir da 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 sendo não confiáveis. (Não confiável).

Para cada uma dessas zonas, o CAS fornece uma conjunto de permissões predefinidas que inclui as permissões que coincidem com o nível de confiança associada a cada zona. Eles incluem:

FullTrust. Para aplicativos iniciados a partir da zona Meu computador . Todas as possíveis permissões são concedidas.
LocalIntranet. Para aplicativos iniciados a partir da zona Intranet local . Um subconjunto de permissões é concedido para fornecer acesso moderado aos recursos de uma máquina cliente, incluindo armazenamento isolado, acesso irrestrito a interface do usuário, caixas de diálogo de arquivo irrestritas, reflexão limitada, 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 a partir das zonas Internet ou Sites confiáveis. Um subconjunto de permissões é concedido para permitir acesso limitado aos recursos de uma máquina cliente, incluindo armazenamento isolado, apenas abertura de arquivo e interface do usuário limitada. Essencialmente, esses conjuntos de permissões isolam os aplicativos da máquina cliente.

Aplicativos identificados como sendo da zona Sites não confiáveis não recebem permissões do CAS. Consequentemente, um conjunto de permissões predefinidas não existe para eles.

A figura a seguir ilustra o relacionamento entre as zonas, conjuntos de permissões, permissões e recursos.

Conjuntos de permissões CAS

As restrições de proteção de segurança da zona Internet se aplicam igualmente a qualquer código que uma XBAP importa de uma biblioteca do sistema, incluindo o WPF. Isso garante que cada pedaço do código está protegido, até o WPF. Infelizmente, para poder executar, uma XBAP precisa executar funcionalidades que requerem mais permissões do que aquelas ativadas pelo modo de segurança da zona Internet.

Considere um aplicativo XBAP que inclua 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();

Para executar esta XBAP, o código WPF subjacente deve executar mais funcionalidades que as disponíveis para a XBAP, incluindo:

Criar um manipulador de janela (hWnd) para renderização
Distribuir as mensagens
Carregar a fonte Tahoma

Do ponto de vista de segurança, permitir acesso direto a qualquer uma dessas operações pelo aplicativo em modo seguro seria catastrófico.

Felizmente, o WPF atenta para essa situação, permitindo que essas operações executem com privilégios elevados em nome do aplicativo no modo seguro. Enquanto todas as operações WPF são verificadas contra as permissões de segurança limitadas da zona Internet do domínio de aplicativo da XBAP, o WPF (como 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 enquanto impede que esses privilégios sejam regidos pelo conjunto de permissões da zona Internet do domínio do aplicativo host .

O WPF faz isso usando 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();

O Assert essencialmente impede que as permissões ilimitadas necessárias ao WPF sejam restritas pelas permissões da zona Internet da XBAP.

Da perspectiva da plataforma, o WPF é responsável por usar Assert corretamente; um uso incorreto de Assert pode ativar código mal-intencionado para elevar privilégios. Consequentemente, é importante somente chamar Assert quando necessário e garantir que as restrições do modo seguro permanecem intactas. Por exemplo, código no modo seguro não tem permissão para em em aberto arquivos aleatórios, mas ele tem permissão para usar fontes. WPF permite que os aplicativos em modo seguro usar a funcionalidade de fonte chamando Declarar, and for WPF para ler arquivos conhecidos por conter essas fontes no nome do aplicativo no modo seguro.

Implantação do ClickOnce

ClickOnce é uma tecnologia de implantação abrangente incluída .NET Frameworke integra-se Microsoft Visual Studio (consulte a ClickOnce Deployment visão geral para obter informações detalhadas). Aplicativos WPF autônomos podem ser implantados usando ClickOnce, enquanto aplicativos hospedados em navegador têm que ser implantados com ClickOnce.

Os aplicativos implantados usando ClickOnce recebem uma camada adicional de segurança sobre o Segurança de Acesso a Código (CAS); essencialmente os aplicativos implantados via ClickOnce solicitam as permissões de que eles precisam. Eles apenas recebem essas permissões se eles não excedem o conjunto de permissões para a zona a partir da qual o aplicativo será implantado. Reduzindo o conjunto de permissões para somente aquelas que são necessárias, mesmo se elas são menos do que aquelas fornecidas pelo conjunto de permissões da zona de inicialização, se reduz o número de recursos a que o aplicativo tem acesso a um mínimo. Consequentemente, se o aplicativo é sequestrado, o potencial de danos ao computador cliente é reduzido.

Metodologia de segurança crítica

O código WPF que usa as permissões para ativar o modo seguro da zona Internet para aplicativos XBAP deve ser mantido no grau mais alto possível de auditoria e controle de segurança. Para facilitar esse requisito, o .NET Framework oferece suporte novo para o gerenciamento de código que eleva privilégios. Especificamente, o CLR permite que você identifique o código que eleva privilégios e marque-o com o SecurityCriticalAttribute; qualquer código não marcado com SecurityCriticalAttribute torna-se transparente usando esta metodologia. Por outro lado, código gerenciado que não está marcado com SecurityCriticalAttribute será impedido de elevar privilégios.

A metodologia de segurança crítica permite a organização do código do WPF que eleva privilégios em núcleo de segurança crítica, com o restante sendo transparente. Isolar o código de segurança crítica permite que a equipe de engenharia do WPF mantenha o foco em análises de segurança adicionais e no controle de código-fonte do núcleo de segurança crítica, de modo acima e além das práticas de segurança padrão (consulte Estratégia de segurança do Windows Presentation Foundation - Engenharia de Segurança).

Observe que o .NET Framework permite que código confiável possa estender o modo seguro da zona Internet de uma XBAP, permitindo que desenvolvedores escrevam conjuntos de módulos (assemblies) gerenciados que sejam marcados com AllowPartiallyTrustedCallersAttribute (APTCA) e implantados no Global Assembly Cache (GAC) do usuário. Marcar um conjunto de módulos (assembly) com APTCA é uma operação altamente delicada de segurança, pois isso permite que qualquer código chame esse conjunto de módulos, inclusive código mal-intencionado a partir da Internet. Extrema cautela e práticas recomendadas devem ser usadas ao fazer isso e os usuários devem optar por confiar nesse software para que ele possa ser instalado.

Segurança no 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 e aperfeiçoamentos de segurança que melhoram a segurança para usuários de aplicativos de navegador XAML (XBAPs). O foco desses recursos tenta permitir aos usuários um maior controle sobre sua experiência de navegação.

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

Janelas popup aleatórias.
Redirecionamento confuso de scripts.
Vários diálogos de segurança em alguns sites da Web.

Em alguns casos, sites não confiáveis poderiam tentar enganar os usuários fazendo spoofing de interface do usuário (UI) de instalação ou repetidamente mostrando uma caixa de diálogo de instalação de Microsoft ActiveX, mesmo que o usuário pudesse ter cancelado-a. Usando essas técnicas, é possível que um número significativo de usuários tenha sido levado a tomar decisões ruim que resultaram na instalação de aplicativos de spyware.

IE6 SP2 inclui vários recursos para atenuar esses tipos de problemas, que giram em torno do conceito de iniciação do usuário. IE6 SP2 detecta quando um usuário clicar em um elemento link ou a página antes de uma ação, que é conhecido sistema autônomo inicialização de usuário e trata diferente quando uma ação semelhante em vez disso, for disparada pelo script em uma página. Como exemplo, o IE6 SP2 incorpora um bloqueador de pop-ups que detecta quando um usuário clica em um botão antes que a página crie uma janela pop-up. Isso permite que o IE6 SP2 permita os pop-ups mais inofensivos e evite pop-ups que os usuários não pedem nem desejam. Pop-ups bloqueados são interceptados sob a nova barra de informações, que permite ao usuário e passar por cima do bloqueio e exibir a janela pop-up manualmente.

A mesma lógica de inicialização de usuário será também aplicada às em aberto/Salvar segurança solicita. ActiveX caixas de diálogo de instalação sempre são preso debaixo da BAR de informações, a menos que eles representam uma atualização de um controle instalado anteriormente. Essas medidas combinam-se para fornecer aos usuários uma experiência do usuário mais segura e mais controlada, já que eles estão protegidos contra sites que os importunam para instalar software mal-intencionado ou indesejado.

Esses recursos também protegem os clientes que usam o IE6 SP2 para navegar por sites da Web que permitem a eles fazer download e instalar aplicativos WPF. Em particular, isso ocorre porque IE6 SP2 oferece uma melhor experiência ao usuário que reduz as chances dos usuários instalem aplicativos mal-intencionados ou sorrateiro independentemente de ter que tecnologia foi usada para criá-la, incluindo WPF. WPF Adiciona a essas proteções, usando ClickOnce para facilitar o download de seus aplicativos pela Internet. Já que as aplicativos de navegador XAML (XBAPs) executam em um modo protegido de segurança da zona Internet, podem ser iniciadas sem problemas. Por outro lado, aplicativos WPF autônomos exigem confiança total para executar. 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, esse processo deve ser iniciado pelo usuário, também será regido pela lógica de iniciação 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 segurança.