Windows Presentation Foundation Security Sandbox


Mark Alcazar
Windows Presentation Foundation Platform
Microsoft Corporation

September 2005

Summary: Gives an overview of the technologies used to create the WBA security sandbox, summarizes the sandbox feature set, and provides a rationale for the tradeoffs made during development. (10 printed pages)

Applies to:
   WinFX Runtime Components September CTP (PDC 2005 Build)
   Windows Presentation Foundation (WPF)
   Web Browser Applications (WBAs)


Feature Decisions


Windows Presentation Foundation (WPF), part of the WinFX platform, introduces a new application type: Web Browser Applications (WBAs). Web Browser Applications are online-only applications that run in the browser and are not installed. These applications execute in a security sandbox and harness the power of the WPF platform on the Web.

This document gives an overview of the technologies used to create the WBA security sandbox, summarizes the sandbox feature set, and provides a rationale for the tradeoffs made during development. It is intended to:

  • Explain the types of operations possible within Web Browser Applications.
  • Enable experienced developers to understand the design of the security sandbox.
  • Help developers understand what is disallowed in the sandbox "by design" and what might be a bug for which they can provide feedback to Microsoft.

Note   This document assumes a familiarity with the WinFX runtime as well as Web Browser Applications (WBAs).

For a general overview of these concepts, see Windows Presentation Foundation on the Web: Web Browser Applications.


Sandboxing is a generic security term that applies to any environment that reduces the privileges under which an application runs. It is particularly important to sandbox applications downloaded from the Internet, as they tend to come from unknown or untrusted sources. This section gives an overview of the Windows Presentation Foundation sandbox created for Web Browser Applications.

Code Access Security

The WPF sandbox is built using Code Access Security (CAS), a base technology of .NET Framework security. This security model uses a combination of permission sets and deployment zones to determine an application's privileges. Please see the MSDN Code Access Security topic for more information on CAS.

Demanding permissions

A key concept of Code Access Security is that code can require a certain level of privilege. At a high level, when code wants to do a privilege check, it explicitly demands the required permission. Take for example an API that performs disk access. The code that creates a file will call FileIOPermission.Demand(). This demand will trigger the .NET runtime to perform a stack walk to determine if any of the callers have the required permission.

There are many intricacies of CAS stackwalks. For more information, please see the Code Access Security MSDN article.

Security exceptions

If code does not have the required permission, the demand fails and the .NET Framework runtime throws a SecurityException. A developer creating a Web Browser Application attempting to use functionality not available in the sandbox will therefore encounter SecurityExceptions during development.

Sandbox and Partial-Trust

Sandboxing is a generic security term referring to a limited-privilege application execution environment. Partial trust refers to a security sandbox based on Code Access Security. All WBAs and Extensible Application Markup Language (XAML) files deployed from the Internet are running in partial trust.

Throughout this paper the term partial trust will be synonymous with "the sandbox applied to WBAs deployed from the Internet." Because CAS is a zone-based security framework, it is possible for intranet applications to request a larger sandbox than the one available to Internet applications. However, this article will focus exclusively on features running within the Internet sandbox since it is a more restrictive environment and maps to a large number of scenarios.

Internet Permission Set

This section is intended to give only an overview of the types of operations that by default may be performed by an Internet-sandboxed application. For more details on the actual permissions listed below consult System.Security.Permissions Namespace.

Default permissions available in the Internet Zone.

FileDialogPermission.Open Allows use of the standard File Open dialog in a safe manner.
IsolatedStorageFilePermission Allows writing up to 512K of state to a safe location on disk.
UIPermission.SafeTopLevelWindows Allows access to a single browser window. Does not allow the opening of additional WPF windows.
PrintingPermission.Safeprinting Allows printing in a safe, user-prompted manner.
WebPermission Allows network access to the site of origin of the application.
WebBrowserPermission Allows WPF Frame elements to navigate to content containing HTML (or other WBAs) in a safe and secure way. (In Beta 2 of WinFX this permission will be added to the Internet Zone only when WPF has been installed on the machine.)
MediaPermission Allows WPF Image, Audio, and Video elements to host content in a safe and secure way. (In Beta 2 of WinFX this permission is added to the Internet Zone only when WPF has been installed on the machine.)

