Our company has a few third-party CSLA/Silverlight applications that we use internally. I am on the information security team and would like to be able to examine the requests/responses that the silverlight application communicates, but the raw HTTP requests/responses are in their serialized form, which doesn't make for easy viewing. As we don't have the source for these application, is there there a Fiddler inspector that could be used to view the deserialized traffic? If not, could someone point me, in terms of the CSLA serialization, the direction I need to go in order to write an appropriate inspector?
That depends quite a bit on which version of CSLA you are using and how the app i configured (like using GZIP or other compression utilities to compress the packages or https encrypted communication).
In general terms a CSLA powered Silverlight client will use XML (generated by a CSLA implemented serializer) to communicate with the server. And yes - they ae not that easily readable for "human eyes".
So the standard fiddler debugging proxy should be able to catch the xml in clear text. And no - there is no CSLA specific fiddler inspector available - nor should there be any need for this.
You can use any Decompiler (like ILSpy, dotPeek, JustDecompile - all available for free) to inspect the actual source code for both SL and .NET code in C#.
Thanks for your reply. The app uses CLSA 4.5.500.0 and it does to appear to be using some sort of compression(this is what I need to find out but don't know where to look). I should have clarified in my original post that, yes, I can see the XML of the Soap request in Fiddler, but I need to deserialize the contents of the base64 encoded data in those XML fields(e.g. the ObjectData field).
I am currently going down the track of decompiling the SL code as I do have access to that (as you mentioned). However, I don't have access to the server-side .NET code as this is a black-box test.
My end goal is to be able to manually tamper with requests so I can test how the server responds to unexpected input values, hence why I'm hoping to be able to write a Fiddler inspector.
Thought I'd post this link as well for reference as he had the same question as well. I'll investigate his replies more tomorrow.
Copyright (c) Marimer LLC