Secure code - things to consider, part 1
Writing secure code is a very good thing. So is designing secure applications. Together, they make up a piece of the puzzle and you need both if your app is not to be a vector for an attacker. I know that a lot of developers don’t consider security until integration testing/documentation/other things that get done at the last minute. Because of this, I am going divide this topic up in to “big stuff” and “little stuff”. A lot of it has to be considered at the design stage. Like reliability, security costs a lot to retrofit in to a product. I am going to talk about the little stuff first because I am a low level kind of guy and I enjoy it. How self indulgent is that?
Parameter validation is dull. It bulks out the code. It takes time and you want your code lean and mean. There is a deadline coming up and, if you are writing middleware, then validation is the job of the guy who writes the front end code. Well, that is what a lot of people seem to think :-) It simply isn’t the case. Let us consider some scenarios
Scenario 1. You have some ASP (or ASP.NET) code that is getting its parameters posted back. The HTML has good error checking and so the data passed back pretty much has to be correct. The big problem there is that there is an invalid assumption. The assumption is that the client side code is going to be run unaltered. This is almost certainly true for legitimate users but not true of attackers. If they can modify the client side code then your validation logic just went away.
Scenario 2. You have some code that takes a description of an item and pulls back a resultset (or recordset if you are old school) of items in your stock list that match that item. The query is a select statement and there is nothing there that can change your code. You build up the query with some string concatenation where the passed in parameter is after the where clause. You don’t validate the string because the worst that could happen is that they get an empty recordset if they supply junk. You put a quote at the start and end of the user input so it inert text and pass the whole string off to SQL to interpret. We have all written this code – a lot of simple applications are this with variations in table names and the odd update query. It seems safe but in fact it is one of the most common holes in applications. What would happen if the user input was ‘ “;delete * from SomeOtherTable where SomeOtherTable.UserName <> “wibble ‘? Note the single quotes which in this case (and contrary to C normal practice) enclose the whole and take the double quotes as literals. That would make up a perfectly valid SQL compound statement. Search for “SQL injection attacks” in your favorite search engine (that would be www.live.com to save you the typing) and you will find a lot more interesting and destructive things to do.
These are two very common scenarios which all the bad guys already know. The mistake that I made when I was a developer (not ever for Microsoft, I hasten to add) was to assume that input was correct or in error. I never considered that they could be deliberately and maliciously wrong. The world has changed and criminals routinely target computer systems for profit.
In my next post, I will be talking about some of the things that developers can do to protect themselves.
Signing out
Mark
