Concepts To Become A Silverlight Master (Series Part 4 - Security).aspx
Series Articles:
This article focuses on the topic of security and Silverlight. This is an abstract software development concept that every software developer should be aware of regardless of the environment in which they are developing. However, each environment is different and exposes different risks. Silverlight is no different. Furthermore, because of its architecture, Silverlight exposes some potential security holes. In this article I go over the security risks to consider in Silverlight, how a hacker can use several tools to extract desired information and what to do to protect your applications.
Silverlight Environment
Silverlight applications execute on the end user's workstation. This means the entire application and all the resources are brought down to the client and executed inside the client's environment. The Silverlight 2.0 application is brought down in an XAP file. An XAP file is a file that includes: xml configuration/manifest files, resource files (XAML, images) and of course your business logic which is a compiled assembly (dll). The XAP contains all these items because it is essentially a ZIP compressed file with a XAP extension. By default, the XAP file does not include any compression security. If you are a seasoned developer, this should immediately trigger some possible design concerns you would want to avoid.
If you are designing applications for the Silverlight environment, there are obviously some security precautions you will want to consider:
Securing Your Code & Protecting Intellectual Property
Just like the full .NET framework, the .NET 3.5 subset that runs Silverlight is managed code. The code is compiled in IL and can be very easily reverse engineered. A great tool for reverse engineering code (even Microsoft's own .NET Framework) is Reflector. A common solution to protect applications from other hackers or developers from easily reverse engineering code is obfuscation. Obfuscation will rename objects, fields, methods, etc., in your code to code that is a lot less readable. Remember, .NET doesn't care if a method in code is called "GetCustomers()". It can just as well be called "a()". This is just one example of obfuscation. Traditionally web developers that utilized web assemblies did not have to consider this, as the assembly never left the server (not always the case)
Reflector can disassemble Silverlight 2.0 assemblies
- As a best practice, if there is ultra sensitive code or some secret intellectual property, ensure that it is executed in its own domain on a server where you access the output through a service call. To be absolutely safe, do not place important business logic inside a Silverlight assembly that will be brought down to the client.
- In some cases, there are assemblies that either are not super sensitive or you have at least modest interest in protecting. In these situations, obfuscation is an ideal solution. The code can still be reverse engineered with time; however, it will take a more dedicated effort.
- Assemblies are not just vulnerable when they are executed or brought down to the client's workstation. Remember that assemblies can also be "picked off" during transit. For example, say you wrote a great application that is only available to users who have been authenticated through your web site. Inside the XAP file you include some sensitive information that is okay for the end user to look at. However, while in transit, this can still make the information inside your XAP file vulnerable. If you are concerned about the XAP package being intercepted, consider using https as a secure delivery mechanism to the client.
- Always make sure to sign the assemblies and provide the proper copyright information, especially if they are leaving the web server.
Isolated Storage (Protecting Sensitive Data)
Silverlight includes a concept called Isolated Storage, which can be viewed as large temporary storage mechanism ("cookies on steroids" is another term I saw on a blog recently). Isolated Storage utilizes three files to manage the contents of Isolated Storage and it is cleared when a user clears the browser cache. The files are well documented so a hacker who knows about Silverlight can easily access them. Furthermore, the contents of Isolated Storage are not secure and should not be assumed so.
- If you are persisting sensitive information on a client's workstation via Isolated Storage, consider obfuscating or encrypting the information. Information such as passwords or sensitive client data will probably warrant the use of the cryptography library inside .NET. Information such as a list of phone numbers might not warrant full-blown 128-bit encryption; however, obfuscating it with Base64 encoding might suffice. The choice is up to the developer to determine how sensitive the data is. However, when persisting data on the client, remember that the end user can always do something stupid and lose their laptop. You do not want to be the one responsible for writing an unsecured application that causes identity theft because someone lost their computer.
- Encrypting data on the client workstation exposes another issue to consider. Obviously, you cannot write encryption inside a Silverlight assembly for Isolated Storage and leave it wide open. A best practice would be to obfuscate the assembly that is used to encrypt the data. Another possible solution is to have the data encrypted through a service call and the encryption logic. More importantly, the key is never placed on the client.
- Remember, you cannot protect everything! (So don't even try to) Just like on the web, your graphic files, Javascript, HTML design are all exposed for everyone to access. Inside Silverlight, this applies to your XAML code and potentially your resource files.
Silverlight Spy is a great program that "extracts" the UI information from the XAP file. Not only that, it can also peek into the Isolated Storage of a Silverlight application.
Secure Communication (Protecting Data in transit to a Silverlight Application)
Silverlight includes several communication mechanisms to retrieve data outside its application domain. The most popular mechanism is through service calls (Web Services). As I wrote in part 2 of the series, Silverlight has great integration with WCF. There are limitations though as to which bindings are supported. Since WCF is part of the .NET 3.0 Framework, a great deal of bindings are not supported simply because Silverlight runs on a subset of the full .NET framework.
- One of the core bindings inside WCF is basicHttpBinding. This binding is largely around for backward compatibility and is usually avoided when designing enterprise based services with WCF. However, this binding is one of the few that Silverlight supports and will be used in Silverlight apps. BasicHttpBinding (unlike other WCF bindings) is, by default, unsecure. Therefore, the default communication mechanism will encode your message as clear text when using this binding. This maybe okay data that does not require secure transport. However, if it does, this binding should be made secure using https. For more information, watch this great video on some of the limitations of Silverlight/Https communication.
Fiddler is a great tool for inspecting message envelopes (peeking into unsecured web calls). Is your information exposed in clear text?
In general, designing services with best practice SOA guidance is not different for Silverlight consumers. I wanted to focus on WCF-BasicHttpBinding because there are a lot of examples using this binding with Silverlight and a lot of applications start from examples. The examples often don't mention that one of the drawbacks of the binding is that it defaults to an unsecured transport.
Isn't this just common sense?
All of the concepts listed above are essentially "best practices" regardless of which platform development is being done. Desktop applications have the same security concerns as Silverlight apps (local assemblies, access to temp/local files, etc). Web Services have the same security concerns as Silverlight consumed services.
- Silverlight is a new technology and many posts, articles and videos neglect to mention security implications in their examples. It is easy to get lost in all the options inside a new environment and lose focus on common design considerations (i.e., security).
- Silverlight is a unique plug-in model that runs on a subset of the .NET 3.5 framework on a client workstation. Services are typically your best bet of communicating with databases or outside the client app domain. These key features of Silverlight can sometimes be a trap to developers coming from other environments. Developers not familiar with plug-in architecture, WCF or just novices starting out with Silverlight can easily fall into a security trap and design an application with major security holes.
- There is some guidance on Enterprise level Silverlight applications and some articles on the web do focus on security. Right now this is limited; however, it should not be overlooked. Security is very important to consider during the design phase and even though there may be no formal "security best practice", you do not want to write a Silverlight application that is easy to breach.
- The tools I listed above: Silverlight Spy, Reflector and Fiddler are not just some hacker tools. Any serious developer should be using these tools to ensure their applications are written in the desired security model.