8 February 2010

Silverlight and security: Developing secure applications

Silverlight is like any other web-based interface – a lot of thought needs to be put into securing it properly.

Any application needs to protect your applications from hackers – both on the client side and server side – as well as eavesdroppers who may be listening in on any server connections. It’s normally safe to assume that somebody, somewhere, will try to exploit your application at some point.

When figuring out an approach to securing an application, it’s important to think about what, exactly you are trying to protect. You don’t need to protect every aspect of your code – after all, if somebody wants to copy your visual design then they will without having to look at any code. However, you do need your intellectual property, and part of the application design process may involve deciding what this actually encompasses – algorithms, data or unique code implementations could all carry commercial value that you will need to protect.

Silverlight can’t be trusted with secrets

As Silverlight is compiled, it’s easy to fall into the trap of thinking that it’s more secure than any other interface technology. This is not the case, as Silverlight is no more secure than an application built on HTML and JavaScript.

It’s pretty straightforward to decompile Silverlight XAP files, read XAML files and exploit any other assets included with the application. As with any web-based application you should assume that a hacker will be able to see anything in that runs in the client and design accordingly.

Code obfuscation of XAP files may help to deter a casual observer, but this will only protect against de-compilation of your Silverlight assemblies. Obfuscated code still has to be loaded into memory, so a more seasoned hacker will be able to use a memory profiler to read the code. Obfusication is not really a solution for protecting Silverlight assets.

XAML is analogous to XHTML and CSS and is only stored as text, so can be easily read unless it is protected via server-based permissions. It is possible to dynamically generate XAML on the server, but this is hardly worth the effort given the fact that XAML does not really encapsulate any genuine intellectual property.

Isolated storage can trip developers up as it provides no protection at all from somebody wanting to read the data. This makes sense, as you wouldn’t want an application writing secret information to your hard drive, but as a developer you should never keep anything at all sensitive in isolated storage.

As with any web development, it is important to limit the surface area for attack and removing any intellectual property from the interface code. If your application includes data, algorithms or logic that you don’t want to share with the rest of the world then this should be encapsulated on the server and accessed via service calls.

Using authentication to protect files and data

Silverlight XAP files, XAML and assets can be protected just like any other file using authentication. A modular approach to application design can help with organising your file security as individual modules can be secured for different users and roles. In this scenario, an initial login application does have to be available for anonymously access, but a composition framework such as Prism or MEF can help to break your application up into self-contained XAP files that can be individually secured.

Web services also need protecting as it’s easy for an intruder to find them and start exploiting them without using the Silverlight application. WCF-based web services for Silverlight are particularly difficult as Silverlight only supports communicating in basic text (the basicHttpBinding) , making them vulnerable to packet sniffers. Whether you’re using SOAP-based services, RESTful services or RIA services you will need to minimise the amount of information exchanged between client and server as a first step, but ultimately you will need to protect your web services via some form of authentication.

Authentication options

You have three options for authentication: cookie-based security through forms authentication, NTLM-based (or Windows) authentication, and a custom, token-based approach. Basic authentication based on a username and password is inherently insecure as it involves exchanging a username and password over the web. Although this can be mitigated using SSL, it is not really recommended as a means of securing web services.

Integrated Windows authentication does assume that the client supports NTLM, which can be problematic for OSX. As Windows authentication can be difficult to scale up for an external-facing application, it’s only really appropriate for internal-facing corporate applications.

Forms-based authentication is a less platform-specific alternative, but cookies should be expired frequently and never decrypted on the client. It’s worth pointing out that Visual Studio’s functionality for adding and refreshing service references does not play well with any form of authentication. You have to go through the rigmarole of disabling authentication before updating any references – this is still not fixed in Visual Studio 2010, apparently.

If you don’t need to leverage the built-in role-based security that comes with .NET authentication, then a custom, token-based security system could be used where a session token is passed into each web method call. This can be convenient for web services as it is not too much work to implement and can be very scalable, but it is not fool-proof or totally secure. Ensuring that tokens are expired very quickly can help to prevent eavesdroppers from usefully exploting any tokens.

Filed under UI Development.