Re: Strategies for teaching secure coding practices

[Crispin Cowan <crispin () immunix com>]

David Crocker wrote:


Crispin Cowan wrote:
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.

I over-simplified when I said it is independent of OO methods. OO 
languages do allow you to simplify the error checking and handling using 
exception methods, which make it much less of a burden for code to 
consider error cases than in classical procedural languages.



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).

Agreed, you can do that too. The limitation of the "proof" method is 
that it leads to brittle code: if a developer changes something over 
here, it may invalidate a lemma that some code over there was counting 
on. As David says, the cost of the "check everything" method is, well, 
the cost :)


You can use a hybrid method, where you use proof for parameters that are 
"internal" to a "module" and error checking for "inter-module" 
parameters. By scaling up or down what you consider to be a "module" you 
can trade trade cost against safety to your taste.


Crispin

--
Crispin Cowan, Ph.D.  http://immunix.com/~crispin/
CTO, Immunix          http://immunix.com
Immunix 7.3           http://www.immunix.com/shop/