Share via


Windows Presentation Foundation Security

This topic discusses the security model for Windows Presentation Foundation (WPF) standalone and browser-hosted applications.

WPF standalone applications execute with unrestricted permissions (CAS FullTrust permission set), whether deployed using Windows Installer (.msi), DOS XCopy, or ClickOnce.

WPF browser-hosted applications are hosted by Windows Internet Explorer, and can be either aplicativos de navegador XAML (XBAPs) or loose Extensible Application Markup Language (XAML) (see Visão geral sobre Windows Presentation Foundation XAML Browser Applications).

WPF browser-hosted applications execute within a partial trust security sandbox, by default, which is limited to the default CAS Internet permission set. This effectively isolates WPF browser-hosted applications from the client machine in the same way that you would expect typical web applications to be isolated. Partial trust security is described in more detail in Windows Presentation Foundation Partial Trust Security.

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

  • Safe Navigation
  • Internet Explorer Security Settings
  • Disabling APTCA Assemblies for Partially Trusted Client Applications
  • Sandboxing External Loose XAML
  • Best Practices for Developing Secure WPF Applications
  • Tópicos relacionados

Safe Navigation

For XBAPs, WPF distingue dois tipos de escopos de navegação: aplicativo e navegador.

Application navigation is navigation between items of content within an application that is hosted by a browser, while browser navigation is navigation that changes the content of a browser itself. The relationship between application-scope and browser-scope navigation is shown in the following figure:

Diagrama de navegação

The type of content that is considered safe for an XBAP to navigate to is primarily determined by whether an application or browser navigation occurs.

Application Navigation Security

Application-Scope navigation is considered safe if it can be identified with a pack URI, which supports four types of content:

  • Resource files, which are files that are added to a project with a build type of Resource, and can be identified with a URI like the following:

    pack://application:,,,/MyResourceFile.xaml

  • Content files, which are files that are added to a project with a build type of Content, and can be identified with a URI like the following:

    pack://application:,,,/MyContentFile.xaml

  • Site of Origin files, which are files that are added to a project with a build type of None, and can be identified with a URI like the following:

    pack://siteoforigin:,,,/MySiteOfOriginFile.xaml

  • Application Code files, which are files that are added to a project with a build type of Page, and can be identified with a URI like the following:

    pack://application:,,,/MyResourceFile.xaml

ObservaçãoObservação:

Para obter mais informações sobre arquivos de dados do aplicativo e empacotar URIs, consulte Arquivos de Recurso, Conteúdo e Dados de Aplicações Windows Presentation Foundation.

Files of these content types can be browsed to as a result of either a user navigation or a programmatic navigation:

  • User Navigation. The user caused the navigation by clicking a Hyperlink element.

  • Programmatic Navigation. The application caused the navigation without involving the user.

Browser Navigation Security

Browser navigation is considered safe only in under the following conditions:

  • User Navigation. The user caused the navigation by clicking a Hyperlink element.

  • Zone. The content being navigated to is located on the Internet or the local intranet.

  • Protocol. The protocol being used to is either http:, https:, file:, or mailto:.

If an XBAP attempts to navigate to content in a manner that does not comply with these conditions, a SecurityException is raised.

Internet Explorer Security Settings

Internet Explorer provides a mechanism by which you can configure the functionality that is allowed to be executed by or from Internet Explorer, including the following:

  • .NET Framework-reliant components

  • ActiveX controls and plug-ins

  • Downloads

  • Scripting

  • User Authentication

Whether a piece of functionality can run, and how it runs, is determined by a security setting. You can configure the security setting to either enable a disable a piece of functionality entirely, or to prompt the user to decide each time a piece of functionality attempts to run.

The collection of functionality that can be secured in this way is configured on a per-zone basis for the Internet, Intranet, Trusted Sites, and Untrusted Sites zones. You can configure the security settings by:

  1. Opening Internet Explorer.

  2. From the Tools menu, click Options | Security.

  3. Select the zone to configure the security settings for.

  4. Click the Custom Level button

This opens the Security Settings dialog box to configure the security settings for the selected zone.

Caixa de diálogo Configurações de Segurança

Windows Internet Explorer 7 includes the following four security settings specifically for .NET Framework:

  • Loose XAML. Controls whether Internet Explorer 7 can navigate to and loose XAML files. (Enable, Disable, and Prompt options).

  • XAML browser applications. Controls whether Internet Explorer 7 can navigate to and run XBAPs. (Enable, Disable, and Prompt options).

  • XPS documents. Controls whether Internet Explorer 7 can navigate to and load XML Paper Specification (XPS) documents. (Enable, Disable, and Prompt options).

  • Enable .NET Framework setup. Controls whether the .NET Framework can be installed via Internet Explorer 7. (Enable or Disable options only).

  • By default, these settings are all enabled for the Internet, Local intranet, and Trusted sites zones, and disabled for the Untrusted sites zone.