Examples of permissions not available in the Internet zone

FileIOPermission This permission controls the ability to read and write files on disk. Consequently, applications in the Internet zone cannot read files on the user's hard disk.
RegistryPermission This permission controls the ability to read/write to the registry. Consequently, applications in the Internet zone cannot access or control state in the user's registry.
SecurityPermission.UnmanagedCode This permission controls the ability to call native Win32 functions.

General philosophy

Enabling any operation involves analyzing the implementation to ensure it poses no security risk to the end user. As a general guideline, the WPF team considers enabling a scenario in the sandbox only if the equivalent scenario is also enabled in an existing Web platform. To enable any new scenarios not available on other Web platforms requires extensive additional analysis to prove that no additional security risk is introduced to the end user. For example:

  • Images are allowed to host content from non-site-of-origin Web sites, as other Web platforms (HTML) allow this functionality.
  • A new feature like 3-D is enabled in partial-trust, as it's been proven to not constitute a security risk (given that all graphics operations are constrained by the browser's window).

Feature Set Available in Partial Trust

Only a subset of the features of the WPF platform is enabled in partial-trust. This is a result of a rigorous process that determines the appropriateness of a feature for partial-trust. The WPF feature set can be categorized into four sections:

  1. Features enabled in partial-trust (for example, Button).
  2. Features enabled in partial-trust, with some change in behavior to make them safe (for example, Pop-up control).
  3. "By design" not available in partial-trust (for example, the Window.DragMove method, or methods that facilitate interop with unmanaged code).
  4. Not currently enabled in partial-trust, but may be enabled in a future release.

Features that "by design" are not enabled in partial trust will have an explicit demand for a specific permission. For example, calling the DragMove method on a Window will result in a demand for UIPermission.AllWindows. This behavior should also be reflected in the documentation.

Features that are not currently enabled but may be enabled at a later date will typically throw a security exception. The current documentation will likely not state that the API is not available in partial-trust, or that specific privileges are required.

Windows Presentation Foundation is still under active development. If you're seeing a demand for functionality you think should work in partial-trust, it may be a bug. Contacting Microsoft (e-mail is the best way to give feedback to the development team.

Features that are enabled in partial-trust

  • Browser window
  • Site of origin access
  • Isolated Storage File IO
  • File Open dialog
  • UIAutomation providers
  • Cicero IMEs
  • Commanding
  • Tablet stylus/ink

Web Integration

  • IE Download Dialog
  • Top Level User Initiated Navigation
  • HTML hosted in Frame or NavigationWindow.
  • mailto: links
  • URI (cmd line) Arguments
  • ASMX Web Services
  • WBAs hosted in HTML IFrame

XPS Documents

  • XPS Document Viewer

  • 2-D
  • 3-D
  • Animations


(and cross-domain rendering)

  • Image
  • Audio
  • Video

Flow Documents

  • Pagination
  • Text flow
  • Optimal paragraph
  • Hyphenation


  • Embedded and system fonts
  • Adobe CFF
  • Glyphs

  • Text Box
  • Rich Text Box
  • Plaintext and Ink clipboard
    • Programmatic cut/copy
    • User-initiated paste (for example, CTRL+V)


  • Buttons
  • Sliders
  • Scroll Viewers
  • Pop-up controls (bound to window limits)
  • Pop-up-based controls (for example, Menu)
  • Basic controls

Features that are "by design" not enabled in version 1

  • Standalone windows
  • Launching of new windows
  • App-defined dialogs
  • App-launched Save Dialog
  • UIAutomation clients

Web Integration

  • Windows Communication Foundation Web services

General Integration

  • HwndHost
  • Full speech support

  • Bitmap effects


  • Rich (RTF, XAML) clipboard
  • Spell checking

Feature Decisions

