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 XAML browser applications (XBAPs) or loose Extensible Application Markup Language (XAML) (see Windows Presentation Foundation Browser-Hosted Applications Overview).

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.

This topic contains the following sections.

• 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
• Related Topics

Safe Navigation

For XBAPs, WPF distinguishes two types of navigation scopes: application and browser.

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:

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
  

Note:
For more information on application data files and pack URIs, see Windows Presentation Foundation Application Data Files.

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 3.0-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.

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

• 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 3.0 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 3.0-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.

Note:
Of these settings, XBAPDisallow and WebBrowserDisallow work for all versions of Internet Explorer.

Disabling APTCA Assemblies for Partially Trusted Client Applications

When managed assemblies are installed into the global assembly cache (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:

• Value Name: APTCA_FLAG.

• Value Type: REG_DWORD.

• Value Data: 1 to disable; 0 to enable.

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.

Note:
Core .NET Framework 3.0 assemblies are not affected by the disabling them in this way, since they are required for managed applications to run. Support for disabling APTCA assemblies is primarily targeted to third party and non-.NET Framework 3.0.

Sandboxing External Loose XAML

Loose XAML files are markup-only .xaml files that cannot be identified by a pack URI (see Pack URIs in Windows Presentation Foundation). This means that they are not resource, content, or site of origin files (see Windows Presentation Foundation Application Data Files).

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 by setting their SandboxExternalContent property appropriately, like so:

[xaml]

<!-- Sandboxing external content using Frame -->
<Frame 
    NavigateUri="ExternalContentPage.xaml" 
    SandboxExternalContent="True">
</Frame>
<!-- Sandboxing external content using NavigationWindow-->
<NavigationWindow
    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:

• Managed code: see Patterns and Practices Security Guidance for Applications.

• CAS: see Securing Applications.

• ClickOnce: see ClickOnce Deployment Overview.

• WPF: see Windows Presentation Foundation Partial Trust Security.

See Also

Concepts

Windows Presentation Foundation Partial Trust Security
Windows Presentation Foundation Security Strategy - Platform Security
Windows Presentation Foundation Security Strategy - Security Engineering
XAML Overview

Other Resources

Patterns and Practices Security Guidance for Applications
Securing Applications
ClickOnce Deployment Overview