Alik Levin's

Clarity, Technology, and Solving Problems | 

March, 2007

  • Alik Levin's

    How To Hack WCF - New Technology, Old Hacking Tricks


    First of I'd like to thank Guy for his excellent screencast - very convenient, so thanks.

    Specifically I liked introductory screencast for WCF which can be found here:

    It is dubbed in Hebrew, but the screens are flipping in so logical way so that one who does not understand Hebrew will be fine - go for it - recommended a lot for WCF newbies like me.

    My interest was to understand the pipeline that the WCF Message goes through before it is put on the transport. The idea was to inject some custom modules (Inspectors) in the pipeline. Why? Is not it clear? To mess around with the message - tamper it in it raw format before it goes down to the transport signed and protected. Why? To show that it DOES NOT matter what communication technology you use - HTTP, Remoting, MSMQ, WCF, RMI, CORBA, DCOM, MQ, <<fill in your own here>> - the basic principle of VALIDATING INPUT ON THE SERVER SIDE is immutable.

    Here I showed it for Web Services App Architecture with Security in mind - Video, Part I (that was easy - Fiddler is of much help here)

    Then remoting came along - same result, here App Architecture with Security in mind - Video, Part II

    Now it is mighty WCF.

    I used excellent demo from Madhu here that explained how to build IClientMessageInspector (NOTE - demo that works!)

    So here is the service contract:

    and the implementation:

    and the client side validation:

    here is the client rejects the input:

    and here is the result of server processing for good input:

    after adding the custom message inspector, I am offered to tamper the massage before it is sent to the service and the resulting reply from the service is in red at the bottom:


    Does that mean that the communication technologies are bad? - NO, it is the way WE use it.

    Here is an basic example for input validation in Web Services Web Service Input Validation - it has link to regex usage that you can use on the server side for input validation.


  • Alik Levin's

    Performance Testing For The Masses


    "FAST is cool, huh" - good friend of mine told me.

    No doubt.

    How do I identify the bottleneck with architecture like this?

    • Is it Browser starving resources for client side JavaScript/AJAX heavy processing?
    • Is it jumbo Http Responses (ViewState for example)?
    • Is it Web Server processing takes my time?
    • Is it Application Server (let's assume it is Web Services) takes my time?
    • Is it about DB processing?

    Here is the set of tools and steps for sanity check when experiencing performance hits for web applications:

    Measuring User experience (Ux) time

    Information gathered during this step is the overall latency that end user would experience

    Factoring browser processing time

    Information gathered during this step can reveal what content type is served back before it get processed by Browser. Here is an example if the data collected by Fiddler (free download):

    RESPONSE BYTES (by Content-Type)
              image/gif:            344
               ~headers:            12,017
              text/html:            66
                text/xml:            1,107
              text/plain:            687
    application/json:            104,497

    Fiddler gives also time to last byte for each resource too:


    Understanding Web Server processing time (ASPX and ASMX)

    Information gathered during this step can tell you which server - Web Server that serves Web Pages or Web Server that serves Web Services - consumes most of the time. Obviously former should be greater :)

    For that purpose set time-taken property to be logged by IIS:


    Measuring DB processing time

    I'll leave it for another day


    Having all this data at hand one can go ahead and focus on the troublemaker.

    Performance Engineering in details is here (redirects to



  • Alik Levin's

    .Net Assembly Spoof Attack


    To be honest I am not sure about the name of such attack, but in the nutshell it is attack where the original good code is replaced by bad one with the same interface but very bad implementation - may be Trojan DLL? Anyway...

    My Australia based teammate Rocky posted sometime ago coolest screencast - Assembly Hijacking. He calls it hijacking. Go see it, very cool.

    The final verdict was to sign the assemblies with SNK which is almost always a good idea to do. This should definitely prevent such attack he demonstrated. To "Evaluate Whether You Need Strong Names" check on the following in referenced article:

    • You need to add your assembly to the global assembly cache.
    • You want to prevent partial trust callers.
    • You want cryptographically strong evidence for security policy evaluation. <-- this one is for our case

    Lately I stumbled on another post Assembly Load Contexts Subtleties that "focus on Assembly.Load and Assembly.LoadFrom" which discusses dynamic assembly and types invocation.

    I thought to myself "What role SNK plays in this case?"


    Dynamically loaded assembly is not checked for its evidence. That means that all applications that use reflection to load assemblies dynamically are vulnerable to such attack - regardless if there is SNK in place or not.

    What to do to prevent such attack when using reflection?

    1. Do sign with SNK your assemblies.

    2. Use Full Assembly Names When You Dynamically Load Assemblies

    The code you should find there will look like this:

    public static StrongName GetStrongName(Assembly assembly)
       if(assembly == null)
          throw new ArgumentNullException("assembly"); 

       AssemblyName assemblyName = assembly.GetName();
       // get the public key blob
       byte[] publicKey = assemblyName.GetPublicKey();
       if(publicKey == null || publicKey.Length == 0)
          throw new InvalidOperationException(String.Format("{0} is not strongly named"
       StrongNamePublicKeyBlob keyBlob = new StrongNamePublicKeyBlob(publicKey); 

       // create the StrongName
       return new StrongName(keyBlob, assemblyName.Name, assemblyName.Version);

    And here is the check itself:

    Assembly assembly = Assembly.LoadFrom("ReflectedDll.dll");

    StrongName sn = GetStrongName(assembly);

    StrongName myStrongName = null;

    IEnumerator enumerator = (IEnumerator)AppDomain.CurrentDomain.Evidence.GetEnumerator();
    while (enumerator.MoveNext())
       if (enumerator.Current.GetType().Equals(typeof(StrongName)))
          myStrongName = (StrongName)enumerator.Current;

    if (!sn.PublicKey.Equals(myStrongName.PublicKey))
       throw new ApplicationException("SPOOFED!!");



    In the world of provider  design pattern (abstract factory – GoF definition) where assemblies get loaded dynamically one should pay closer attention to this.


Page 1 of 9 (25 items) 12345»