Someone asked me to hack his Silverlight portal. The goal was to test the security and to give some recommondations for future projects. This is part one of my trip down hackers lane.
As a Microsoft developer I know Silverlight is an simplified version of the .NET framework. The XAP file contains the assemblies and a manifest file with some meta information. Changing the extension to ZIP wil reveal te contents of the file. The same trick applies to DOCX and other office files, so you might call it Microsoft behavior.
My first step is to obtain the XAP file. The file must be send to the client to be executed, so check your browser cache. I opened the source view of the webpage hosting the XAP file and found the url. An example of what to look for is below
<object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%"> <param name="source" value="ClientBin/portal.xap"/> <param name="background" value="white" /> <param name="minRuntimeVersion" value="4.0.50401.0" /> <param name="autoUpgrade" value="true" />
The contents of the XAP file showed me the use of
- Telerik controls, used to make it pretty
- MvvmLight, used for guidance of mvvm
- Csla, used to standardize data access
Hmm, would the Csla WcfPortal be used? To find out I decompiled the assemblies using Reflector and found a class called DataPortalHelper with the following code:
public static string GetProxyUrl(StartupEventArgs e) { // less important stuff removed ... return string.Format("{0}/Services/WcfPortal.svc", str2); }
Looks like the WcfPortal is used. I need to investigate further. For now the question is: Standard components like Csla save time in development and maintenance, but you open up the books of what happens on the server. Can we live with that or is this too much of a security risk?
Pingback: Hacking Silverlight part 2 | Erictummers's Blog
Pingback: Hacking Silverlight part 3 | Erictummers's Blog