Security

Microsoft Silverlight will reach end of support after October 2021. Learn more.

Security is incorporated into the design of Silverlight. By default, Silverlight applications are hosted in a browser and run in an environment that restricts access to the user's computer. Despite the restricted execution environment, there are some security considerations when you build Silverlight applications. In addition, Silverlight 4 and later applications can be configured to run in elevated trust, which also has security implications.

This topic describes how Silverlight is made secure through its restricted run environment and provides security guidance for building Silverlight applications in different scenarios. In addition, you will find many links to more information.

Note:
This topic does not discuss how to deploy Silverlight applications and secure your Web sites. For information about deployment, see the Silverlight Deployment Guide, Group Policy Settings, and the Security Guidance for Writing and Deploying Silverlight Applications whitepaper.

This topic contains the following sections:

• Understanding Security in Silverlight

• Hosting Silverlight Applications

• Avoiding Cross-Site Scripting Attacks

• Isolating Your Silverlight Application

• Accessing Network Resources in Secure Ways

• Protecting User Data

• Protecting Your XAP File

• Processing XAML and XML in Secure Ways

• Related Topics

Understanding Security in Silverlight

Silverlight is developed by using the Microsoft Security Development Lifecycle (SDL), which includes processes for designing, implementing, and testing for security. Silverlight applications typically operate within a partial-trust security boundary that is sometimes called a sandbox. Because most Silverlight applications run in a sandbox, they cannot access the file system and other system resources in the same way as traditional .NET applications. These actions can still be performed, but they typically must be initiated by the user.

Security Terms

To understand security in Silverlight, it is important to understand the security terms. The following table lists common security terms and their definitions.

Term	Definition
sandbox	Refers to a limited-privilege application execution environment.
partial trust	Describes an application execution environment with limited privileges.
trusted	Describes an application execution environment with elevated security privileges, such as increased access to the file system.
full trust	Refers to an application execution environment with full access to the user's computer.

Security Features

Silverlight enforces the partial-trust environment in several ways. The following table lists features in Silverlight and how they help create more secure applications. Some of these security restraints are relaxed for trusted applications. For more information, see Trusted Applications.

Application Feature	Sandbox Restrictions
File system access	File system access is limited and most dialog boxes must be user-initiated. For more information, see Dialog Boxes Overview.
Isolated local storage	Local storage is isolated from the rest of the file system. Storage is limited to 1 MB unless the user increases it. User may clear isolated storage cache. For more information, see Isolated Storage.
Full-screen mode	Full-screen mode must be user-initiated and displays a message about how to exit. When the user presses the ESC key or switches to another window, the application automatically exits full-screen mode. For more information, see Full-Screen Support.
Webcam and microphone support	Use of a webcam or microphone must be user-initiated. The user must grant permission in the security prompt. For more information, see Webcam and Device Overview. Silverlight 4 and later.
Printing	The Print dialog box must be user-initiated. For more information, see Printing. Silverlight 4 and later.
Clipboard access	Clipboard access must be user-initiated. The user must grant permission in the security prompt. Permission ends when the current page is closed or the user navigates away. For more information, see Clipboard. Silverlight 4 and later.
Right-click, context menu support	By default, Silverlight provides a right-click context menu that includes an option to access the Microsoft Silverlight Configuration Dialog Box. The configuration dialog box is also available on the Start menu in case an application provides its own right-click support.
Reflection and Reflection Emit	Reflection and reflection emit are restricted per partial-trust requirements. For more information, see Security Considerations for Reflection and Security Issues in Reflection Emit.
Network resource access	Network resource access is restricted. Only some network protocols can be used and access is restricted by a security policy. For more information, see Accessing Network Resources in Secure Ways.

For more information about how the security sandbox is constructed, see Silverlight Application Security Model.

Hosting Silverlight Applications

Typically, Silverlight applications are hosted in a Web browser. You create the Silverlight object as part of the Web page and set the Source property for the object to a XAP file, which is a zip file that contains Silverlight content. When the Silverlight application runs, it runs in a different security context than the rest of the HTML page that hosts the Silverlight plug-in.

You can configure Silverlight applications to run outside the browser and you can configure out-of-browser applications to bypass some of the restrictions imposed by the security sandbox.

The following table lists the Silverlight hosting environments.

