Just trust me!!

Today I was working with my intern, we are using DotNetNuke to run a marketing site so that our product team can go in and tweak some things. We have custom workflow in there, and a requirement that we want to save the results of the workflow into our own table so we can report on it latter.

The workflow component has some facilities to do this, so he creates a table and a stored proc, and gives it a shot. He is instantly greated with a lovely error in the front end Invalid Syntax Near xyz

I tell him that's not good, as it indicates a potential for a Sql injection attack. Fast forward three hours, and he is arguing with me that its safe, that it can't be injected, and demands I prove to him it can be done.

Not wanting to take the time or effort to figure out the magic sequence, as this isn't something I do everyday (Contrary to popular belief, I don't sit around trying to hack). I tell him to trust me, parsing errors are easy to inject into. He doesn't buy it, and I can see he is going to be stubborn until I prove him wrong.

Fast forward ten minutes, and I found that injecting with this forms component was as simple as entering a string like the following for the last field:

injectComing' select * from aspnet_users--

Watching with profiler, we quickly saw three key events. First was a Batch Starting which looked something like this:

exec myProc '','','','injectComing' select*from aspnet_users--';

Second was SQL Stmt Starting Event:

exec myProc '','','','injectComing'

Third was another Sql Stmt Starting Event:

select*from aspnet_users--';

Needless to say now he is working on a costume module so we can execute the Sql as a parameterized query and avoid all this ass ache. Moral of the story? While you shouldn't always trust everyone, you should trust your boss who has 10 more years of experience. And if you don't you try and prove him wrong, don't demand your boss to prove himself.


Gahh Interns!

Responsability of Third Party Control & Blacklists

My intern just sent me a screen shot of a CAPTCHA from a site we are working. The CAPTCHA is generated by a third party control which we have no control over.

If you are a developer of third party controls which are sold to professional companies please take the effort to implement a blacklist of letter sequences that should not be allowed in CAPTCHAs. What are the odds of this happening probally preety small but had we lost a sale because of this....

Telerik Gives Back to the Community

While using StackOverflow a great site for asking questions to problems software developers face, I noticed an advertisment from Telerik. They have decided to give any SO user who has over 10,000 reputation points a free developers license to their control suite.

This is great to see a company see the value a site such as Stackoverflow provides, and to provide some recognition to the people who spend their time helping others by answering questions. Thanks again!

Duration in RPC:Completed is Misleading

I discovered something today while troubleshooting a long running query today. We have a specific dialog in our application which in a specific case takes 60 seconds to open up. I fire up SQL Profiler and click run just to see the standard events and verify if this a DB issue or not.

I find that there is a specific query which does take 60 seconds to run according to the RPC:Completed event (We are using SQL Server 2005). So I pull that query out and run it inside of SSMS, it completes in under a second. These are the issues I hate having to troubleshoot. So the first thing was to rule out our web application, so I create a little .net windows form app and I basically run this:

sqlCmd.Connection.Open();

using (var reader = sqlCmd.ExecuteReader())

{

    int i = 0;

    while (reader.Read())

    {

        i++;

    }

    MessageBox.Show(i.ToString());

}

The query runs fine no issue. Now we are actually using nHibernate so I wanted to simulate us processing the result set. I add a small Thread.Sleep(5) (my result set has 1500 items in it so a small sleep duration is plenty). I run the query and wait about eight seconds.

Then I go and look at SQL Profiler RPC:Completed (And Stmt:Completed events). The duration for the events is 8 seconds. Now I am asking myself if I opened a ticket with Microsoft burned a support incident for an nHibernate issue or not.

The moral of the story? Well don't always trust what you think the tool is measuring. And if your interested, when I ran my queries loading the entities through nHibernate with the windows form, the query again completed extremly fast. So I am still hunting this one down.

Update

I found and resolved the issue. It wasn't an issue with SQL but a configuration issue which caused the system to try and log to an invalid file thousands of times which slowed the system down.

This is very eye-opening as one of my fundamental assumptions about SQL Profiler and how to interpret the results has been crushed.

Turning off ASP.Net's Unique ID Generation

