Writing Secure Code

Michael Howard writes about habits for developing secure code in the November 2006 issue of MSDN Magazine (https://msdn.microsoft.com/msdnmag/issues/06/11/SecureHabits/default.aspx).  Interesting enough, I just started reading his book on the Security Development Lifecycle and in the few pages that I have read so far, I think I would already recommend it to anyone who deals with writing software (there are very good insights on how to position the need for security to management/stakeholders as well).

One tip that I always like to stress is to always code for what you know is correct.  I've seen so many people do this:

if (input is bad #1) || (input is bad #2) || (input is bad #3)
{
    // reject input
}
else
{
    // input deemed non-malicious, do processing
}

Which is a good first step to input validation but is inherently insecure - there's no way that you can think of *all* of the various malicious inputs.  A better way would be to code for what you know is correct.  This is easily achieved with regular expressions.

if (input is good #1) || (input is good #2)
{
    // do processing
}
else
{
    // reject input
}

In line with this, I'd like to invite you all to attend the upcoming MSDN Connection Evening on Nov 30: https://mssg.earth9.com/singapore/edm/2006/11/02/msdn.html