You may know that Silverlight applications can run in three different security modes:
- In browser — the application runs as part of a larger webpage, and is subject to the same sandboxed protection as other web content.
- Out of browser – sandboxed — the application can run in browser, but it can also be installed onto the user’s Start menu; Silverlight will prompt the user before installing. Sandboxed out of browser applications have the same security restrictions as ‘in browser’ applications.
- Out of browser – trusted applications — like sandboxed out of browser, these applications could be run in browser with security restrictions available for “in browser” application. The difference for trusted applications is when the application is installed and run out of browser, the application has additional privileges, subject to user granting permission and group policy settings in a corporate environment. From a security perspective, running this class of Silverlight application is similar to running a .exe — it has access to a subset of the file system (‘My Documents”) and calling out to COM objects.
All of them has their own restrictions and useful tips. But how an ordinary user will discover them?
Microsoft helped us by publishing Silverlight Security Overview (Whitepaper). All security notices are there.
From the Abstract:
“Security on the Web continues to be a significant concern to consumers and enterprises alike. Security becomes increasingly important as we see the migration of more and more everyday activities onto the Web is driving the explosive growth in applications built on Web development platforms such as Microsoft Silverlight. In this environment really secure applications are a result of both protection built into development platforms and adoption of secure practices by developers. This document describes how Silverlight protects end-users from attack by malicious web sites, and how to build a secure Silverlight application.” Nick Kramer, Microsoft Corporation – April 2010.
But it’s not only describing the policies, but suggesting solutions.
Let’s see what are they suggesting for preventing unauthorized reuse of our .xap files:
public App() {
// Check that the xap is hosted on the page we
// expect it to be hosted on. Make sure to do
// this in the App constructor rather than the
// Startup event or page constructor, as exceptions
// thrown then won't bring down the app.
if (App.Current.Host.Settings.EnableHTMLAccess == false)
throw new Exception();
string htmlurl = System.Windows.Browser.HtmlPage.Document.DocumentUri.ToString();
//Comparing with your website address
if (htmlurl != "http://foo.com/mypage.html")
throw new Exception();
this.Startup += this.Application_Startup;
this.Exit += this.Application_Exit;
this.UnhandledException += this.Application_UnhandledException;
InitializeComponent();
}
This code is preventing reuse by throwing exception if HTML access id disabled and application is trying to run out side your website. Simple and clever. Also, there is solution for another .xap checking. This time it’s checking from where .xap file were downloaded:
public App() {
// Check that the xap is hosted on the server we
// expect it to be hosted from. Make sure to do
// this in the App constructor rather than the
// Startup event or page constructor, as exceptions
// thrown then won't bring down the app.
string xapServer = this.Host.Source.ToString();
if (xapServer != "http://localhost:60338/TestApp.xap") {
throw new Exception("Application came from an unexpected server");
}
this.Startup += this.Application_Startup;
this.Exit += this.Application_Exit;
this.UnhandledException += this.Application_UnhandledException;
InitializeComponent();
}
All other information is available here at Microsoft security doc. And you can look at the Shawn Wildermuth’s session at MIX10 video with PPT. He is providing security tips for securing your Silverlight applications.