Security Settings for IE6 and Below

For versions of Internet Explorer other than Internet Explorer, security settings for various .NET Framework-related security settings can be configured from the Registry, under the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Windows Presentation Foundation\Features

The following table lists the values that can be set.

Value Name

Value Type

Value Data

XBAPDisallow

REG_DWORD

1 to disallow; 0 to allow.

LooseXamlDisallow

REG_DWORD

1 to disallow; 0 to allow.

WebBrowserDisallow

REG_DWORD

1 to disallow; 0 to allow.

XPSDocumentsDisallow

REG_DWORD

1 to disallow; 0 to allow.

MediaAudioDisallow

REG_DWORD

1 to disallow; 0 to allow.

MediaImageDisallow

REG_DWORD

1 to disallow; 0 to allow.

MediaVideoDisallow

REG_DWORD

1 to disallow; 0 to allow.

ObservaçãoObservação:

Essas configurações, XBAPDisallow and WebBrowserDisallow trabalho todas as versões de Internet Explorer.

Disabling APTCA Assemblies for Partially Trusted Client Applications

When managed assemblies are installed into the cache de assembly global (GAC), they become fully trusted because the user must provide explicit permission to install them. Because they are fully trusted, only fully trusted managed client applications can use them. To allow partially trusted applications to use them, they must be marked with the AllowPartiallyTrustedCallersAttribute (APTCA). Only assemblies that have been tested to be safe for execution in partial trust should be marked with this attribute.

However, it is possible for an APTCA assembly to exhibit a security flaw after being installed into the GAC. Once a security flaw is discovered, assembly publishers can produce a patch to fix the problem on existing installations, and two protect against installations that may occur after the problem is discovered. One option for the patch is to uninstall the assembly, although that may break other fully trusted client applications that use the assembly.

WPF provides a mechanism by which an APTCA assembly can be disabled for partially trusted WPF applications, including XBAPs, without uninstalling the APTCA assembly.

To disable an APTCA assembly, you need to create a special key under the following Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\APTCA\<AssemblyFullName>, FileVersion=<AssemblyFileVersion>

The following shows an example key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\APTCA\aptcagac, Version=1.0.0.0, Culture=neutral, PublicKeyToken=215e3ac809a0fea7, FileVersion=1.0.0.0

This establishes an entry for the APTCA assembly, although you also need to create a value underneath this key that enables/disables the assembly. The following are the details of the value you need to create:

  • Nome do valor: APTCA_FLAG.

  • Tipo de valor: REG_DWORD.

  • Dados do valor: 1 desabilitar; 0 para ativar.

Publishers of an assembly that needs to be disabled for partially trusted client applications in this way can write a patch to create Registry key and value entries for the assembly.

ObservaçãoObservação:

Principais .NET Framework módulos (assemblies) não é afetados pela desabilitá-los dessa forma, pois são necessários para a execução de aplicativos gerenciado. Support for disabling APTCA assemblies is primarily targeted to third party and non-.NET Framework.

Sandboxing External Loose XAML

Loose XAML files are markup-only .xaml files that cannot be identified by a pack URI (see URIs de Pacotes no Windows Presentation Foundation). This means that they are not resource, content, or site of origin files (see Arquivos de Recurso, Conteúdo e Dados de Aplicações Windows Presentation Foundation).

When loose XAML files are navigated to directly from Internet Explorer, they are security sandboxed by the default Internet zone permission set.

However, the security behavior is different when loose XAML files are navigated to from either a NavigationWindow or Frame in a standalone application.

In both cases, the loose XAML file that is navigated to inherits the permissions of its host application. However, this behavior may be undesirable from a security perspective, particularly if a loose XAML file was produced by an entity that is either not trusted or unknown. This type of content is known as external content, and both Frame and NavigationWindow can be configured to isolate it when navigated to. Isolation is achieved by setting the SandboxExternalContent property to true, as shown in the following examples for Frame and NavigationWindow:

<Frame 
  Source="ExternalContentPage.xaml" 
  SandboxExternalContent="True">
</Frame>
<!-- Sandboxing external content using NavigationWindow-->
<NavigationWindow 
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation" 
  Source="ExternalContentPage.xaml" 
  SandboxExternalContent="True">
</NavigationWindow>

With this setting, external content will be loaded into a process that is separate from the process that is hosting the application. This process is restricted to the default Internet zone permission set, effectively isolating it from the hosting application and the client machine.

Best Practices for Developing Secure WPF Applications

Building applications for WPF that are secure requires applying best practices for the following:

Consulte também

Conceitos

Windows Presentation Foundation Partial Trust Security

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

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

Visão geral sobre a implantação do ClickOnce

XAML Overview

Outros recursos

Patterns and Practices Security Guidance for Applications

Segurança de Acesso de código