This section provides additional details about the decisions made to enable various features in partial-trust.

Windows, Spoofing, and Phishing

UI spoofing and phishing refers to a class of security exploits where the UI of a trusted application is mimicked from an application with less trust. For example, being able to create a window that convincingly looks like a Windows logon UI is a form of UI spoofing. Internet Explorer provided by Windows XP SP2 introduces several mitigations to address spoofing vulnerabilities in HTML. This section describes the model that Web Browser Applications follow to prevent spoofing vulnerabilities.

Browser's window

By default, a Web Browser Application ** displays its content in-place within the browser's main window. Spoofing vulnerabilities are mitigated by the presence of the browser's standard trust UI (address-bar, status bar, window-icon, presence of browser chrome, and so on). Furthermore, only a limited subset of the programming model available on standard WPF windows is available in the browser (for example, attempting to change the icon of the browser's window would throw an InvalidOperationException).


In the Internet sandbox, Web Browser Applications are not allowed to create WPF windows. An attempt to create either a Window (or an equivalent class like HwndSource) will demand UIPermission.AllWindows. This addresses the risk of spoofing exploits described above but creates a constraint on the types of applications that can be developed. A future release of WPF may address this limitation; some potential workarounds are discussed below.

The pop-up control (and its subclasses) can be instantiated in the Internet zone. Spoofing concerns are mitigated, as a partial-trust pop-up control is always constrained to be within the content region of the browser window.

The MessageBox class is enabled in partial-trust. This is possible as the UI that the MessageBox creates is constrained so that it's not possible to realistically spoof a system dialog and to take user input.

If your application needs to display a dialog or secondary window, there are several workarounds you can consider:

  • Many applications on the Internet (for example, e-commerce-based sites) don't use dialogs. Instead a Web-like model is used to display status/error messages "in-place" on the page. You should consider whether an "in-place" UI model would be appropriate for your application.
  • Applications that need to display status messages can use the pop-up control.
  • Applications can use the System.Windows.MessageBox class to display status/warnings.
  • Applications that need to display dialogs or secondary windows can use the System.Windows.Forms.Form class. This has some constraints, namely:
    • The window displays a trust balloon indicating that the content came from the Internet.
    • Only System.Windows.Forms controls can be hosted in the dialog.
    • There is an additional working set cost of using System.Windows.Forms.

Graphics Operations

All graphics operations (including 3-D and animations) are constrained to the top-level browser window, and are enabled in partial-trust.

Images and decoders

Displaying an image using the image element is enabled in partial-trust. Images may be displayed using URIs that refer to resources embedded in the application, images on the site of origin of the application, or even images on other Web sites. However, you are not able to programmatically access the metadata from an image element when the URI refers to an image on another Web site (see the Network Section for more detail). A wide variety of image formats is supported by default in the WPF platform (.jpg, .gif, .tiff, .png, .bmp, and so on).

Image decoders are a known source of vulnerabilities in Web platforms. Consequently, although there is a general extensibility mechanism for extending the set of decoders/encoders available on the WPF platform, only codecs that have been signed are enabled in partial-trust. Microsoft recommends that an extremely rigorous testing and review process be used before any codec is enabled in partial-trust.

Information exposed about codecs by the BitmapCodecInfo class exposes information about installed codecs and constitute an information disclosure risk. Consequently, accessing the properties on this class is not possible in partial-trust.


Providing Web applications access to the Clipboard is a security/privacy concern. If Web applications can access the Clipboard, they can gain access to potentially sensitive data. At the same time, being able to cut and paste between applications is a fundamental operation that end-users expect to be able to perform. WPF strikes a balance between these conflicting requirements by allowing copy operations while also allowing only user-initiated paste operations.

More concretely, the Paste command may be invoked by a user through the key-binding associated with Paste (CTRL+V for English locale), or through the Edit menu in the browser. However, an attempt to programmatically invoke Paste (for example, through the DataObject class directly) will fail with a SecurityException. This model allows users to perform the operations they expect, while preventing malicious applications from being able to obtain the end-user's sensitive data.

Only a limited set of Clipboard formats is currently supported in partial trust (for example, CF_TEXT). Richer formats such as CF_XAML are currently not enabled in order to prevent elevation of privilege exploits between partially-trusted and fully-trusted applications. This limitation may be addressed in a future release of WPF. There have been many social engineering exploits employing the use of drag-and-drop. Consequently drag-and-drop operations are not enabled in partial-trust in the PDC 2005 release.

Navigation is an inherent part of Web applications. In partial trust, it is possible for applications to navigate to content in three locations:

  1. Bundled with the application as a resource or content file,
  2. Posted at the site-of-origin server, or
  3. Hosted at other sites.

Navigation to content from other sites requires a user action; the navigation must occur as the result of a hyperlink click.

The rationale for user-initiated cross-domain navigation is to provide a user experience consistent with some of the security measures introduced with Windows XP SP2. In Internet Explorer, the information bar is displayed across the top of the browser when attempting to programmatically navigate a Web page to an unsafe file type, such as an executable (.exe) file. For more details on this and other Windows XP SP2 security measures, see Windows XP Service Pack 2 Overview. Supporting only user-initiated navigations is a slightly more constrained approach to protecting the user from the risks associated with unsafe file types on cross-domain servers.

Navigating to http:, mailto:, and pack: protocols is supported in partial trust. However, not all the other protocols available to HTML Web pages (like javascript:, mks:, or res:) are available to .NET Framework applications. This is not strictly a security measure, as the .NET Framework does not at this time have native support for all protocols.

Sub-frame navigation to HTML

Navigating a frame to HTML content is possible in partial-trust. However, for the frame case, only content that came from the site of origin of the application is allowed. In the Beta 2 release of WPF, the ability to navigate frames to HTML content will be controlled by WebBrowserPermission.

Network Access

By default, the Internet zone only allows performing Web requests to the site of origin of an application. This follows the existing Web cross-domain security model, where a page on the Internet can only access the Document Object Model (DOM) of pages from the same domain. Beyond these constraints, the WPF platform allows images and video elements to display content from domains other than the site of origin. However, reading the raw decoded bits that came from the external site is not allowed—for example, calling the BitmapSource.CopyPixels method for an image that came from an external site and will result in a demand for WebPermission.

The rationale for this is that displaying images and video is considered a safe operation. However, accessing the raw data obtained from an external site would constitute a way to circumvent the default WebPermission, as the developer would be able to get data from an external site.


A post-PDC 2005 release of WPF is expected to enable the printing of WPF content in partial trust. The proposed model is that using printing within partial-trust will require user consent through a print dialog. Denial-of-service and information-disclosure attacks are prevented as any request to print will require explicit user consent.

Controls and Layout

All of the controls and layouts that are part of WPF are available in partial-trust (for example, DockPanel, Grid, Button and so on). As discussed in the Window section of this article, the System.Windows.Controls.Primitives.Popup class is always constrained to be clipped within the browser's window in partial trust. All elements that derive from the pop-up class (for example, Menu) will also exhibit this clipping behavior.


Methods/properties that exist to enable interop to unmanaged code are not enabled in partial-trust (for example WindowInteropHelper). The rationale here is that using these classes is not a scenario for partial trust.


Several of the security features already discussed (the Paste command, navigation) require a determination to detect whether the operation was initiated by a user. As a result, programmatically generating input events is considered a trusted operation. Any method that provides a hook that can be used to generate an input event is not available in partial trust and will demand UIPermisison.Unrestricted. For example, most of the properties, methods, and events surfaced on the InputManager class are not available in partial trust.

Miscellaneous Features

Image effects

Image effects are not enabled in partial-trust.

ActiveX controls

WPF does not currently support embedding ActiveX controls directly in XAML. Applications that wish to host ActiveX controls can do so by pointing a WPF frame to HTML content that hosts an ActiveX control. The same limitations that currently govern the use of ActiveX controls in HTML pages will apply.


Secure systems will have many layers of defense. Consider the example of a castle that has a moat, walls around the castle, a drawbridge, an inner wall and so forth. If one of the layers is breached, there are several other protective tiers to guard the citizens within.

The previous sections of this document have described security measures and design decisions governing the use of Code Access Security. Like the castle in our example, the WPF platform has been designed with several layers of defense. This section gives a high level description of those other defense-in-depth measures. For more details, see the Windows Presentation Foundation Security Whitepaper.

Process Security

Many users run with Administrator privileges on their machines, with the net result that any malicious code that runs on that machine has extensive privileges. The User Account Protection (UAP) feature in Windows Vista addresses this by reducing the set of privileges applications have even when run from accounts that belong to the Administrators group.

Although Windows Vista users will be protected with this new measure, the WinFX runtime is available on Windows XP SP2 and Windows Server 2003. To protect users on these earlier operating systems, all WBAs run in a process where the Administrator and Power-User tokens have been removed. Consequently, even if there is a failure in the CAS security mechanisms described in the previous sections, malicious code will not have Administrator access on the machine.

Critical and Transparent Assemblies

WPF makes use of a new .NET Framework feature: critical and transparent code. By making use of this feature, the most security-sensitive code in WPF assemblies is attributed with metadata. Static code analysis tools are then employed to spot dangerous patterns that need to be reviewed. (Furthermore, by clearly identifying the most security-sensitive code, the entire code base is easier to audit, security-wise.)

Turning Off and Controlling the Sandbox

Although Microsoft has gone to extreme efforts to secure the WPF platform, there are several scenarios where an administrator may want to limit the functionality of WPF on end-users' machines.

  • An administrator may want to limit functionality based on zone. For example, a corporation may want to disallow WBAs from running from the Internet on their users' machines, but allow intranet WBAs to run.
  • An administrator may want to control the set of permissions available in a zone (for example, make intranet apps have more permission, reduce privileges of Internet applications, and so on).
  • If a critical security vulnerability is discovered, switches give administrators the option of turning off functionality until a patch is made available.

WPF provides "big switches" to disable large sets of features (for example, disable WBAs, disable XPS documents), and "little switches" that can be used to configure more discrete features. "Big switches' map to Internet Control panel switches that can be changed by zone and "little switches" map to code access permissions.

Controlling through the Internet Control Panel

In Internet Explorer 7, several new security settings have been added to control WPF-specific features. (To customize the Internet Explorer security settings, click the Custom button on the Security tab of the Internet Control panel.) As with all security settings surfaced in the Internet Control panel, these WPF settings can be configured by zone. Users can choose to prompt as well as enable or disable WPF content. For example, an administrator could configure a machine so that Internet WBAs don't run and Internet XPS documents prompt the user before running.

The set of features that are configurable by switches are

  • XPS documents
  • Web Browser Applications (WBAs)
  • XAML pages

Administrators can make changes to the settings through several well-documented mechanisms#&151;for example, using the IEAK, or deploying changes through group policy.

Controlling through registry keys

Not every user of WPF will necessarily have Internet Explorer 7 installed. For these customers, registry keys are available that will always allow disabling of equivalent functionality.

Controlling through CAS policy

Code Access security can be configured through a command-line tool, Caspol. Caspol allows administrators to change the permissions granted to named permission sets (for example, changing the permissions available in the Internet zone). For more detail on how to administer security policy, please see Administering Security Policy.

As described in the Internet permission set section of this article, WPF introduces new default permissions that are added to the Internet zone. By configuring the WebBrowserPermission, or the MediaPermission, administrators have fine-grained control of these features that have a large surface area.


Creating an Internet-facing platform that provides sufficient utility and is secure by default is a difficult task. This paper has outlined some of the design decisions that have been made in the creation of the sandbox for Web Browser Applications. Developers should understand the types of applications that can be built using WBAs and understand their limitations. The WBA sandbox provides a useful utility to the developer, while ensuring that applications running inside the sandbox are secure by default.