RE: Strategies for teaching secure coding practices

["David Crocker" <dcrocker () eschertech com>]

Crispin Cowan wrote:

> >
The overall philosophy of secure coding is to write all code as if any
code not on the page is out to get you, or at least will do things
improperly. Check *everything*! Do not assume that the parameters to a
function will be properly formatted or within bounds. The business with
string overflows and pointer handling are just instances of this philosophy.

...

The secure coding philosophy is independent of OO methodologies, but can
be applied there. Here's some ideas:

...
    * Object methods should *not* assume that objects have been properly
      initialized.
    * Objects are abstract data types, and therefore strong bounds can
      often be placed on valid data values. Insert checks all over the
      place that more tightly restrict data to those valid values.
<<

That's one approach, but it means that you will be doing a very large number of
parameter checks and adding some sort of error handling when the checks fail.
The problem with this is that the error handling code grows like Topsy. Also, if
you are doing this seriously, you should test every part of the code, including
all the error checks; which means a great deal of unit testing. In practice,
developers are very lazy about testing error handling code.

An alternative way is to *prove* that all inputs are within bounds, all objects
are properly initialised by their constructors, and the invariants on abstract
data types are maintained. Then you can avoid most of the error checks. Where
your system accepts external input, you must ensure that it is robust for all
possible inputs (which will probably mean including checks on the parameters for
those functions that are called from outside). You do not need checks on the
parameters of functions that are only called *internally* (you can still add
them if you are paranoid, but if they fail then it is reasonable to abort the
entire program because the only possible cause should be a hardware failure).

This approach is more or less impossible to apply if you are coding in C or C++.
It may be feasible if you are using Java (using tools such as ESC/Java), but it
is easiest if you are using a language and toolset specifically designed for the
purpose. This is what I do for a living.

David Crocker
Escher Technologies Ltd.
www.eschertech.com