Estratégia de Segurança 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 profunda 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 ao WPF especificamente.
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 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.
Microsoft Windows XP Service Pack 2 (SP2)
Além de uma revisão geral e fortalecimento do Windows, há três recursos principais do Windows XP SP2 que discutiremos neste tópico:
Compilação GS
Atualização do Microsoft Windows.
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 mitigar saturações de buffer. Isso é conseguido usando o parâmetro /GS com o compilador de linha de comando C/C++. Embora as saturações de buffer devam ser explicitamente evitadas, a compilação /GS fornece um exemplo de defesa profunda contra vulnerabilidades potenciais criadas inadvertidamente ou maliciosamente por elas.
Historicamente, as saturações de buffer têm sido a causa de muitas explorações de segurança de alto impacto. Uma saturação de buffer ocorre quando um invasor aproveita 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 interrompa o processo em que o código é executado, substituindo o endereço de retorno de uma função e assim causar a execução do código do invasor. O resultado é um código malicioso que executa código arbitrário com os mesmos privilégios do processo sequestrado.
Em um nível alto, 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 tenha buffers de cadeia de caracteres locais. Depois que uma função retorna, o cookie de segurança é comparado com seu valor anterior. Se o valor tiver sido alterado, pode ter ocorrido uma saturação de buffer e o processo é interrompido com uma condição de erro. Parar o processo impede a execução de código potencialmente malicioso. Consulte -GS (Buffer Security Check) 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árioLeast-Privilege", verificações de integridade de código e isolamento de privilégios.
Controle de Conta de Usuário (UAC)
Hoje, os utilizadores do Windows tendem a operar com privilégios de administrador porque muitos aplicativos os exigem para instalação ou execução, ou ambos. Ser capaz de escrever configurações padrão do aplicativo para o Registro é um exemplo.
A execução com privilégios de administrador realmente significa que os aplicativos são executados a partir de processos aos quais são concedidos privilégios de administrador. O impacto de segurança disso é que qualquer código mal-intencionado que sequestre 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 se proteger contra essa ameaça à segurança é executar aplicativos com a menor quantidade de privilégios necessários. Isso é conhecido como o princípio do menor privilégio e é um recurso central do sistema operacional Windows. Esse recurso é chamado de Controle de Conta de Usuário (UAC) 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 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 no manifesto do aplicativo ou como uma entrada na diretiva de segurança.
Para fornecer soluções de compatibilidade, como virtualização. Por exemplo, muitos aplicativos tentam gravar em locais restritos como C:\Program Files. Para aplicativos executados no UAC, existe um local alternativo por usuário que não requer privilégios de administrador para gravar. Para aplicações executadas no UAC, o UAC virtualiza C:\Programas para que as aplicações que pensam estar a gravar nele na verdade estejam a gravar no local alternativo definido por utilizador. 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 mais profundas de integridade de código para ajudar a evitar que códigos mal-intencionados sejam injetados em arquivos do sistema ou no kernel em tempo de carga/execução. Isso vai além da proteção de arquivos do sistema.
Processo de Direitos Limitados para Aplicações Browser-Hosted
Os aplicativos WPF hospedados no navegador são executados dentro da área restrita da zona da Internet. A integração do WPF com o Microsoft Internet Explorer estende essa proteção com suporte adicional.
Advertência
Os XBAPs requerem navegadores herdados para funcionar, como o Internet Explorer e versões antigas do Firefox. Esses navegadores mais antigos geralmente não são suportados no Windows 10 e no 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 freqüentes sobre aplicativos hospedados no navegador WPF (XBAP).
Como os aplicativos de navegador XAML (XBAPs) geralmente são protegidos pelo conjunto de permissões da zona da Internet, a remoção desses privilégios não prejudica os aplicativos de navegador XAML (XBAPs) de uma perspetiva de compatibilidade. Em vez disso, uma camada adicional de defesa em profundidade é criada; Se um aplicativo em área restrita for capaz de explorar outras camadas e sequestrar 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 Common Language Runtime (CLR) oferece vários benefícios de segurança importantes que incluem validação e verificação, CAS (Code Access Security) e a Metodologia Crítica de Segurança.
Validação e Verificação
Para garantir isolamento e integridade de assemblies, o CLR utiliza um processo de validação. A validação CLR garante que os assemblies sejam isolados validando o formato de arquivo PE (Portable Executable) para os endereços que apontem para fora dos limites do assembly. A validação CLR também valida a integridade dos metadados incorporados em um conjunto.
Para garantir a segurança de tipos, ajudar a evitar problemas de segurança comuns (por exemplo, saturações de buffer) e habilitar sandboxing através do isolamento de subprocessos, a segurança CLR usa o conceito de verificação.
Os aplicativos gerenciados são compilados em Microsoft Intermediate Language (MSIL). Quando os métodos em um aplicativo gerenciado são executados, seu MSIL é compilado em código nativo por meio da compilação Just-In-Time (JIT). 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-tipo
Introduzir saturações de buffer
Acesso descontrolado à memória.
O código gerenciado que não está em conformidade com as regras de verificação não pode ser executado, a menos que seja considerado código confiável.
A vantagem do código verificável é uma das principais razões pelas 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
Uma máquina 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 uma máquina 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 por 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 a partir da máquina cliente (Totalmente confiável).
Intranet Local. Aplicações iniciadas a partir da intranet. (Pouco confiável)
Internet. Aplicações lançadas a partir da Internet. (Menos confiável).
Sites confiáveis. Aplicativos identificados por um usuário como 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 predefinidas que inclui as permissões que correspondem ao nível de confiança associado a cada uma. Estes incluem:
FullTrust. Para aplicações lançadas a partir da zona O Meu Computador. Todas as permissões possíveis são concedidas.
LocalIntranet. Para aplicações iniciadas a partir da zona de da Intranet Local
. Um subconjunto de permissões é concedido para fornecer acesso moderado aos recursos de uma máquina cliente, incluindo armazenamento isolado, acesso irrestrito à interface de utilizador, caixas de diálogo de ficheiro sem restrições, reflexão limitada, acesso limitado a variáveis de ambiente. As permissões para recursos críticos, como o Registro, não são fornecidas. Internet. Para aplicações iniciadas a partir da zona Internet ou Sites Confiáveis. Um subconjunto de permissões é concedido para fornecer acesso limitado aos recursos de uma máquina cliente, incluindo armazenamento isolado, somente arquivo aberto 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
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 aplicam-se igualmente a qualquer código que um XBAP importe de uma biblioteca do sistema, incluindo WPF. Isso garante que cada bit do código seja bloqueado, até mesmo o WPF. Infelizmente, para ser capaz de executar, um XBAP precisa executar uma funcionalidade que requer mais permissões do que as habilitadas pela área restrita de segurança da zona da Internet.
Advertência
Os XBAPs requerem navegadores herdados para funcionar, como o Internet Explorer e versões antigas do Firefox. Esses navegadores mais antigos geralmente não são suportados no Windows 10 e no 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 freqüentes sobre aplicativos hospedados no navegador 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 este XBAP, o código WPF subjacente deve executar mais funcionalidade do que está disponível para o XBAP chamador, incluindo:
Criando um identificador de janela (HWND) para a renderização
Envio de mensagens
Carregando a fonte Tahoma
Do ponto de vista da segurança, permitir o acesso direto a qualquer uma dessas operações a partir 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 área restrita. Enquanto todas as operações do WPF são verificadas em relação às permissões limitadas de segurança da zona da Internet do domínio do 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 governados pelo conjunto de permissões da 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 restringidas 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 do Assert pode permitir que códigos mal-intencionados elevem privilégios. Consequentemente, é então importante apenas chamar Assert quando necessário e garantir que as restrições de sandbox permaneçam intactas. Por exemplo, o código em área restrita não tem permissão para abrir arquivos aleatórios, mas é permitido usar fontes. O WPF permite que aplicativos em área restrita usem a funcionalidade de fonte chamando Asserte 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 integrada ao Visual Studio (consulte de segurança e implantação do ClickOnce para obter informações detalhadas). Aplicativos WPF autônomos podem ser implantados usando ClickOnce, enquanto aplicativos hospedados no navegador devem ser implantados com ClickOnce.
Os aplicativos implantados usando o ClickOnce recebem uma camada de segurança adicional sobre o CAS (Code Access Security); essencialmente, os aplicativos implantados pelo ClickOnce solicitam as permissões de que precisam. Eles recebem apenas essas permissões se não excederem o conjunto de permissões para a zona a partir 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 inicialização, o número de recursos aos quais o aplicativo tem acesso é reduzido ao mínimo. Consequentemente, se a aplicação for sequestrada, o potencial de danos à máquina cliente é reduzido.
Security-Critical Metodologia
O código WPF que usa 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 controlo de segurança. Para facilitar esse requisito, o .NET Framework fornece novo suporte para gerenciar código que eleva o privilégio. Especificamente, o CLR permite identificar o código que eleva o privilégio e marcá-lo com o SecurityCriticalAttribute; Qualquer código não marcado com SecurityCriticalAttribute torna-se transparente usando esta metodologia. Por outro lado, o código gerenciado que não está marcado com SecurityCriticalAttribute é impedido de elevar o privilégio.
Advertência
Os XBAPs requerem navegadores herdados para funcionar, como o Internet Explorer e versões antigas do Firefox. Esses navegadores mais antigos geralmente não são suportados no Windows 10 e no 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 freqüentes sobre aplicativos hospedados no navegador WPF (XBAP).
A Metodologia Security-Critical permite a organização do código WPF que eleva privilégio no kernelcrítico 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 (Global Assembly Cache) do usuário. Marcar um assembly com APTCA é uma operação de segurança altamente sensível, pois permite que qualquer código chame esse assembly, incluindo código malicioso 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 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 impulso dessas características tenta permitir aos utilizadores um maior controlo sobre a sua experiência de navegação.
Advertência
Os XBAPs requerem navegadores herdados para funcionar, como o Internet Explorer e versões antigas do Firefox. Esses navegadores mais antigos geralmente não são suportados no Windows 10 e no 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 freqüentes sobre aplicativos hospedados no navegador 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 tentam enganar os usuários falsificando a interface do usuário (UI) de 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 erradas que resultaram com a instalação de aplicativos spyware.
O IE6 SP2 inclui vários recursos para mitigar esses tipos de problemas, que giram em torno do conceito de iniciação do usuário. O IE6 SP2 deteta quando um usuário clicou em um link ou elemento de página antes de uma ação, que é conhecida como de iniciação do usuário, e a trata de forma diferente do que quando uma ação semelhante é acionada pelo script em uma página. Por exemplo, o IE6 SP2 incorpora um Bloqueador Pop-Up que deteta quando um utilizador clica num 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. Os pop-ups bloqueados são retidos na nova Barra de Informações , que permite ao utilizador substituir manualmente o bloqueio e visualizar o pop-up.
A mesma lógica de inicialização do utilizador é também aplicada 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. Estas medidas combinam-se para dar aos utilizadores uma experiência de utilizador mais segura e controlada, uma vez que estão protegidos contra sites que os assediam para instalar software indesejado ou malicioso.
Esses recursos também protegem os clientes que usam o IE6 SP2 para navegar em sites que lhes 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á-lo, incluindo o WPF. WPF adiciona a essas proteções usando 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 da 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 amplia os recursos de segurança do IE6 SP2 como parte de um compromisso contínuo com a segurança.
Ver também
.NET Desktop feedback