Grass Cutting and Defensive Coding

What does cutting your grass and defensive coding have to do with each other?  Give me a second to tell a real life story.

A week and a half ago my wife and I closed on our new house here in the Seattle area.  The house had a wonderfully landscaped ½ acre of property and was being sold by a family that had moved back to Germany a few months prior. 

A few weeks before settlement we visited the house again to get a couple of measurements and notice that the grass was getting very tall, so our realtor (highly recommended if you need to buy or sell a home in the Seattle area) contacted the Remax agent that was listing the house.  The selling agent assured as that the property would be mowed before settlement after all it is up to the seller to maintain the property until the sale is complete.

On the day of settlement the grass was now measured in feet in some areas.  The agent advised us that the lawn was supposed to have been cut already but that the people to do it would be out before the end of the weekend (this was on a Friday).  So we believed her.

Monday, no one had come.  After repeated calls, almost daily, for over a week to the selling agent our agent and her husband rented the heavy equipment that was now needed to chop down my lawn that in places was now passing 3 feet and got the yard back to a manageable height.  This was way above the call of duty and greatly appreciated as we had not yet been able to dig through the piles of boxes from the movers to find our lawn mower.  A follow up call was made to the selling agent to let her know this was done and she just needed to send some people to get the massive amount of grass off the lawn before it killed it.  This gave way to the typical “no problem” type response.

Someone did indeed show up to rack and bag my lawn; of course they only did part of the yard and left a huge section that was some of the worse areas.  To put this in perspective it is probably a couple of hours of racking for my wife and I plus 15 to 20 large trash bags of grass left.

What was my mistake?  I trusted in the statements of the selling agent.  I assumed that I could accept her assurances that my lawn would be mowed and restored to the state that I saw the property in when we agreed to buy it.  Now I am left with a mess of a yard to clean up despite repeated promises that it would be taken care of.

How does this relate to coding?  I was reviewing some code the other night and I came across something that looked like this:

Dim fontSize as integer
fontSize = FontSizeTextBox.Text

‘ Some code to set screen font size

This code trusts the user to enter a value in the textbox that will convert to an integer with no problem.  The code assumes that the user will provide good data, a situation that can lead to a mess at runtime that someone will need to clean up.

I see developers make assumption about user input all of the time without validating it.  Code defensively, always validate user input and data before working with it.  While it will take a brief bit of extra development time it will greatly reduce problems down the road.

Another example I saw in the past couple of days was an email that asked people to cut and paste a value from the body of the mail into a textbox on a registration page.  The problem was that when highlighting the text in Outlook some users highlighted an extra space at the end.  The registrations page did not trim the text, it assumed that the user would never add leading or trailing spaces, this caused the registration code to be rejected as not matching any valid codes.  Only a small percent of users made this mistake, but over the millions of users the mail would go to that turned out to be tens of thousands of customers having a bad experance because someone did not do text.trim().

In another example I see this often in web applications is this:

https://somesite.com/login.aspx?UserID=Bob

Then in code you see something like this:

Dim UserID as string

UserID = Request.QueryString(“UserID”)

SQL = “Select * from Users Where UserID=’” & UserID & “’”

cmd.FillDataSet(….)

This code trusts that the user will not mess with the query string or provide you with a user name. 

What would happen if the user changed Bob in the query string to be:

‘; Delete Users –

This text would be inserted directly in the SQL string.  The first quote would like the string so that the select statement did not return an exception.  The ; tells SQL to start processing a command and the trailing – comments out the closing ‘ so that does not cause an error.

This is called a SQL Injection attack.  It can be used for a lot more then just deleting files.  A malicious user can issue DBCC commands or crawl the system tables to gather lots of information about your database or steal sensitive information.

By blindly trusting users to give you valid input you open yourself up, even in simple code, to runtime errors and exceptions or even worse to major security holes.  It only takes a few simple lines of code to valid a number as an integer, or trim spaces, or prevent a SQL injection attack.  Make sure you spend the time to do this as not every user will be the right thing (either intentionally or by accident) and you will be left with problems.

If I had validated the selling agent’s remakes and “thrown an exception” at closing I would have greatly reduced my pain.  Like wise, if you validate user input and deal with it at that time you can save yourself a lot of pain after you deploy your application.