Silverlight2 Security Microsoft Korea Next Web Team Reagan Hwang / UX Evangelist
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
Security Settings in HTML Bridge
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 .
When the enableHtmlAccess parameter is set to true, as shown in the previous example, the following HtmlPage properties are enabled:
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.
Silverlight managed code can obtain the value of the plug-in's enableHtmlAccess parameter by getting the Settings..::.EnableHTMLAccess or HtmlPage..::.IsEnabled property.
The ExternalCallersFromCrossDomain attribute accepts two values: ScriptableOnly and NoAccess .
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.
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.
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.
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.
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.