Silverlight Security Concepts

2008-04-01T19:35:00Z

I’m cutting into this topic to remind myself that even though Silverlight is the greatest thing since sliced bread, there are a few things that we have to keep in mind when developing a ~~flashy~~ shiny Silverlight application.

First of all.

Your silverlight code is visible to the end user.

A brief walkthrough of how a user might acquire the silverlight code that you’ve written for your Silverlight application.

User goes to your site
Whips out its favorite DOM explorer or just simply the ‘view source’
Find the object element inside your page thats hosting your silverlight application
Find the “src” attribute which contains a link to the “Clientbin/ShinyApp.xap”
Downloads the application, unzips the xap (it technically is just a zip file)
And finally the user gets out Reflector and starts poking around your code.

This is my opinion is great, no longer do I have to spend countless hours tweaking and hacking away to get that awesome animation working, when I can simply look at the source code itself and learn by coding.

Mike Harsh , PM in the Silverlight team mentioned in the initial video on Channel9 that the first release of Silverlight will use textual (as opposite to compiled binary) xaml to enable all developers to share their source, and are looking for input from customers if they prefer perhaps a compiled version of their xaml.

Good news is, if you haven’t noticed that most of the current Silverlight 1.0 application use the inline or referenced xaml pages for their content, which in my opinion (and Mikes) enables a more fluent adoption of Silverlight.

All is well.

However, their might be some developers that are transitioning from ASP.NET to silverlight or are looking at the possibility of integration.

Howver, with the ASP.NET model comes the complete seperation that all managed code and (most of the) UI logic is run on the server and spit backout to the client as easy and (usually) safe Javascript.

With Silverlight however, this distinction is not present.

You could write an entire application as a Silverlight application, and mentally translate all your database calls to WCF calls which inturn does your basic database CRUD.

This however would not be a big deal, since the calls to your WCF services are being protected by the cross domain policy file which restricts (or enables) cross domain calling of your WCF services.

The user can see you’re code calling the webservices, but the potential abuser cannot call your webservices as it cannot impersonate your Silverlight application even though he might even physically have your application.

Ofcourse, you can still write code which might undermine your application (or more importantly the users) security, but using the cross domain policy and encapsulating you’re database calls inside your WCF calls is great way to minimise the potential of your data becoming compromised.

A few more weeks of Silverlight and I think I might have to join these guys...

I also recommend this talk over at the Mix08 sessions called "Working with Data and Web Services in Microsoft Silverlight 2"

Daveloper

Silverlight Security Concepts