Silverlight 5 Security: Designed for the Intranet

Posted by Jonathan Allen on Jan 04, 2012

Sections

Development

Topics

Silverlight ,

Rich Internet Apps ,

.NET ,

Languages ,

Security ,

Programming

Silverlight’s role has always been poorly understood. Originally it was seen as something to compete with Flash, but Flash itself is being replaced by HTML5. It was also seen as a way of delivering cross-platform applications, but Apple’s policies concerning iOS made that a non-starter as well. Surprisingly it is thriving in areas that were supposed to be the domain of WPF such as internal business applications and Silverlight 5’s updated security model reflects this.

Silverlight 2, seen by many as the first real version, wasn’t around for very long before people started asking for ways to deliver traditional style applications. Known as “out-of-browser” or OOB, this feature was first made available in Silverlight 3. But even before that was released people were starting to ask for access to COM. But as we all know, COM in the browser was a horrible idea as far as security is concerned. Yet Microsoft relented and it was added in Silverlight 4, but only for OOB applications.

Once they had a taste of COM, Silverlight developers demanded even more access to the underlying OS. And they demanded that access even if they are running inside the browser. So we now we have Silverlight 5 with p/invoke, full trust within the browser, and not even the illusion that this is anything but a corporate technology. Some may see this as a rather bold statement, but consider this passage from the updated Silverlight Security Overview.

In browser - trusted applications – Like trusted applications out of browser, these applications have additional privileges such as access to the filesystem and calling COM objects. In browser apps can run with trust only if they are signed with a key in the trusted publishers list and is subject to group policy settings in a corporate environment. The user is never prompted to grant permission.

Becoming a “trusted publisher” isn’t a simple matter of buying a code signing certificate. To be added to that list a user would have to manually import the certificate and install it using a snap-in for the Microsoft Management Console. There isn’t even a shortcut for it in the Control Panel; users have to launch it from the command line.

In Silverlight 4 applications were at least restricted from ever having administrator access. That limitation has also been removed.

Silverlight 5 does not strip administrator privileges. In Silverlight 4, if the Silverlight app is Run As administrator, Silverlight will remove administrator privileges by launching a second restricted process and ending the original process. The restricted permissions were similar to the User Account Control (UAC) restrictions on Windows Vista and above. Silverlight 5 gets rid of this logic and follows normal operating system rules – in SL5, if the application is launched as administrator, it's executed with administrator privileges, and if it's not launched as administrator, it's not run with administrator privileges.

Code Signing

If you are deploying an Internet-facing Silverlight application then you can discount all the trusted application stuff, but there is still a lot of security measures you need to consider. First and foremost, Microsoft recommends that you sign all Silverlight applications. “If you can't use a signature issued by a Certificate Authority (CA), you should at least self-signed the application to prevent man in the middle attacks against upgrading your app.”

Re-hosting

A major risk factor for Silverlight applications is re-hosting. One could create a “phishing” site that hosts a copy of your actual Silverlight application. Service calls are then bounced through the fake site so that the usernames and passwords can be harvested.

One way to reduce the risk of this attack is to check to see what page the application was launched from. If it isn’t coming from the right domain then you should exit on startup.

Cross-site Scripting Attacks and Page/App Trust

By default Silverlight is not vulnerable to cross-site scripting attacks. However vulnerabilities can be introduced by the exposure of scriptable functions, especially if those functions call XamlReader.Load or AssemblyPart.Load. As a rule, any function that is tagged with the ScriptableMemberAttribute can be invoked from JavaScript and should be carefully reviewed for security vulnerabilities.

Another possibility is the introduction of a rogue Silverlight application invoking JavaScript on the page. To reduce the likelihood of this the EnableHtmlAccess property on the <object> tag should be explicitly set to false if possible. (Note: false is the default when the page and application are from different domains.)

Direct Service Invocation

An often overlooked attack vector is the service calls used by the application. WCF has no reliable way to detect whether a web service call is actually coming from the Silverlight application, so you have to assume any service call is potentially malicious and any validation done by the client must be duplicated in the server.

• Older >