CSLA fiddler inspector?

CSLA fiddler inspector?

Old forum URL: forums.lhotka.net/forums/t/12626.aspx

jamessneg posted on Monday, May 12, 2014

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?

JonnyBee replied on Monday, May 12, 2014


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#.

jamessneg replied on Tuesday, May 13, 2014

Hi Jonny,

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.

jamessneg replied on Tuesday, May 13, 2014

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