One of the major goals of this book is to help clarify how Windows security works so you'll be able to use it effectively in your applications and also in your everyday life. But even if you have a perfect understanding of all the security features of the platform, and make all the right API calls and configure security policy very carefully to keep out attackers, if you don't write your code with security in mind, none of that will matter because you'll still be vulnerable to attack.

Look at the following C# method and count the number of security APIs that it uses.

 // this code has a really nasty security flaw
 void LogUserName(SqlConnection conn, string userName) {
   string sqlText = "insert user_names values('" + userName + "')";
   SqlCommand cmd = new SqlCommand(sqlText, conn);
   cmd.ExecuteNonQuery();
 }

That's right, it doesn't call any security APIs. However, if we assume the userName parameter has been given to us by someone we don't fully trust (aka a user of our application) then this benign-looking code has a horrible security flaw. If the above function had been written with security in mind, here's how it might have looked instead:

 // much more secure code
 void LogUserName(SqlConnection conn, string userName) {
   string sqlText = "insert user_names values(@n)";
   SqlCommand cmd = new SqlCommand(sqlText, conn);
   SqlParameter p = cmd.Parameters.Add("@n",
       SqlDbType.VarChar, userName.Length);
   p.Value = userName;
   cmd.ExecuteNonQuery();
 }

Note the difference in the coding style. In the first case, the coder appended untrusted user input directly into a SQL statement. In the second case, the coder hardcoded the SQL statement and encased the user input in a parameter that was sent with the query, carefully keeping any potential attackers in the data channel and out of the control channel (the SQL statement in this case).

The flaw in the first bit of code is that a user with malicious intent can take control of our SQL statement and do pretty much whatever he wants with the database. We've allowed an attacker to slip into a control channel. For example, what if the user were to submit the following string as a user name?

 SeeYa');drop table user_names--

Our SQL statement would now become

 insert user_names values('SeeYa');drop table user_names--')

This is just a batch SQL query with a comment at the end (that's what the -- sequence is for) that inserts a record into the user_names table and then drops that same table from the database! This is a rather extreme example (your database connection should use least privilege so that dropping tables is never allowed anyway; see WhatIsThePrincipleOfLeastPrivilege), but it dramatically emphasizes that the attacker has taken control of your SQL statement and can submit arbitrary SQL to your database. This is really bad!¹

There are many examples where malicious user input can lead to program failure or security breaks. If you're not familiar with things like cross-site scripting, buffer overflow vulnerabilities, and other attacks via malicious user input, please stop reading now and go buy a copy of a book for example, Howard and LeBlanc, 2002 or Viega and McGraw, 2002 that focuses on these sorts of vulnerabilities. Study it, seriously. Perform regular code reviews to keep your sofware free from such bugs. These bugs aren't the focus of this book, but so many developers are unaware of them that I'd be remiss not to mention them here.

It's not enough to know how about security technologies. You need to be able to write secure code yourself.

¹ For more information on exploiting a SQL injection vulnerability, see http://www.issadvisor.com/columns/SqlInjection3/sql-injection-3-exploit-tables_files/frame.htm

PortedBy KeithBrown