Hosting Environment	Description
Web Browser, partial trust	The Silverlight application runs as part of a Web page, and has limited access to the host computer.
Out-of-Browser, partial trust	The Silverlight application is installed on the user's computer, but with the same security context as an in-browser Silverlight application.
Out-of-Browser, elevated trust	The Silverlight application is installed with increased access to the user's computer. Silverlight 4 and later. Note: In Silverlight 4 and later, you can configure a Silverlight application to run with elevated trust. A trusted application has fewer restrictions on user-initiation and more access to the user's computer. This is of particular concern when your Silverlight application also makes calls to Web services. You should carefully consider whether a trusted application is necessary before creating an application of this type. In addition, you should take additional security steps, such as digitally signing your application. For more information about trusted applications and the security considerations, see Trusted Applications.

Avoiding Cross-Site Scripting Attacks

Cross-site scripting (XSS) describes a vulnerability typically found in Web applications. If steps are not taken to prevent this type of vulnerability, an attacker can inject code (typically JavaScript) into Web pages hosted on different domains. For more information about XSS and other kinds of client vulnerabilities, see Client-side Cross-domain Security. For Silverlight, XSS issues are possible, but less likely than in traditional HTML development. However, an exploited cross-site scripting vulnerability can give the attacker access to any cookies, isolated storage, and authentication data that the browser would normally only give to a legitimate client.

In Silverlight, XSS issues typically occur when attacker-controlled strings are inserted into markup without first validating or escaping the attacker-controlled string.

The following is a list of scenarios when you need to be careful of exposing an XSS vulnerability. Many of the mitigations listed are called out in other sections of this document. However, it is important that you also understand these vulnerabilities in the context of XSS issues.

• Loading untrusted XAML with the XamlReader.Load method. You should never load a string or partial string from an unknown user. For more information, see Using XamlReader.Load.

• Setting the Xaml property on the RichTextBox control to an attacker-provided string.

• Loading an untrusted assembly with the Assembly.Load method.

• Creating XML by combining strings. For example, you might do this to create XML to send to a REST service. Use the XmlWriter and XElement classes to create more secure XML. For more information, see Security Considerations (XML Data in Silverlight).

• Using Silverlight to create HTML with the classes provided by the System.Windows.Browser namespace, or allowing untrusted access from the Silverlight plug-in to the hosting page. For more information, see the Settings.EnableHTMLAccess property.

• Using Silverlight to display attacker-provided HTML with the WebBrowser.NavigateToString method. You can do this only, in an out-of-browser application. Silverlight 4 and later.

• Hosting an attacker’s XAP file from your Web server, perhaps by allowing user uploads.

Isolating Your Silverlight Application

Typically, the more isolated you can make your Silverlight application, the more secure it will be. Many of the security decisions that you make are about how your Silverlight applications interact with other applications and resources. You must decide whether you will allow communication between its hosting environment, other code, and other Silverlight applications. Each of these choices has security implications, such as whether your Silverlight application will be vulnerable to cross-site scripting and other attacks. The following sections describe different ways to isolate your application.

Isolating from the Host HTML page

Silverlight applications are part of an HTML page. For security purposes, there are times when you do not want to allow communication from the hosting HTML page to the Silverlight application. You can control whether your Silverlight application can make calls to the HTML page and receive calls from the hosting HTML page with a feature called HTML Bridge. For information about how to manage these security settings, see Security Settings in HTML Bridge.

Isolating from Other Code

Any assembly that your Silverlight application loads can be potentially malicious, so you should make sure that your application only loads assemblies that it trusts. You can increase your trust of assemblies by requiring that they be signed with SignTool.exe.

Isolating from Other Silverlight Applications

In addition to the communication between Silverlight applications through the host HTML page, you can configure your Silverlight application to communicate with other Silverlight applications by using a feature called local messaging. By default, Silverlight limits local messaging to senders and receivers on the same domain, and you should be careful about extending this behavior to communication from other domains. For more information about local messaging, see Communication Between Local Silverlight-Based Applications.

Accessing Network Resources in Secure Ways

In Silverlight, you can access network resources using HTTP, HTTPS, and sockets.

Accessing Resources with HTTP

