Silverlight2 SecurityMicrosoft KoreaNext Web Team

Reagan Hwang / UX Evangelist

Application Code

Silverlight 2 Application Security Model

How Silverlight 2 processes application code

More Silverlight Application Security• All applications written for Silverlight are security transparent.  This

means that they cannot: [details] • Contain unverifiable code • Call native code directly

• Silverlight applications can access public methods exposed by platform assemblies which are either: [details] • Security transparent (neither the defining type nor the method has any

security attributes) • Security safe critical (the method has a SecuritySafeCriticalAttribute)

• Silverlight applications may contain types which derive from: [details] • Other types defined in the application • Unsealed, public, security transparent types and interfaces defined by the

platform• Silverlight applications may contain types which override

virtual methods and implements interface methods which are: [details] • Defined in the application itself • Defined by the platform and are transparent or safe critical

HTML Bridge

Security Settings in HTML Bridge• The EnableHtmlAccess parameter, which is set on the Silverlight plug-

in on the host page, prevents a malicious cross-domain Silverlight-based application from accessing the host page's JavaScript and DOM code.

• The ExternalCallersFromCrossDomain deployment manifest attribute prevents a malicious cross-domain host from accessing scriptable properties, methods, or events that are exposed by the Silverlight-based application.

• The AllowHtmlPopupwindow parameter, which is set on the Silverlight plug-in on the host page, controls pop-up windows that are opened by cross-domain Silverlight-based applications. When this attribute is set to false (the default when the Silverlight control is loaded from a different domain than the containing page or hosting iframe), a developer cannot call PopupWindow.

from Silverlight to JavaScript• The enableHtmlAccess parameter is set on the Silverlight plug-in. It enables managed

code in the .xap file to access the JavaScript and DOM code on the host page. This parameter can be set only during plug-in initialization, and is read-only afterward. For same-domain applications, the parameter is set to true by default, and you do not have to explicitly set its value in code. For cross-domain applications, the parameter is set to false by default, and you have to explicitly enable it, as shown in the following host page HTML code.

When the enableHtmlAccess parameter is set to true, as shown in the previous example, the following HtmlPage properties are enabled: •HtmlPage..::.Document •HtmlPage..::.Window •HtmlPage..::.Plugin •HtmlPage..::.BrowserInformation

<div id="silverlightControlHost"> <object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="300" height="100" <param name="source" value="http://www.northwindtraders.com/MySample.xap"/> <param name="enableHtmlAccess" value="true" /> // for cross-domain application </object></div>

enableHtmlAccess Workarounds• When the enableHtmlAccess parameter is set to false, direct access to JavaScript or

DOM elements and objects is not possible. However, individual, specific access can be programmatically re-established in the following cases: • Silverlight code exposes one or more scriptable entry points that accept

ScriptObject references as input parameters. • Silverlight code explicitly registers the scriptable entry points by calling the

RegisterScriptableObject method. • Access to scriptable entry points is not disabled with the

ExternalCallersFromCrossDomain attribute. • JavaScript code accesses the plug-in's Content property, obtains a reference to

one of the scriptable entry points, and passes a DOM object or JavaScript object reference as an input parameter.

• These conditions cannot occur by accident. The Silverlight managed code and the JavaScript code must each be written specifically to allow mutual access.

• Silverlight managed code can obtain the value of the plug-in's enableHtmlAccess parameter by getting the Settings..::.EnableHTMLAccess or HtmlPage..::.IsEnabled property.

from JavaScript to Silverlight• The ExternalCallersFromCrossDomain attribute accepts two values: ScriptableOnly and

NoAccess.

<Deployment xmlns="http://schemas.microsoft.com/client/2007" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" EntryPointAssembly="MyAppAssembly" EntryPointType="MyNamespace.MyApplication" ExternalCallersFromCrossDomain="ScriptableOnly"><Deployment.Parts> <AssemblyPart Source="MyAppAssembly.dll” /> <AssemblyPart Source="MyUserControl.dll" /> </Deployment.Parts></Deployment>

ExternalCallersFromCrossDomain Workarounds• When the ExternalCallersFromCrossDomain attribute is set to NoAccess, direct

access to Silverlight managed code is not possible. However, individual, specific access can be programmatically re-established if the following conditions are true: • The Silverlight plug-in's enableHtmlAccess property is set to true. • Silverlight managed code calls a JavaScript function and passes one or more

managed objects as input parameters to the Invoke, InvokeSelf, and SetProperty methods.

• The managed instances passed in the previous step have scriptable properties, methods, or events, and the objects have been registered for scriptable access by using the RegisterScriptableObject method.

• These conditions cannot occur by accident. They require explicit steps by the cross-domain Silverlight-based application to pass managed objects to the host's JavaScript.

• You can get the current value of the ExternalCallersFromCrossDomain attribute from the ExternalCallersFromCrossDomain read-only property. This property returns a CrossDomainAccess value that indicates the access level of cross-domain callers.

HTTP communication

Default HTTP Support • Same-domain calls are always allowed.• When the Web server hosting the Web services is

appropriately configured, cross-domain and cross-scheme calls are supported.

• All communication is asynchronous.• Only GET and POST verbs are supported.• Most standard and all custom request headers are supported.

(Headers must be allowed in the cross-domain policy file before they can be set on cross-domain requests.)

• Only 200 OK and 404 Not Found status codes are available.

HTTP Communication Scenario

Same Domain

Cross Domain• Silverlight cross-domain policy file (clientaccesspolicy.xml)• A subset of the Adobe Flash cross-domain policy file (crossdomain.xml)

Redirects on cross-domain policy files are not allowed. However, a Silverlight-based application will follow a redirect for a target resource. The resource can be retrieved only if access is granted by the following:•The cross-domain policy file at the domain indicated by the original URI before redirection.•The cross-domain policy file at the domain indicated by the final URI after all redirections.

Cross-Domain Policy File Example

Network Security Access Restrictions in Silverlight 2 (more crossdomain policy file)http://msdn.microsoft.com/en-us/library/cc645032(VS.95).aspx

<?xml version="1.0" encoding="utf-8"?> <access-policy> <cross-domain-access> <policy > <allow-from http-request-headers="SOAPAction"> <domain uri="*"/> </allow-from> <grant-to> <resource path="/services/" include-subpaths="true"/> </grant-to> </policy> </cross-domain-access> </access-policy>

URL Access Restrictions in Silverlight 2

Reference• Security Settings in HTML Bridge • Silverlight MD5 implementation - Home • Dr. Dobb's | The Silverlight 2.0 Security Model | 3Ô 9, 2

008

• .NET Security Blog : Silverlight Security Cheat Sheet • .NET Security Blog : Silverlight Security III: Inheritance • .NET Security Blog : Silverlight Security II: What Makes

a Method Critical • .NET Security Blog : The Silverlight Security Model • CLR Inside Out: Security In Silverlight 2 • Calling secure (SSL) services from Silverlight 2 • HTTP Communication and Security with Silverlight