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 Resource, Content, and 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

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.

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.

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

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

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 Resource, Content, and 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. 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="http://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.

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 Code Access Security.

• ClickOnce: see ClickOnce Deployment Overview.

• WPF: see Windows Presentation Foundation Partial Trust Security.

Concepts

Other Resources