Silverlight supports both HTTP and HTTPS for loading XAP files and calls to Web services. Silverlight supports same-domain calls by default and cross-domain calls if the service provider opts in to them with a cross-domain policy file. Same domain means that calls must use the same sub domain, protocol, and port.

The following illustration shows examples of calls that are considered to be cross-domain and therefore not allowed in a Silverlight application that uses the default settings.

Cross-domain examples

If you deploy a Silverlight application and a Web service that the Silverlight application depends on, you must make sure that your Web service is secure so that it does not also jeopardize the Silverlight application. For information about how to mitigate attacks on a deployed Web service, see Security Guidance for Writing and Deploying Silverlight Applications.

In addition, Silverlight offers two options for HTTP processing; HTTP processing done by the browser and HTTP processing done by the Silverlight client. The browser and client HTTP processing are slightly different in the way they handle cookies and headers, and also different in what verbs that can be used. For example, a client HTTP Web request always sends a Referer header, but a browser HTTP Web request may or may not send this header depending on the hosting browser. The Referer header helps a server determine the domain of a Silverlight application.

For more information about the different types of HTTP processing and HTTP security restrictions and considerations, including the cross-domain policy file, see the following topics.

Title	Description
HTTP Communication and Security with Silverlight	Describes HTTP processing options and communication scenarios and how you can enable these scenarios. Includes security guidance.
Network Security Access Restrictions in Silverlight	Describes how to use the security policy system in Silverlight and describes the policy file formats that are supported.
URL Access Restrictions in Silverlight	Describes how the Silverlight runtime restricts access to certain classes of URLs.
Making a Service Available Across Domain Boundaries	Describes the cross-domain policy file that Silverlight supports to opt-in to cross-domain access.
Security Considerations for Service Access	Describes security considerations when using Silverlight with Web services.

Accessing Resources with Sockets

Silverlight offers support for sockets communication. For information about security considerations and restrictions when communicating with sockets, see the following topics.

Title	Description
Working with Sockets	Describes the managed implementation of the sockets networking interface.
Network Security Access Restrictions in Silverlight	Describes sockets and the security policy system in Silverlight.
Working with Multicast	Describes how to create Silverlight multicast clients in a secure way.

Protecting User Data

Isolated storage is one mechanism for storing data for users. Data in isolated storage can be accessed by a computer's administrator and by any application in the same domain. This means when you store sensitive data in isolated storage, you should consider encrypting it. For general information about isolated storage and encryption, see Isolated Storage. For an example of how to encrypt an isolated storage file, see the AesManaged class. For an example of how to sign an isolated storage file, see the HMACSHA256 class. For more information about how to encrypt data, see Cryptographic Services in Silverlight.

Protecting Your XAP File

You should take steps to make sure that your XAP file is not hosted in another unauthorized HTML page. You can do this by checking the host page URL when your XAP file starts with the HtmlDocument.DocumentUri property if EnableHTMLAccess is true.

In addition, you should never store sensitive data, such as passwords and other proprietary information, in a XAP file. It is possible that malicious users can retrieve this information from a XAP file, even if you have obfuscated it.

Processing XAML and XML in Secure Ways

Because Silverlight is typically hosted in an HTML page, you should be aware of cross-site scripting (XSS) and other vulnerabilities in your application.

As mentioned previously, one of the ways you can avoid XSS issues in your Silverlight application is to never load untrusted XAML. The RichTextBox.Xaml property or the XamlReader.Load method enable you to load XAML. For more information about loading XAML and the security considerations, see Using XamlReader.Load.

Improper handling of XML files can lead to Denial of Service (DoS) and other attacks. For more information, see Security Considerations (XML Data in Silverlight).

If your application is a trusted application, you should take steps to verify that the XAML (in the XAP file) you are loading is from the source you expect. You can do this by checking the Host property of your application.

Related Topics

Topic	Description
Silverlight Application Security Model	Describes the code security model for Silverlight.
Cryptographic Services in Silverlight	Describes and contains links to the Silverlight cryptographic services.
Out-of-Browser Support	Describes out-of-browser applications.
Trusted Applications	Describes trusted applications and security concerns when you create them.
Silverlight 4 Security Overview	Describes aspects of Silverlight application security.
Security Guidance for Writing and Deploying Silverlight Applications	Provides security help for creating and deploying Silverlight applications.