One of the things I am not a fan of (but I understand why they have it), is the unique id generation for server side controls in ASP.Net. The unique Id generation allows the framework to ensure that all controls will have a unique client Id, allowing it avoid collisions.

While this is great it does add a lot of complexity as you start to move away from the traditional ASP.Net Web Forms model. This complexity is one of the reasons this feature doesn't exist in ASP.Net MVC. What are some of the issues with the unique id generation?

• If you have javascript in your pages the controls are given a somewhat dynamic name, this leaves you with two options. Either you dynamically generate your javascript, or you can assume that you won't be moving the control, and can hard code the ID. The ID is based upon a concept of Naming Containers which is beyond the scope of this post. But essentially as long as you don't introduce new containers in the hierarchy the Id will always be the same.
• If you want to use post a form to a non-web form page(or different page then the generating page), and want to make use form fields, the field names are associated to their unique id.

The first issue I have always solved by either generating the javascript dynamically in my user controls for example (A user control acts as a naming container and thus all controls in the user control will have it's unique id based on the user control's id). Or by just hard coding the value and hopping I don't change it.

During my latest round of enhancements to my current project I ran into a scenario where I felt I had to disable this unique id generation and couldn't find a workaround that didn't involve rewriting a ton of code. Let me give you some background on the scenario.

This site deals with types of documents, and allows the user to printout (or Email) various PDF files based on the document. There are currently roughly a dozen various printouts and emails which are generated, and the number is always growing. In order to streamline my code and simplify adding new types of printouts, I created a method of doing this which essentially is as follows:

• On the document's details page we have a second form, this form contains all the printing and email options. There are quite a few variations of options, and certain options depend on other options being set.
• We preserve the last options used to printout the document, which are set at render time for the page.
• The form is smart enough to know which type of printout it is doing and will either open a new window, or reuse the current window when doing a post.
• This form posts to an ASP.Net Handler which based on the type of printout directs the request to what I call a print handler. The print handler will either execute (if its sending an email for example), or it might render a new page to let the user see a preview, or it might just generate a PDF for the user.
• When generating PDF's we generate the Html and then use a third party tool to convert it to Html.

It's actually a pretty slick mechanism and has streamlined a lot of the code. My new requirement is to enable printing from other pages then the Details page. At this point I have two choices. I can either duplicate a subset of my code to allow printing for just document types we need, or I can try and find a way to consolidate this printing framework to make it reusable.

I opted for the second option of course. So the first thing was to move all the markup, script and code behind outside of the details page into its own user control. A quick test showed that some basic functionality is there so I dropped the control onto my new page and things were looking good. This might be possible I thought.

Then I started doing a deeper more thorough testing (And I wish I had an automated unit test for this UI stuff but ah well It's on my ever growing to do list). I quickly found that all the Id's had changed, this messed with all the javscript which enables or disabled options based on what you've selected.

Well we can fix this one easily so I pick one of the controls, and modify the javascript so it is dynamically generated, and things are looking good again. So then I go and printout the most complex of the documents, this time paying close attention to it, and I noticed that none of the options that were set, were being honored.

The issue is the form fields changed so in the old version I was expecting to see a field with id of "printDescription" now it's coming out as "printOptions_printDescription". Furthermore when I drop it into a content page, which happens to user a master page which is also nested, the Id becomes a long mess. So now at this point how can I tell ASP.Net to not auto generate the Id's. I could write my own custom server side controls but that's a lot of work. I could get rid of the server side setting of options but to do that I would now have to either generate all the html dynamically, use code in the markup, or make a second call to get an json representation of the print options and set them on the client.

So let's get back to the original point of this post. I am going to turn off the Unique ID Generation. The first thing is this works if you have a naming container, which you can override properties on. A user control works perfectly, and since a user control doesnt render any markup by default it doesn't change the structure of the page.

I have found that by overriding the following properties results in the control's child control's from picking up the containers uniqueid and appending it.

    public override string UniqueID

    {

        get { return ""; }

    }

    public override Control NamingContainer

    {

        get { return null;}

    }

Caution


I have not tested this beyond my simple usage scenario. I do not know what would happen if these controls were used in a normal postback scenario, if they would be able to pickup their state from the form fields or not.