Estratégia de segurança do WPF – segurança da plataforma
Embora o Windows Presentation Foundation (WPF) 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 em profundidade.
SP2 (Microsoft Windows XP Service Pack 2)
Além de uma revisão geral e do fortalecimento do Windows, há três recursos principais do Windows XP SP2 que discutiremos neste tópico:
Compilação com /GS
Atualização do Microsoft Windows.
Compilação com /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 as saturações de buffer. Isso é feito pelo uso do parâmetro /GS com o compilador de linha de comando C/C++. Embora seja necessário evitar estouros de buffer explicitamente, a compilação com /GS fornece um exemplo de uma proteção extensa contra possíveis vulnerabilidades que são criadas de maneira inadvertida ou mal-intencionada por eles.
Historicamente, os estouros de buffer tem sido a causa de diversas explorações de segurança de alto impacto. Um estouro de buffer ocorre quando um invasor aproveita uma vulnerabilidade de código que permite a injeção de um código mal-intencionado escrito além dos limites de um buffer. Em seguida, isso permite que um invasor sequestre o processo no qual o código está em execução, substituindo o endereço de retorno de uma função para fazer com que o código do invasor seja executado. O resultado é um código mal-intencionado que executa um código arbitrário com os mesmos privilégios do processo sequestrado.
Em um alto nível, o sinalizador do compilador -GS protege contra algumas possíveis saturações 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. Após o retorno de uma função, o cookie de segurança é comparado com seu valor anterior. Se o valor tiver sido alterado, poderá ter ocorrido um estouro de buffer e o processo será interrompido com uma condição de erro. A interrupção do processo impede a execução do 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 de Usuário com Privilégios Mínimos", 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 executar com privilégios de administrador porque muitos aplicativos os exigem para instalação ou execução, ou ambos. Ter a capacidade de escrever configurações de aplicativo padrão no Registro é um exemplo.
De fato, a execução com privilégios de administrador significa que os aplicativos são executados em processos que receberam 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 a 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 do privilégio mínimo e é um recurso central do sistema operacional Windows. Esse recurso é chamado de 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 se o usuário for um administrador; somente os 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 em seus manifestos do aplicativo ou como uma entrada na política de segurança.
Para fornecer soluções de compatibilidade como virtualização. Por exemplo, vários aplicativos tentam gravar em localizações restritas como C:\Program Files. Para os aplicativos executados no UAC, existe uma localização alternativa por usuário que não exige privilégios de administrador para ser usada para gravação. Para os aplicativos executados no UAC, o UAC virtualiza C:\Program Files para que os aplicativos que acreditam que estão fazendo gravações nele, na verdade, estão gravando na localização alternativa por usuário. Esse tipo de trabalho de compatibilidade permite que o sistema operacional execute vários aplicativos que anteriormente não podiam ser executados no UAC.
Verificações de integridade de código
O Windows Vista incorpora verificações mais profundas de integridade de código para ajudar a impedir que códigos mal-intencionados sejam injetados em arquivos do sistema ou no kernel em tempo de carregamento/execução. Isso vai além da proteção de arquivo do sistema.
Processos com direitos limitados para aplicativos hospedados pelo navegador
Os aplicativos WPF hospedados no 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.
Aviso
Os XBAPs exigem navegadores legados para operar, como o Internet Explorer e versões antigas do Firefox. Esses navegadores mais antigos geralmente não são compatíveis com Windows 10 e Windows 11. Os navegadores modernos não suportam mais a tecnologia necessária para aplicativos XBAP devido a riscos de segurança. Plug-ins que habilitam XBAPs não são mais suportados. Para obter mais informações, consulte Perguntas frequentes sobre aplicativos hospedados no navegador do WPF (XBAP).
Como os aplicativos de navegador XAML (XBAPs) geralmente são colocados em área restrita pelo conjunto de permissões de zona da Internet, a remoção desses privilégios não prejudica os aplicativos de navegador XAML (XBAPs) de uma perspectiva de compatibilidade. Em vez disso, é criada uma camada adicional de proteção extensa; se um aplicativo em área restrita puder explorar outras camadas e sequestrar o processo, ainda assim, o processo apenas terá privilégios limitados.
Consulte Usando uma conta de usuário de privilégios mínimos.
Segurança do Common Language Runtime
O CLR (Common Language Runtime) oferece vários benefícios de segurança importantes 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 usa um processo de validação. A validação CLR garante que os assemblies sejam isolados validando seu formato de arquivo PE (Portable Executable) para endereços que apontam para fora do assembly. A validação CLR também valida a integridade dos metadados inseridos em um assembly.
Para garantir a segurança de tipo, ajudar a evitar problemas comuns de segurança (por exemplo, saturações de buffer) e habilitar a área restrita por meio do isolamento de subprocesso, a segurança CLR usa o conceito de verificação.
Os aplicativos gerenciados são compilados em MSIL (Microsoft Intermediate Language). Quando os métodos em um aplicativo gerenciado são executados, a MSIL é compilada 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 várias regras de segurança e robustez que garantem que o código não:
Viola contratos de tipos
Introduz estouros de buffer
Acessa a memória de forma ampla.
O código gerenciado que não está em conformidade com as regras de verificação não tem permissão de ser executado, a menos que seja considerado um 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 um código verificável é usado, a possibilidade de exploração de possíveis vulnerabilidades é consideravelmente reduzida.
Segurança de Acesso do Código
Um computador cliente expõe uma grande variedade de recursos aos quais um aplicativo gerenciado pode 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 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 recebe do CAS quando ele começa a ser executado é conhecido como um conjunto de permissões e é determinado pelas evidências fornecidas pelo aplicativo. Para aplicativos WPF, a evidência fornecida é o local, ou zona, a partir do qual os aplicativos são iniciados. O CAS identifica as seguintes zonas:
Meu Computador. Aplicativos iniciados no computador cliente (Totalmente Confiável).
Intranet local. Aplicativos iniciados na intranet. (Um Pouco Confiáveis).
Internet. Aplicativos iniciados na Internet. (Os Menos Confiáveis).
Sites confiáveis. Aplicativos identificados por um usuário como sendo confiáveis. (Os Menos Confiáveis).
Sites não confiáveis. Aplicativos identificados por um usuário como sendo não confiáveis. (Não Confiáveis).
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. Estão incluídos:
FullTrust. Para aplicativos iniciados na zona Meu Computador. Todas as permissões possíveis são concedidas.
LocalIntranet. Para aplicativos iniciados na zona Intranet Local. Um subconjunto de permissões é concedido para fornecer acesso moderado aos recursos do computador cliente, incluindo armazenamento isolado, acesso irrestrito à interface do usuário, caixas de diálogo de arquivo irrestritas, 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 na zona Internet ou Sites Confiáveis. Um subconjunto de permissões é concedido para permitir acesso limitado aos recursos do computador cliente, incluindo armazenamento isolado, somente abertura de arquivo e interface do usuário limitada. Essencialmente, esse conjunto de permissões isola os aplicativos da máquina cliente.
Os aplicativos identificados como sendo da zona de Sites Não Confiáveis não recebem nenhuma permissão do CAS. Consequentemente, não existe um conjunto de permissões predefinidas 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 importa de uma biblioteca do sistema, incluindo o WPF. Isso garante que cada bit do código seja bloqueado, até mesmo o WPF. Infelizmente, para poder ser executado, um XBAP precisa executar uma funcionalidade que requer mais permissões do que aquelas habilitadas pela área restrita de segurança da zona da Internet.
Aviso
Os XBAPs exigem navegadores legados para operar, como o Internet Explorer e versões antigas do Firefox. Esses navegadores mais antigos geralmente não são compatíveis com Windows 10 e Windows 11. Os navegadores modernos não suportam mais a tecnologia necessária para aplicativos XBAP devido a riscos de segurança. Plug-ins que habilitam XBAPs não são mais suportados. Para obter mais informações, consulte Perguntas frequentes sobre aplicativos hospedados no navegador do WPF (XBAP).
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();
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 funcionalidades do que as disponíveis para o XBAP de chamada, incluindo:
Criando um identificador de janela (HWND) para renderização
Expedição de mensagens
Carregamento da fonte Tahoma
De um ponto de vista de segurança, permitir o acesso direto a qualquer uma dessas operações pelo 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 área restrita. 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 do aplicativo do XBAP, o WPF (assim 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 controlados pelo conjunto de permissões de zona da 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();
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 essencialmente 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 Assert corretamente; um uso incorreto de Assert pode permitir que código mal-intencionado eleve privilégios. Consequentemente, é importante chamar Assert somente quando necessário e garantir que as restrições da área restrita permanecem intactas. Por exemplo, um 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 se integra ao Visual Studio (consulte Segurança e implantação do ClickOnce para obter informações detalhadas). Aplicativos WPF autônomos podem ser implantados usando o ClickOnce, enquanto aplicativos hospedados no 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 de que precisam. Eles recebem somente as permissões se eles não excedem o conjunto de permissões para a zona da qual o aplicativo é implantado. Ao reduzir o conjunto de permissões apenas para aquelas que são necessárias, mesmo que sejam menores do que as fornecidas pelo conjunto de permissões da zona de execuçã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 Crítica para Segurança
O código WPF que usa permissões para habilitar a área restrita da zona da Internet para aplicativos XBAP deve ser mantido no mais alto grau possível de auditoria e controle de segurança. Para facilitar esse requisito, o .NET Framework fornece um novo suporte para gerenciar o código que eleva o privilégio. Especificamente, o CLR permite que você identifique o código que eleva o privilégio e marque-o com o SecurityCriticalAttribute; qualquer código não marcado com SecurityCriticalAttribute torna-se transparente usando essa metodologia. Por outro lado, o código gerenciado que não está marcado com SecurityCriticalAttribute é impedido de elevar o privilégio.
Aviso
Os XBAPs exigem navegadores legados para operar, como o Internet Explorer e versões antigas do Firefox. Esses navegadores mais antigos geralmente não são compatíveis com Windows 10 e Windows 11. Os navegadores modernos não suportam mais a tecnologia necessária para aplicativos XBAP devido a riscos de segurança. Plug-ins que habilitam XBAPs não são mais suportados. Para obter mais informações, consulte Perguntas frequentes sobre aplicativos hospedados no navegador do WPF (XBAP).
A Metodologia Crítica de Segurança permite a organização do código WPF que eleva o privilégio ao kernel crítico de segurança, 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 um APTCA é uma operação de segurança altamente confidencial, pois permite que qualquer código chame esse assembly, incluindo um código mal-intencionado da Internet. Deve-se ter extremo cuidado e usar as melhores práticas 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 os 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 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.
Aviso
Os XBAPs exigem navegadores legados para operar, como o Internet Explorer e versões antigas do Firefox. Esses navegadores mais antigos geralmente não são compatíveis com Windows 10 e Windows 11. Os navegadores modernos não suportam mais a tecnologia necessária para aplicativos XBAP devido a riscos de segurança. Plug-ins que habilitam XBAPs não são mais suportados. Para obter mais informações, consulte Perguntas frequentes sobre aplicativos hospedados no navegador do WPF (XBAP).
Antes do IE6 SP2, os usuários podiam estar sujeitos a qualquer um dos seguintes:
Janelas pop-up aleatórias.
Redirecionamento de script confuso.
Várias 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 de instalação ou mostrando repetidamente uma caixa de diálogo de instalação do Microsoft ActiveX, mesmo que o usuário a tenha cancelado. Usando essas técnicas, é possível que um número significativo de usuários tenha sido levado a tomar decisões erradas 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 clicou em um link ou elemento de página antes de uma ação, o que é conhecido como inicialização do usuário, e o trata de forma diferente do que quando uma ação semelhante é disparada pelo script em uma página. Por exemplo, o IE6 SP2 incorpora um Bloqueador de Pop-Up que detecta quando um usuário clica em um botão antes de a 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 solicitam nem desejam. Os pop-ups bloqueados são interceptados na nova Barra de Informações, que permite ao usuário substituir o bloco manualmente e exibir o pop-up.
A mesma lógica de iniciação pelo usuário também se aplica aos prompts de segurança Abrir/Salvar. 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 são combinadas 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 induzem a instalar software indesejado ou mal-intencionado.
Esses recursos também protegem os clientes que usam o IE6 SP2 para navegar em sites que permitem baixar e instalar aplicativos WPF. Em particular, isso ocorre porque o IE6 SP2 oferece uma melhor experiência do usuário que reduz a chance de os usuários instalarem aplicativos mal-intencionados ou desonestos, independentemente da tecnologia usada para criá-los, incluindo o WPF. O WPF aumenta essas proteções usando o ClickOnce para facilitar o download de seus aplicativos pela Internet. Como os aplicativos de navegador XAML (XBAPs) são executados em uma área restrita de segurança de zona da Internet, eles podem ser iniciados sem problemas. Por outro lado, aplicativos WPF autônomos exigem confiança total 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.
Confira também
.NET Desktop feedback