Alik Levin's

Clarity, Technology, and Solving Problems | PracticeThis.com 

July, 2007

  • Alik Levin's

    Use Sysinternals DebugView To Diagnose The Application

    • 7 Comments

    "Unspecified error", "Catastrophic failure", "Object reference not set to an instance of an object" and other "self explanatory" errors promise no easy debugging. Good instrumentation of the application  to the rescue! The techniques described in the paper explores on very often overlooked healthmonitoring feature of ASP.NET 2.0. It supports few providers - mechanisms that collect and log the events emitted by the application:

    • SimpleMailWebEventProvider. This provider sends e-mail for event notifications.
    • TemplatedMailWebEventProvider. This provider uses templates to define and format e-mail messages sent for event notifications.
    • SqlWebEventProvider. This provider logs event details to a SQL Server database. If you use this provider, you should encrypt the connection string in your Web.config file by using the Aspnet_regiis.exe tool.
    • EventLogWebEventProvider. This provider logs events to the Windows application event log.
    • TraceWebEventProvider. This provider logs events as ASP.NET trace messages.
    • WmiWebEventProvider. This provider maps ASP.NET health monitoring events to Windows Management Instrumentation (WMI) events.

    Nothing is to log into file or to show interactively though.

    Here is another way for quick and dirty understanding what happened in the app (assuming instrumentation is in place). Instrumentation mechanism is my old friend System.Diagnostics.Debug.WriteLine(string message). This command emits messages to OutputDebugString. The best tool that collects and shows the messages that I found so far is Sysinternal's Debugview.

    The following code:

        protected void Page_Load(object sender, EventArgs e)
        {
            Trace.WriteLine("Loading the page");

        }

    Would interactively look like this:

    image

    DebugView also offers logging the events into file - very handy.

     

    While healthmonitoring is great to log stuff for later analyzing, tracing with DebugView is great for interactive debugging. I can think of some wrapper class that is used by the application to log the messages, and the implementation uses both healthmonitoring custom events and Debug.WriteLine. Both then rely on the web.config stuff.

     

    Enjoy and happy debugging, tracing, instrumentation, and other veggies.

  • Alik Levin's

    Typed DataSet - Potential Performance And Security Risk

    • 4 Comments

    Are you using Typed DataSet as DTO (data transfer object)? Are you building distributed systems where the DTO goes back and forth including your Smart Client? If yes then I think you should be aware that the most of your DB schema can be easily revealed using my friends ILDASM and FindStr.

    It is common pattern creating shared libraries that contain only data definitions. These libraries are shared/deployed usually to both client and the server.

    In my example I created simple library called TypedDataSetSharedLibrary.dll. It holds Typed DataSet I generated from AdventureWorks sample database. I ran simple command line as follows:

    ildasm.exe TypedDataSetSharedLibrary.dll  /text | findstr /C:"ldstr" >"C:\TypedDataSetSharedLibrary.dll.Strings.txt"

    Here is the fragment of what I see after opening the resulting file:

    IL_00d7:  ldstr      "tableTypeName"
    IL_00e4:  ldstr      "vEmployeeDataTable"
    IL_001d:  ldstr      "The value for column 'Title' in table 'vEmployee' "
    IL_001d:  ldstr      "The value for column 'MiddleName' in table 'vEmplo"
    IL_001d:  ldstr      "The value for column 'Suffix' in table 'vEmployee'"
    IL_001d:  ldstr      "The value for column 'Phone' in table 'vEmployee' "
    IL_001d:  ldstr      "The value for column 'EmailAddress' in table 'vEmp"
    IL_001d:  ldstr      "The value for column 'AddressLine2' in table 'vEmp"
    IL_001d:  ldstr      "The value for column 'AdditionalContactInfo' in ta"
    IL_0059:  ldstr      "XmlSchema"
    IL_00a9:  ldstr      "vEmployee"
    IL_00c9:  ldstr      "vEmployee"
    IL_0031:  ldstr      "vEmployee"
    IL_004f:  ldstr      "vEmployee"

    It is clear that from such information an attacker may learn a lot about DB schema thus being able to craft her attacks more easily.

    Why it is performance risk? Well, it is not but using this approach one could spot it.

    Imagine that the above fragment only small representation of huge data set that travels the network. Recently I stumbled on such code. This simple check revealed that the code uses Typed DataSet of about 1000 columns. We assumed that this should be a problem from network throughput perspective and we ran some load tests using VSTS.

    The result was pretty expected - almost all bandwidth was utilized by load of few simultaneous users.

    Next time you design distributed system - take these into account.

    Plus Dino Esposito once published another discussion around DataSets vs. Collections which might be useful too.

     

    Enjoy

  • Alik Levin's

    WCF Security In Intranet Scenario : Thoughts On Cons and Pros

    • 3 Comments

    I am researching on best practices with WCF security in terms of "YOU SHOUD" vs "YOU CAN". While it is great to have "How to" stuff I am also interested in "Why" angle. I have common simple scenario of WinForms client consuming WCF service inside corp walls with Active Directory deployed. Here is what I came up with while looking at Hosting Services and Common Security Scenarios.

    I have built simple Hello World WCF service that accepts Person object/message and echoes back "Hello, " + Person.FirstName. I was using DataContract serialization. I think it really does not matter what it does in terms of biz logic. What really matters for me is how to host it, what binding to apply, and what security settings to configure.

    For my intranet scenario "Message Security with a Windows Client without Credential Negotiation" would fit most I think. It utilizes Active Directory for authentication and message protection in transit as well saving me from messing with certs, transport level protection SSL, IPSEC style and plain vanilla UserName and Passwords. I think it is great and apparently it is a pro part from security stand.

    Since it uses wsHttpBinding binding I thought it would be natural choice to host it in IIS rather self hosted as it shows up in the example. Here I earn what IIS has to offer vs what I can write in C#...

    I also implemented scenario where I used basicHttpBinding with security set to None...

    I fired up Fiddler2 to see what runs on the wire in both cases. The difference was pretty notable in terms of response time and payload size. Of course all these goodies that come from using Kerberos from my Active Directory friend - authentication and message protection - have their cost in terms of performance. I guess it is cons part from performance stand. I presume the time is spent for negotiation with Domain Controller and for cryptographic operations - encryption and signing - for message protection. The other cons part would be message size that naturally inflates when encrypted.

     All my experiments are done with my demo lab domain that is totally based on VPC 2007 so the numbers should be taken with caution but I presume that it can give some food for thoughts. Consider simple message as follows:

    <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">

       <s:Body>

          <SayHello xmlns="http://tempuri.org/">

             <person xmlns:a="......." xmlns:i=".....">

                <a:FirstName>Alik</a:FirstName>

                <a:LastName>Levin</a:LastName>

            </person>

          </SayHello>

       </s:Body>

    </s:Envelope>

    Here is what I captured using Fiddler:

     

    basicHttpBinding

    wsHttpBinding

    Message Encryption

     

    V

    Message Signing

     

    V

    Bites sent

    584

    8,014

    Bites received

    420

    5,286

    Time to last byte

    20 ms

    231 ms

    Conclusion

    When designing my next WCF solution for intranet scenario I will sure try to utilize current IT investment like AD and IIS to provide first class security and hosting services while saving on maintenance costs. On other hand I must take into account performance part, this consideration should reflect on message size - for example, think twice when tempted to use DataSet as DTO. It should also reflect on hosting options - using IIS 6.0 allows me to utilize Http traffic only.

    Here is my take on intranet scenario where Windows 2003 Active Directory and IIS 6.0 deployed:

    • Utilize AD for message security and authentication.
    • Host WCF in IIS 6.0. If I had Windows Server 2008 with IIS7 I'd go for WAS hosting for sure since it allows binding other than Http and I presume this should improve performance.
    • Do not use DataSets for DTO rather carefully design custom most lightweight DTO (yes, invest as much time as needed for that one).
    • Use DataContract serialization with opt-in approach (allows fine tune what gets to the wires and what is not).

    You have better suggestion for me around intranet scenario? If so, do not hesitate and drop me a line.

    Here is even more food for thoughts A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies

    Bon appetite.

Page 1 of 3 (8 items) 123